Security and privacy at RankEcho

What RankEcho needs for a free audit

A free RankEcho audit starts with public-domain information. The user submits a domain, and RankEcho checks public pages, AI visibility signals, prompt outcomes, cited URLs, and source patterns that can be observed without connecting private systems.

This design keeps the first audit lightweight. A brand can see where AI systems cite, mention, ignore, or replace it without giving RankEcho access to CMS, analytics, CRM, or private customer records.

• Public domain name submitted for audit.
• Optional email address for results, login, or follow-up.
• Generated prompt results and cited URLs.
• Publicly observable source domains and source categories.
• Scorecard, gap map, and fix recommendations generated from the audit.

What RankEcho does not require

RankEcho does not need broad internal access to run an initial public-domain audit. The product is intentionally built around public visibility measurement first, not private data extraction.

That does not mean paid features never use account data. It means the core AI visibility audit does not require sensitive operational systems just to diagnose whether AI engines can see and cite a public brand.

• No CMS admin access required for the initial audit.
• No Google Analytics access required.
• No Search Console access required.
• No CRM, customer database, or sales pipeline access required.
• No website passwords required.
• No raw payment-card data stored by RankEcho.

What audit data is stored

RankEcho may store audit metadata and generated results so users can view reports, generate fixes, track proof-loop re-tests, and compare changes over time. Stored data should be limited to what is needed to operate the product and improve aggregate measurement responsibly.

Audit data can include the submitted domain, optional email, audit status, prompt outputs, cited URLs, scorecard data, source breakdowns, and fix/proof metadata.

• Domain and audit ID.
• Optional email address if provided by the user.
• Prompt set, engine, result status, and generated scorecard.
• Cited URLs, source domains, and source-type classification.
• Gap diagnosis and fix package metadata.
• Proof-loop observations when tracking is enabled.

How benchmark data should be handled

Benchmark reporting should use aggregated and anonymized patterns, not customer-level exposure. RankEcho can report public benchmark trends such as citation rate or off-site source dependence only when the sample size supports the claim.

Small samples should remain in collecting state. This avoids fake precision and protects the trust value of the benchmark.

• Use aggregate counts and rates, not private customer-level rows.
• Withhold industry rows until the sample threshold is reached.
• Avoid publishing identifiable customer data without permission.
• Separate benchmark methodology from sales claims.
• State limitations when sample sizes are small or directional.

How secrets and API keys should be handled

Production secrets should be stored in the hosting provider's secret system, not committed to the repository. For RankEcho on Cloudflare Workers, API keys and webhook secrets should be configured as Worker secrets or protected environment variables depending on sensitivity.

Stripe secret keys, webhook secrets, AI provider keys, email provider keys, and similar credentials should never be pasted into source files or exposed in client-side code.

• Store secret keys as Cloudflare Worker secrets.
• Keep public configuration separate from private credentials.
• Do not commit .env files containing production secrets.
• Do not expose API keys in browser JavaScript.
• Rotate credentials if a secret is ever leaked.
• Use webhook signature verification for payment events.

Billing and payment security

RankEcho uses Stripe-style checkout and webhook flows for paid plans. Raw card details should be handled by the payment provider, not stored by RankEcho.

Plan access should be based on verified billing status and signed session state. Webhook signatures should be checked so billing changes cannot be forged.

• Payment processing handled by Stripe or the configured payment provider.
• Raw card data should not be stored by RankEcho.
• Webhook signatures should be verified before updating plan status.
• Plan entitlements should fail closed when billing status is inactive or unknown.
• Checkout and login endpoints should be rate-limited.

Abuse prevention and safe domain handling

A public-domain audit system needs abuse controls. RankEcho should reject internal hosts, private IP ranges, localhost-style names, invalid hostnames, and domains that could create SSRF risk.

Rate limits also matter because audits can call external services and AI providers. Abuse controls protect customers, infrastructure, and cost stability.

• Reject localhost, private IPs, metadata IPs, and internal hostnames.
• Validate public domain format before starting an audit.
• Rate-limit audit, checkout, login, and fix endpoints.
• Reuse recent audit results where appropriate to reduce duplicate cost.
• Keep API routes disallowed in robots.txt where appropriate.

Responsible AI visibility measurement

RankEcho measures public AI-search behavior. It should not be used to generate deceptive content, fabricate third-party support, spam communities, or manipulate AI systems with hidden claims that do not match visible page content.

Responsible GEO focuses on making truthful, useful, crawlable, and corroborated information easier for AI systems and humans to understand.

• Use schema only when it matches visible content.
• Avoid fake reviews, fake citations, or fabricated benchmark claims.
• Do not publish hidden text meant only for machines.
• Do not claim guaranteed AI placement.
• Prioritize accurate brand representation over gaming answers.

What customers should review before publishing fixes

RankEcho fix packages can make recommendations, but customers should review any content, schema, source outreach, or technical changes before publishing them. The customer remains responsible for accuracy, brand voice, compliance, and claims made on their site.

This review step is especially important for regulated industries, legal claims, health claims, financial claims, testimonials, and competitor comparisons.

• Review generated answer blocks for factual accuracy.
• Confirm schema reflects visible page content.
• Check competitor comparisons for fairness and accuracy.
• Avoid unsupported performance or revenue claims.
• Have legal or compliance review where required.

Security limitations

No public SaaS can make absolute security guarantees. The responsible position is to minimize data collection, avoid unnecessary credentials, protect secrets, verify payment events, rate-limit sensitive endpoints, and be transparent about what the product does and does not need.

RankEcho's security posture should improve over time as the product matures, including clearer incident processes, customer controls, and enterprise documentation where needed.

• No system is risk-free.
• Audit outputs can include public URLs and generated text that should be reviewed.
• AI provider behavior and third-party source availability can change.
• Customers should avoid submitting confidential information into public-domain audit fields.
• Security questions should be directed to RankEcho support.

Security FAQ

Last updated 2026-06-07. RankEcho is operated by Nexus Decision Systems LLC.