Security
This page describes the controls that exist in the AnswerRank codebase today, in enough detail that a technical reviewer can check them against the product. Where something is planned rather than done, it says so.
AnswerRank holds no third-party security certification. We are not SOC 2 certified, not ISO 27001 certified, and have not completed a third-party penetration test. Nothing on this page should be read as a compliance attestation.
Certification status
Security badges are easy to display and hard to earn. Here is the honest state of each one, including the ones we do not have.
- SOC 2 Type IINot held
Not certified. No audit has been performed and no report exists. We would rather say so than display a badge we did not earn.
- ISO/IEC 27001Not held
Not certified, and not currently in an audit process.
- Third-party penetration testPlanned — not yet done
Not yet performed. Planned before we describe the platform as generally available.
- HIPAANot held
Out of scope. AnswerRank is not designed for protected health information and should not be used to process it.
- Data processing agreementPlanned — not yet done
A DPA template is published on this site. It is an unexecuted template pending review by qualified legal counsel, not a signed agreement.
- Row level security across tenant dataIn place today
Implemented in the database schema and described in detail below, with a test suite asserting the anonymous role reaches nothing.
- Strict response security headersIn place today
A content security policy and the headers listed below are applied to every route by the application configuration.
Tenant isolation
Isolation is enforced in the database, not only in application code. Every tenant table carries an organization identifier, row level security is enabled on it, and each policy is scoped to authenticated sessions.
- A row is readable only by users who are members of the organization that owns it. Membership is resolved by a database function, not by a value the client can send.
- Writes are gated by role — viewer, editor, admin and owner are ordered, and privileged operations require a minimum rank.
- The anonymous role has its table, sequence and function grants revoked outright, so a carelessly written future policy still cannot expose data to an unauthenticated caller.
- Several tables carry row level security with zero policies, which means no client can reach them at all. They are served only by server code holding the service-role key: share tokens, anonymous audit results, the billing webhook ledger and platform operations tables.
- Personal notification rows are scoped to the individual user rather than the organization.
Measurement integrity
Measurement data is read-only to clients. Engine responses, brand and competitor mentions, citations, metric snapshots, site audits and experiment runs have no insert, update or delete policy for any authenticated user, which means a customer cannot manufacture their own score — and neither can an attacker holding a customer session.
Large raw provider payloads are held in object storage and referenced by a pointer plus a SHA-256 digest, so a stored answer can be shown to be unmodified. A database constraint prevents a successful execution from being stored without the answer text that justifies it.
Administrative actions are recorded in an append-only audit log. Clients have no insert, update or delete policy on it; organization admins can read their own trail, and log payloads are redacted before they are written so secrets never enter the log.
Secrets and credentials
- Provider API keys are read server-side only. The single value derived from them that is allowed to reach the browser is a boolean per engine: configured, or not configured.
- A missing key is a state, not a crash. The product renders an engine as unavailable pending administrator configuration rather than silently falling back to sample data.
- Third-party integration credentials are encrypted at the application layer before storage, and the ciphertext column has its read privilege revoked from authenticated sessions — including organization admins — so row level security and column privileges both have to fail before it could be read.
- Scheduled and cron entrypoints require a shared secret. Administrative access is an explicit server-evaluated email allowlist, never a client-supplied claim.
Application hardening
These response headers are applied to every route by the application configuration. You can verify them yourself on any page of this site.
| Header | Value | What it does |
|---|---|---|
| Content-Security-Policy | default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none' | Restricts where scripts, styles, images, fonts and network calls may come from, and forbids the page being framed at all. |
| Strict-Transport-Security | max-age=63072000; includeSubDomains; preload | Browsers refuse to talk to the site over plain HTTP for two years, including subdomains. |
| X-Frame-Options | DENY | Clickjacking defence for older browsers, alongside the frame-ancestors directive. |
| X-Content-Type-Options | nosniff | Stops the browser reinterpreting a response as a type it was not served as. |
| Referrer-Policy | strict-origin-when-cross-origin | Outbound requests never leak the full path of the page you were on. |
| Permissions-Policy | camera=(), microphone=(), geolocation=(), interest-cohort=() | The application asks for no device permissions and opts out of cohort-based ad targeting. |
The content security policy is abbreviated in this table for readability. The full policy, including the allowed connect and frame sources, is sent with every response.
Data collection and retention
AnswerRank is a measurement tool. The data we hold is mostly about public web content and public AI answers, plus the minimum needed to run accounts and prevent abuse.
A free audit result is retrieved with a token that we store only as a SHA-256 hash. The visitor IP is stored as a hash for abuse control rather than in the clear, and results carry an expiry — 30 days by default — after which they are purged.
Profiles are readable by the account holder and by teammates in a shared organization, and by nobody else. Account deletion cascades from the authentication record through the schema.
The prompts you track are sent to the answer engines you have enabled, because that is how a check is performed. Do not put confidential information into a tracked prompt.
Card details are handled by our payment provider. We store subscription state, never card numbers.
Service providers
The platform is built to run on the services below. Which ones are active depends on the deployment — every one of them has an explicit configuration switch, and the product shows a capability as unavailable when it is not configured.
- Supabase
Postgres database, authentication and object storage
- Stripe
Subscription billing. Card details never reach our servers.
- Upstash Redis
Rate limiting and short-lived operational state
- Trigger.dev
Background job execution for scans and reports
- Resend
Transactional email
- Sentry
Error monitoring
- PostHog
Product analytics
- Cloudflare Turnstile
Abuse protection on the public audit form
- OpenAI, Anthropic, Google, Perplexity
Answer engine APIs that receive the prompts we execute
- DataForSEO
Licensed structured search-results data for Google AI Overviews
The list that governs a specific customer relationship belongs in a signed data processing agreement, not on a marketing page. Our DPA template is published for review.
Reporting a vulnerability
If you believe you have found a security issue, email hello@answerrank.io with “Security report” in the subject line, and include enough detail to reproduce the issue. We do not run a paid bug bounty programme and we do not publish a response-time commitment yet — we would rather promise nothing than promise something we have not staffed.
Please do not run automated scanning against production, and do not access data belonging to anyone other than yourself while investigating.