Security is a release condition, not a badge.

Controls in the application

• Password hashing, server-side sessions, HttpOnly cookies, and rate-limited authentication routes.
• Same-origin checks for state-changing browser requests and stricter origin requirements for anonymous brief and funnel writes.
• Workspace membership, role-aware project access, plan-aware capability enforcement, and audit logs.
• Private-upload paths, presigned object access, configurable upload limits, and project ownership checks.
• Offline mutation conflict detection and an admin merge workflow rather than silent last-write-wins behavior.

Data boundaries

Account, project, build, runtime, and billing records are separated by owner and workspace identifiers. Product briefs use random opaque claim tokens stored only as hashes in the database. Conversion events are kept separate from audit logs and exclude the brief and direct identity data.

Production requirements

A public production launch requires operator-activated domain routing and trusted HTTPS, rotated secrets, working transactional email, backups and restore tests, monitoring and alerting, provider-specific credentials, app-store accounts, vulnerability review, and an incident response contact. Domain verification records do not activate routing or TLS by themselves. Mobile builds and other features that depend on missing credentials remain disabled instead of appearing to work.

Responsible reporting

Do not include passwords, access tokens, private customer data, or exploit details in public channels. The deployment operator must establish and publish a monitored security contact before commercial launch, then acknowledge, triage, and remediate credible reports under its incident process.