Most SaaS security failures aren't exotic — they're missed basics. A checklist worth running through before launch, and before your first customer's security team asks you about it in a procurement questionnaire.
Authentication and access
- Passwords hashed with a modern algorithm (bcrypt/argon2), never stored in plain text or reversible encryption.
- Session tokens expire and can be revoked — a logged-out session should actually be dead, not just hidden client-side.
- Rate limiting on login and password-reset endpoints, to slow down credential-stuffing attempts.
- Role-based access enforced server-side, not just hidden in the UI — a hidden button is not access control.
Data isolation (the multi-tenant basics)
- Every database query that touches customer data is scoped to that customer's tenant ID — checked in code review, not assumed.
- Test accounts and staging data are never in the same database as production customer data.
- File uploads are validated for type and size, and stored somewhere that can't execute arbitrary code.
Secrets and infrastructure
- API keys, database credentials, and signing secrets live in environment variables or a secrets manager — never committed to the repository, ever, including in a "temporary" test commit.
- TLS everywhere — no plain HTTP endpoints for anything handling real data.
- Admin/internal tools are not reachable from the public internet without their own auth layer.
Dependencies and ongoing hygiene
- A dependency audit (npm audit or equivalent) run before launch, with known critical vulnerabilities actually addressed, not just logged.
- A process for applying security patches after launch — this is a standing responsibility, not a one-time launch checklist item. See our note on why AI-generated code still gets human review for the same reasoning applied to dependencies.
- Error messages and logs don't leak sensitive data (stack traces, internal paths, other users' data) to end users.
Why this list matters more than it looks
None of this is exotic red-team-level work — it's the stuff that gets skipped when a team is racing to ship an MVP on a tight timeline, and it's exactly the stuff that shows up in a customer's security questionnaire six months later, or worse, in an actual incident. Building it in during development costs a fraction of what retrofitting it into a live product with real customer data costs — the same logic as our note on GDPR compliance for SaaS.
Every build we ship gets threat modelling, a dependency audit, and access-control review before launch, regardless of pricing tier — see what's included on our SaaS products page.