Security

Last verified July 17, 2026.

This page describes what is actually deployed, verified directly against our database and code — not a compliance-marketing page. We do not hold a SOC 2 report, ISO 27001 certification, or any other third-party security certification, and we do not claim to. If a claim isn’t backed by something we can point to below, it isn’t on this page.

Encryption in transit and at rest

All traffic to citationsafe.com is served over HTTPS. Our host, Vercel, supports TLS 1.2 and TLS 1.3 at the edge and negotiates TLS 1.3 with modern clients (see Vercel’s encryption documentation); plaintext HTTP is not served. Our database, hosted on Supabase, is encrypted at rest using AES-256 by default and encrypted in transit via TLS, per Supabase’s published security page — that is Supabase’s documented guarantee about its own infrastructure, not an independent audit we have performed ourselves.

Document handling

Documents and briefs submitted for verification are parsed and checked in memory during the request; there is no code path in this application that writes an uploaded file to disk or object storage (verified: zero calls to Supabase Storage anywhere in the codebase). What is written to the database is a SHA-256 hash of the submitted text plus citation-level metadata (the matched citation string, verdict, source URL, confidence) — never the surrounding document text. We are hardening this into a database-level guarantee (a constraint that makes full-text storage physically impossible, not just absent from today’s code paths) and will publish a stronger “zero-retention” statement once that lands and is verified in production. Until then, we are not making that stronger claim here — see retention schedule and privacy policy for what is retained today.

Database access control — Row Level Security

Every table in our production database (43 of 43, verified live via Postgres system catalogs) has Row Level Security (RLS) enabled. 32 of those 43 tables have zero RLS policies defined, which in Postgres means default-deny: no row is readable or writable through the public API using an anonymous or authenticated end-user key, even if that key were leaked — only our backend, using a service-role key that never reaches the browser, can read or write those tables. The remaining tables carry narrowly scoped policies for specific self-service cases (for example, a signed-in user reading their own verification history), never a blanket allow.

Access controls

Least-privilege service credentials. The Supabase service-role key (the only credential capable of bypassing RLS) is used exclusively in server-side code and is never exposed to the browser or to end-user API responses.
Audit logging. Authentication and billing lifecycle events (login, signup, logout, subscription created/updated/canceled, password reset requested/completed) are written to an append-only audit log table. That table has RLS enabled with zero policies — the same default-deny posture as above — so only server-side code can write to it, and no end-user role can read, modify, or delete entries.
Provider account access. Administrative access to our infrastructure providers (Vercel, Supabase, GitHub, Stripe) is limited to a small number of authorized accounts, and multi-factor authentication is our policy on each. We are not able to publish a machine-verified attestation of 2FA status here: as of this writing, none of these providers expose per-account 2FA/MFA status through a documented, publicly-callable API endpoint, so this is a policy statement, not an API-verified one — the same standard of honesty this entire page holds itself to.

Rate limiting

Abuse and free-tier limits (signup attempts, free citation checks, free-tool usage) are enforced with durable, database-backed counters — not in-memory counters that reset on redeploy or can be bypassed by hitting a different serverless instance. Where a rate-limit check itself fails due to an infrastructure error, it fails open (allows the request) rather than taking the product down over a transient database hiccup — a deliberate availability-over-strictness tradeoff for low-severity limits, documented in code where it applies.

Payments

All payment processing runs through Stripe. We never see or store full card numbers — Stripe handles card data directly and we receive only limited billing metadata (plan, status, last four digits, billing country) back via webhook. Stripe’s own PCI DSS Level 1 certification and security practices are documented on Stripe’s security page — that is Stripe’s claim about Stripe, not ours.

Hosting, infrastructure, and subprocessors

The application is hosted on Vercel (application layer, TLS termination, edge network) and Supabase (Postgres database). Paid-tier proposition-matching checks make a single model call to Anthropic , sent only a narrow citation/quote/proposition excerpt, never the full document. Both hosting providers and Anthropic publish their own security and compliance documentation at the links above — those are their documented guarantees about their own infrastructure, not claims we are independently making or auditing on their behalf. See the full subprocessor list for every third party that touches customer data and what each one handles.

Compliance posture

Not SOC 2 certified today. We hold no SOC 2 report (Type I or Type II), ISO 27001 certification, HIPAA attestation, or any other third-party security certification, and this page has never claimed otherwise.
Roadmap: targeting a SOC 2 Type I readiness assessment in 2027. This is a stated goal, not a claim of current compliance, and we will update this page the moment that status changes — not before.
Controls already in place that a SOC 2 assessment would evaluate: RLS default-deny on every database table, least-privilege service credentials, append-only audit logging on auth/billing events, database-backed rate limiting, and payment processing fully delegated to a PCI DSS Level 1 processor.
No claim of a formal penetration test or bug bounty program at this time.

Incident response

Found a security issue? Email security@citationsafe.com (or support@citationsafe.com if that doesn’t reach us). We will acknowledge and investigate reports; we do not currently offer a paid bounty. For confirmed incidents affecting customer data, we will notify affected account holders directly by email.

Privacy policy · Breach response protocol · Subprocessor list · Retention schedule · Data Processing Addendum (template) · Methodology

Digital Empire Holdings LLC · 30 N Gould St Ste N, Sheridan, WY 82801.