Security overview

This page is a concise summary of how Comma protects your data. It is written for security reviewers and engineering teams evaluating the Service. For the full legal description of how we collect and handle personal information, see the Privacy Policy; for the list of third parties that touch customer data, see Subprocessors.

1. Data residency

Comma’s primary infrastructure runs in the United States — specifically AWS us-west-2 (Oregon). Customer report content, comments, account information, and routine run history are stored only in that region. AI inference (AWS Bedrock) runs in the same region. Static assets and TLS termination are served through Cloudflare’s global edge network, but no customer-uploaded content is stored at the edge.

2. Encryption

• At rest. All Postgres data (reports, comments, accounts, billing state, run history) is encrypted at rest with AES-256, provided by Supabase on AWS EBS. Uploaded assets in Cloudflare R2 are encrypted at rest with AES-256.
• In transit. Every connection — browser, API, and inter-service — is encrypted with TLS 1.2 or higher. HSTS is preloaded (max-age 2 years, includeSubDomains) and HTTPS is enforced for all routes.
• Application-layer. Sensitive connector secrets (third-party API tokens, webhook authentication headers) are encrypted with AES-256-GCM using a key held in our infrastructure secrets, then stored. Postgres never sees these in plaintext.

3. Access controls

• Row-level security (RLS). Every report, comment, and connector row is gated by Postgres RLS policies enforced against the requester’s authenticated identity. A user can never read a row they were not granted access to, even by hitting the database directly via our anon API key.
• Share-link visibility tiers. Reports can be shared as private (invitees only), team, signed-in Comma users, or public link. The link permission additionally controls whether viewers can comment.
• Optional password on share links. Any non-private share link can be locked with a password. We store a PBKDF2-SHA256 hash (200,000 iterations, per-link salt) — never the password itself. Unlocking issues a per-link, signed, HttpOnly+Secure+SameSite=Lax cookie scoped to that report and expiring after 24 hours.
• API tokens. Personal API tokens (comma_sk_…) are hashed before storage; the plaintext is shown to the user exactly once. Tokens carry an optional expiry and can be revoked instantly. Per-token rate limits apply (Free 60 rpm, Pro 600, Team 6,000).
• Authentication. Email + password sign-in via Supabase Auth, with email-confirmation enforced. Sessions are short-lived JWTs with refresh rotation.

4. Audit logging

Sensitive workspace actions (permission changes, share-visibility changes, API-token creation/revocation, connector secret writes) are recorded to an immutable audit log tied to the actor and the affected resource. The log is queryable by the workspace owner.

5. Retention & deletion

• Account & content. Reports, comments, routines, connectors, and API tokens are deleted on account closure (including any support correspondence tied to the account).
• Routine run history. Timestamps, HTTP status codes, error messages, and estimated cost are automatically purged after 90 days.
• Operational logs & backups. Retained for a limited operational window (typically up to 30 days) before automatic deletion.
• Right-to-erasure. Deleting your account cascades to your contact-form history; deleting a report cascades to its comments, revisions, and assets.

6. Tenancy & isolation

Comma is a multi-tenant SaaS. Workspace data is logically isolated by RLS — there is no shared application memory across tenants in our request path, and each request runs in a fresh Cloudflare Worker isolate. User-uploaded HTML is rendered exclusively in sandboxed, opaque-origin iframes so an embedded script cannot read the surrounding application context.

7. Application hardening

• Content Security Policy on every HTML response, blockingframe-ancestors entirely and restricting connect, script, and style sources to known origins.
• HTTP security headers on every response: HSTS (preloaded, 2 years),X-Content-Type-Options: nosniff, Referrer-Policy strict-origin-when-cross-origin, restrictive Permissions-Policy.
• Structured request logging with per-request IDs, surfaced in Cloudflare Workers Observability for incident review.
• Dependency hygiene. Dependencies are pinned via lockfile and updated regularly; CI runs lint and type-check on every change.

8. Vendors

The third parties that touch customer data are listed on the Subprocessors page, with their hosting region and a link to each vendor’s DPA. We notify customers of material subprocessor changes at least 30 days in advance.

9. Reporting a vulnerability

If you have discovered a security issue, please email info@getnadir.com with a description and reproduction steps. Please give us a reasonable window to remediate before public disclosure. We do not currently run a paid bug-bounty program, but we acknowledge responsible reports and credit reporters on request.

10. What we do not yet have

Transparency: Comma is an early-stage product. We do not yet hold a SOC 2 audit, do not sign HIPAA BAAs, and do not currently offer customer-managed encryption keys. If these are blocking for your evaluation, please contact us at info@getnadir.com — we are happy to discuss our roadmap.