Encryption Inventory

> Scope & status: This is part of SiteRevive's SOC2-LITE evidence trail — > a documented, good-faith inventory of how data is protected. It is not a > certified SOC 2 audit and makes no certification claim.

_Last reviewed: 2026-07-16_

This document inventories where customer and workspace data is encrypted at rest and in transit, and how secrets are handled.

At rest

| Data store | What it holds | Encryption at rest | |---|---|---| | Supabase Postgres (primary DB) | All workspace data: leads, campaigns, mockups, messages, events, revenue, clients, access logs | AES-256 disk/volume encryption provided by the Supabase/AWS managed platform. Encryption keys are managed by the platform. | | Supabase Storage (screenshots/assets) | Validated current-site screenshots and generated assets | Encrypted at rest by the managed storage backend. Screenshot objects use workspace/lead/content-hash paths. | | Render (application hosting) | No primary data store; ephemeral compute + build cache only | Managed-platform disk encryption; the app is stateless and holds no durable customer data outside the DB. |

Notes:

• SiteRevive runs logical multi-tenancy on a shared Postgres. Every workspace-scoped query filters by workspaceId; tenants are not physically separated (per-tenant databases are explicitly out of scope for v1.5).
• Row-Level Security (RLS) policies exist on tenant tables as defense-in-depth for any direct PostgREST/supabase-js access. The server's Drizzle client uses an owner role and enforces isolation via explicit workspaceId filters.

In transit

| Hop | Protocol | |---|---| | Browser ⇄ app (Render) | HTTPS / TLS (HTTP is redirected to HTTPS at the platform edge). | | App ⇄ Supabase Postgres | TLS-encrypted Postgres connection (Supabase requires TLS; connections use the pooler/direct hostnames over TLS). | | App ⇄ Supabase Auth/Storage | HTTPS / TLS. | | App ⇄ subprocessor APIs (Anthropic, Resend, Google Places, Stripe, Microlink; legacy thum.io) | HTTPS / TLS to each vendor endpoint. | | Inbound webhooks (Resend, Calendly/Cal.com, Stripe, Twilio) | HTTPS, plus payload signature verification (Svix / HMAC / Stripe signature) before the payload is trusted. | | Published client sites (/sites/[host]) | Served over TLS via the hosting platform + custom-domain certificates. |

TLS is terminated at the hosting edge and used for every outbound vendor call and every inbound webhook. There is no plaintext transport of customer data between components.

Secrets handling

• Environment variables only. All credentials (DB URL, Supabase keys, Anthropic/Resend/Google/Stripe/Twilio/Microlink keys, webhook signing secrets, UNSUBSCRIBE_SECRET) are supplied via environment variables in Render and in a local .env that is gitignored — never committed to source control.
• Startup validation. Server env is validated (src/lib/env.ts); blank values are treated as absent so misconfiguration fails fast rather than running with an empty secret.
• Hashed tokens & keys. Values that authenticate a bearer are stored as SHA-256 hashes, never in plaintext: - Public API keys — only the hash is stored (api_keys.key_hash); the raw key is shown once at creation (src/db/schema/api-keys.ts). - Team invite tokens and client-portal magic-link tokens are hashed (src/lib/auth/invite-tokens.ts, portal-tokens.ts). - Unsubscribe links are HMAC-signed, not guessable.
• Webhook signatures. Inbound webhooks verify a per-tenant or global signing secret before acting on any payload; verification happens before side effects.
• No secrets in logs. The self-hosted error capture (app_errors) and the access-evidence log (access_logs) record metadata (message, path, action, resource) — not credentials or full request bodies.
• Screenshot key boundary. MICROLINK_API_KEY is sent only in the server-side x-api-key header to the Pro endpoint. Provider URLs, attempt diagnostics, database rows, public reports, and browser image requests never contain it.

Explicitly not claimed

This inventory documents controls that exist in the product today. It is not a SOC 2 certification, a penetration-test report, or an attestation by an independent auditor. It is evidence intended to help a prospective agency customer evaluate SiteRevive's baseline data-protection posture.