Security Overview

1. Architecture in one paragraph

The platform runs on Vercel (serverless functions, edge cache), with primary state in a Supabase Postgres instance in eu-west-2 (London). Static assets and Kickstarter-imported reward images live in Supabase Storage, also in eu-west-2. Authentication is delegated to Clerk. Payments go through Stripe. Transactional email is sent by Resend. Cloudflare sits in front of Vercel for DNS and DDoS protection. The full list and what each provider touches is on the public sub-processor list.

2. Encryption

• In transit — TLS 1.2+ on every connection, with HSTS on the apex domain. Cloudflare and Vercel enforce TLS termination; we do not allow plaintext traffic.
• At rest — Postgres storage is encrypted with AES-256 by Supabase. Object storage is encrypted with AES-256 by the upstream provider. Backups are encrypted with the same keys.
• Application-level — sensitive fields (backer email when stored alongside private-relay metadata; addresses pending charge) are additionally encrypted with a field-level key managed via Vercel's environment-variable vault, separate from the database password.

3. Kickstarter credential handling

Mechanics, for the curious:

• The credential entry form posts directly to a Vercel serverless function with a CSRF token. The body is not logged.
• The function spawns a single Kickstarter authentication session, fetches the necessary pages, and writes the resulting backer + reward data into the creator's Postgres rows.
• The Kickstarter session cookie is held in process memory only and is not persisted. The function exits within a fixed time budget; memory is reclaimed by the platform.
• If you change your Kickstarter password, future imports will fail — there is no long-lived token we can fall back to.

See the Terms of Service for the legal basis of this delegation. You can always import from a CSV export instead, in which case no Kickstarter credentials touch our infrastructure at all.

4. Access control

• Production database — accessible only via the application's runtime identity, which is rotated per deployment. There are no shared human credentials.
• Engineering access — direct database queries (read-only) and infrastructure dashboards are gated behind SSO with required hardware-key 2FA.
• Customer-support access — there is no "log in as customer" feature. Where support requires data access, it goes through a short-lived "view as tenant" lens that is audit-logged with the staff member's identity, the customer affected, and the duration.
• Audit log — every successful or attempted privileged access is logged for 12 months.

5. Application security

• Authentication is delegated to Clerk, with password complexity rules, breached-password detection, and account-lockout policies enforced by Clerk.
• All admin endpoints require an authenticated session with the matching organisation membership. Authorisation is checked server-side on every request — there is no client-side trust.
• The platform uses parameterised queries throughout (Drizzle ORM). No raw SQL is built from request data.
• Content rendered into HTML is escaped by React's default behaviour. We do not use dangerouslySetInnerHTML except where the input is known-safe and explicitly attribution-marked.
• Stripe handles all card data via Stripe Elements; cardholder data does not transit our servers. The platform is therefore out of scope for PCI DSS beyond the SAQ-A self- assessment that Stripe Elements requires.

6. Breach response

• A confirmed unauthorised access event triggers our incident playbook within 1 hour of detection.
• We will notify affected creators within 48 hours of confirming a Personal Data Breach, in line with our DPA.
• Where required by law, we will also notify supervisory authorities (the ICO in the UK; the relevant lead authority in the EEA) within 72 hours.
• Post-incident, we publish a redacted public root-cause analysis within 30 days.

7. Certifications & attestations

StoryForge Pledges is an early-stage product. We are not yet SOC2 or ISO 27001 certified. Our committed roadmap:

• Now — written security policy, sub-processor disclosure, breach playbook, self-assessment against ISO 27001 controls available on request.
• +12 months — SOC2 Type I.
• +24 months — SOC2 Type II.

We rely on the SOC2/ISO 27001 certifications of our sub-processors (Vercel, Supabase, Clerk, Stripe, Resend, Cloudflare) where they have them, and disclose this on the sub-processor page.

8. Reporting a vulnerability

We take vulnerability reports seriously and will not pursue legal action against good-faith researchers who follow these rules:

• Email security@storyforgerpg.com with a description, reproduction steps, and any proof-of-concept.
• Do not access, modify, or destroy data that does not belong to you. Stop and report as soon as you have demonstrated a vulnerability.
• Give us a reasonable disclosure window (90 days from acknowledgement) before publishing.

We do not yet run a paid bug bounty programme but are happy to credit responsible researchers and to provide a written attestation for your CV.