Security at ComplianceKit

ComplianceKit separates private workspace data from public legal pages. Security is based on authentication, server-side authorization, workspace boundaries, payment-provider boundaries, and limited data exposure.

No security program can promise absolute protection, but the product is designed to keep the public surface narrow and the private surface controlled.

• Private audits, reports, and drafts remain in the workspace.
• Public legal pages only show documents the user publishes.
• Source audit IDs, recommendation IDs, and private evidence should not appear on public pages.
• Published pages are public by design and may be visible to anyone with the URL.

Access control is enforced with Supabase auth, session cookies, workspace membership checks, and server-side authorization.

• Server-side checks gate report unlocks and document generation.
• Workspace-scoped tables should rely on RLS and server checks together.
• Service-role access should remain server-only.
• Protected actions should fail closed rather than assume client state is trustworthy.

Stripe handles payment details. ComplianceKit stores checkout and payment references, status, and entitlement state.

• We do not store full card numbers.
• Webhook signature verification is required before entitlements change.
• Duplicate or repeated webhook events should be handled idempotently.
• Unlocks should not activate until payment confirmation is verified.

The crawler is intentionally limited and conservative.

• It is intended for public URLs only.
• It blocks localhost, private, and internal network targets.
• It limits redirects, timeouts, response size, and page count.
• It does not require credentials.
• It does not intentionally persist raw full HTML by default.
• It stores only safe evidence snippets and metadata needed for the report.

Operational data lives in Supabase-backed tables, document version history, and lifecycle metadata needed to power the app.

• Document versions should remain append-only.
• Audit lifecycle data should preserve what happened during scans and retries.
• Logs and backups may retain some data for a limited time.
• Users can request deletion through the contact channels listed below, subject to legal and operational limits.

Analytics are optional and should stay narrow.

• PostHog is optional and should be a no-op when not configured.
• Analytics should avoid raw document bodies and private audit content.
• Logs are used for reliability, debugging, security, and abuse prevention.
• When analytics are not configured, tracking should not expose data elsewhere.

Secrets should stay in server-side environment variables and out of the client bundle. Stripe and Supabase secret keys must only be used in server-only code.

If an exposed secret is discovered before production release, it should be rotated before the app is considered ready for launch.

If you believe you found a vulnerability, contact us through the support channel in the app footer.

• Do not access, delete, or modify data that is not yours.
• Do not run destructive tests.
• Give us reasonable time to investigate before public disclosure.
• No bug bounty is implied unless we explicitly announce one.

If we identify a security incident, our response is to investigate, contain, remediate, and, where required, notify affected users or regulators.

We also use incidents to improve controls and reduce the chance of repeat issues.

• No system is perfectly secure.
• Users are responsible for protecting their own account credentials.
• Generated documents must be reviewed before use or publication.
• Public documents are public by design and should be published carefully.