SaaS Security Checklist
A production SaaS product needs security controls across 7 layers: authentication, database, API, infrastructure, billing, monitoring, and compliance. The six controls that must be in place before any user signs up: httpOnly JWT cookies, RLS on all tenant tables, Zod input validation, Stripe webhook verification, auth rate limiting, and HTTPS with HSTS.
Security issues found after launch with real user data cost 10–100× more to fix than the same issues found before launch. This checklist is run before every 4Byte SaaS goes live.
▸ Critical Controls
Six controls that must be in place before any user signs up
Every other security control is important — but these six are the ones where missing them causes immediate, exploitable vulnerabilities with real-world consequences.
httpOnly cookies for JWT storage
localStorage is accessible to JavaScript — one XSS bug exposes every user's session token. httpOnly cookies are completely inaccessible to scripts.
RLS on every tenant table
Application-layer scoping has bugs. RLS is the database-level guarantee that no bug in your API code can ever expose one tenant's data to another.
Zod input validation on all API routes
Unvalidated input is the root cause of SQL injection, prototype pollution, and unexpected application behaviour. Validate before any database operation.
Stripe webhook signature verification
Without verification, anyone can send fake payment success events to your webhook endpoint and fraudulently upgrade their account.
Rate limiting on auth endpoints
Unprotected login and signup endpoints can be used for credential stuffing, brute force attacks, and email bombing at scale.
HTTPS with HSTS header
HTTP exposes all data in transit including session tokens. HSTS prevents browsers from ever connecting over HTTP even if the user types it manually.
▸ Full Security Checklist
50+ security controls across seven layers
This is the complete security checklist 4Byte Agency runs before every SaaS product goes live. Controls marked Critical must be in place before the first user signs up.
Authentication Security
Database & Data Security
API & Application Security
Infrastructure & Network Security
Billing & Payment Security
Monitoring & Incident Response
Compliance & Privacy
▸ Security Headers
Six HTTP security headers every SaaS product must set
These headers are configured in next.config.js under the headers() array. They cost nothing to add and eliminate multiple attack vectors.
Strict-Transport-Securitymax-age=31536000; includeSubDomains; preloadContent-Security-Policydefault-src 'self'; script-src 'self' 'nonce-{nonce}'; style-src 'self' 'unsafe-inline'X-Frame-OptionsDENYX-Content-Type-OptionsnosniffReferrer-Policystrict-origin-when-cross-originPermissions-Policycamera=(), microphone=(), geolocation=()Add to next.config.js
headers: async () => [{
source: '/(.*)',
headers: [
{ key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains' },
{ key: 'X-Frame-Options', value: 'DENY' },
{ key: 'X-Content-Type-Options', value: 'nosniff' },
]
}]▸ Pre-Launch Summary
Security by layer — at a glance before you go live
Run through this summary the week before launch. Every category must pass before real users touch your product.
Auth
10 items- httpOnly JWT cookies
- Email verification
- Rate limiting on auth
- PKCE for OAuth
- Session invalidation on password change
- + 5 more…
Database
10 items- RLS on all tenant tables
- Cross-tenant leak test
- No raw SQL concat
- Service key server-side only
- Encrypted sensitive fields
- + 5 more…
API
10 items- Zod input validation
- RBAC middleware
- Org scoping on all queries
- CORS restricted to origin
- Error responses sans stack traces
- + 5 more…
Infrastructure
10 items- HTTPS + HSTS
- CSP header configured
- No secrets in NEXT_PUBLIC_
- Env vars per environment
- Dependency scan in CI
- + 5 more…
Billing
8 items- Webhook sig verification
- State via webhooks only
- Stripe key server-side
- No card data on your servers
- + 4 more…
Monitoring
8 items- Sentry error tracking
- Uptime monitoring
- Audit log table
- Alert on auth failure burst
- + 4 more…
Compliance
5 items- Privacy Policy published
- Terms of Service accepted
- User data export available
- Account deletion process
- + 1 more…
▸ Security Mistakes
Security mistakes that cause real breaches in production
These four mistakes appear repeatedly in SaaS security incidents. All are preventable and all are expensive once they've occurred with live user data.
Storing sensitive data in client-visible environment variables
Consequence
Any variable prefixed NEXT_PUBLIC_ is bundled into client-side JavaScript and visible to every user in the browser. Stripe secret keys, database URLs, and internal API keys exposed this way cause full platform compromise.
4Byte Standard
Only use NEXT_PUBLIC_ prefix for non-sensitive values. All secret keys, database URLs, and internal service tokens stay server-side only — never prefixed NEXT_PUBLIC_.
Testing RLS policies only for authorised access
Consequence
Teams verify that permitted users can read their data but never verify that non-members cannot. An RLS policy that's missing or misconfigured allows cross-tenant reads — which only shows up when tested from the wrong session.
4Byte Standard
Create a dedicated security test suite that explicitly attempts to read Organisation A's data from Organisation B's session. RLS must fail — not just succeed for authorised access.
Committing secrets to version control
Consequence
Even if a secret is committed and immediately deleted, it remains in git history permanently. Automated scanners continuously harvest secrets from GitHub repositories within minutes of a push.
4Byte Standard
Use .gitignore for all .env files from the first commit. Use a secrets manager (Doppler, Vercel env vars) for production. Rotate any secret that has ever touched version control.
No security review before launch
Consequence
Security issues found after launch with real users and real data cost 10–100× more to fix than the same issues found before launch. Data breaches post-launch carry regulatory and reputational consequences.
4Byte Standard
Run a pre-launch security checklist covering all 7 layers before any production deployment. This doesn't require a penetration test — systematic checklist review catches the most common and highest-impact vulnerabilities.
▸ FAQ
Frequently asked questions about SaaS security
What are the most important security controls for a SaaS product?+
The most critical SaaS security controls are: JWT tokens in httpOnly cookies, row-level security on every tenant table, Zod input validation on all API routes, rate limiting on auth endpoints, Stripe webhook signature verification, HTTPS with HSTS, and dependency scanning in CI/CD.
How do you prevent cross-tenant data leakage in a SaaS product?+
Cross-tenant data leakage is prevented through two layers: application-level scoping (all queries include WHERE organisation_id = current_org_id) and database-level RLS policies (PostgreSQL enforces tenant boundaries even if application code has a bug). Both must exist.
What security headers should a SaaS product set?+
Essential SaaS security headers: Strict-Transport-Security (enforces HTTPS), Content-Security-Policy (prevents XSS), X-Frame-Options: DENY (prevents clickjacking), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy.
Is SaaS GDPR compliance required?+
GDPR compliance is required if your SaaS processes personal data of EU residents — regardless of where your company is based. Core requirements: privacy policy, DPA for B2B customers, user data export and deletion on request, and defined data retention policies.
How should SaaS environment variables and secrets be managed?+
Never commit secrets to version control. Use environment variables per environment (dev/staging/production). Store secrets in Vercel environment variables or a secrets manager like Doppler. Rotate any secret exposed in version control immediately. Audit production secret access quarterly.
How does 4Byte Agency approach SaaS security?+
4Byte Agency implements security-first across every build: RLS from migration zero, httpOnly JWT storage, Zod input validation on all routes, rate limiting on auth, HTTPS with security headers, Stripe webhook verification, dependency scanning in CI/CD, and a pre-launch security review across all 7 layers.
▸ Related Resources
Go deeper into SaaS security
▸ Ship securely from day one
Want your SaaS product built with all 50+ controls in place?
We implement every control on this checklist — authentication hardening, RLS from migration zero, API validation, security headers, Stripe verification, and monitoring — before a single user signs up.