For the complete documentation index, see llms.txt. Prefer markdown by appending.mdto documentation URLs or sendingAccept: 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.exampleplaceholders) - Production secrets set in the host / CI - not in committed
.envfiles - No sensitive values use the
NEXT_PUBLIC_prefix -
BETTER_AUTH_SECRETis a long random value unique to production -
URL/NEXT_PUBLIC_URLmatch 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
-
trustedOriginsincludes 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
Headers & transport (recommended)
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
-
pnpmlockfile 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