For the complete documentation index, see llms.txt. Prefer markdown by appending .md to documentation URLs or sending Accept: text/markdown.

Checklist

A pre-launch security checklist covering secrets, auth, API authorization, webhooks, storage, and dependency hygiene.

Use this checklist before your first production deploy, and again after major features that touch auth, billing, or file uploads. Pair it with the general deployment checklist.

Secrets & configuration

  • No secrets committed to git (only .env.example placeholders)
  • Production secrets set in the host / CI - not in committed .env files
  • No sensitive values use the NEXT_PUBLIC_ prefix
  • BETTER_AUTH_SECRET is a long random value unique to production
  • URL / NEXT_PUBLIC_URL match the real production origin
  • Billing webhook secrets match the live provider endpoint
  • Seed credentials are disabled or changed in production

Authentication

  • Email verification enabled for password sign-up
  • OAuth callback URLs point at production
  • trustedOrigins includes only the apps you ship (web, mobile scheme, extension)
  • 2FA / passkeys available for accounts that need them
  • Dashboard and admin layouts still redirect unauthenticated users

Authorization & tenancy

  • New API routes use enforceAuth (and permission middleware when needed)
  • Admin routes also use enforceAdmin
  • Organization-scoped queries filter by a verified org id
  • Client-side permission checks are mirrored on the server
  • Server Actions authenticate and authorize internally

Validation

  • Mutation endpoints validate bodies with Zod via validate
  • Schemas are allowlists (no unbounded passthrough objects)
  • File upload paths and content types are constrained

Integrations

  • Billing webhooks verify signatures before updating customers
  • Background task endpoints verify QStash (or equivalent) signatures
  • Storage buckets are private; uploads go through presigned URLs
  • Provider API keys are only imported from ./server / server env presets
  • Error monitoring scrubbers hide cookies, tokens, and secrets

TurboStarter does not force a Content Security Policy out of the box - enable one when you are ready to inventory third-party scripts (analytics, payments, fonts).

  • HTTPS only in production
  • Consider security headers (Content-Security-Policy, Referrer-Policy, X-Frame-Options / frame-ancestors, Permissions-Policy)
  • If you add a strict CSP, pass nonces to any required inline scripts and allowlist payment / analytics origins deliberately

Dependencies & process

  • pnpm lockfile committed; installs are reproducible
  • Dependencies updated for known Next.js / React advisories
  • Access to production env and database is limited to the team that needs it
  • Webhook and auth failures are visible in logs / monitoring

Ship with confidence

You do not need every optional hardening step on day one, but you do need correct secrets, server-side authz, validated input, and verified webhooks. Those four prevent the most common SaaS incidents.

How is this guide?

Last updated on

On this page

Ship your startup everywhere. In minutes.Try TurboStarter