Security checklist before launching your SaaS startup

By the QuantumSec team

You're about to launch. The product works, the team is excited, your first users are waiting. Before you hit the button, there's a set of security controls you should have reviewed. Not to be perfect (no system is), but to avoid the mistakes that make a breach a matter of days rather than years.

Authentication and session management

Passwords hashed with bcrypt, scrypt or Argon2 (never MD5 or SHA1). Two-factor authentication (MFA) available for users, mandatory for admins. Session tokens with expiry and revocation. Brute-force protection: rate limiting and temporary account lockout. Secure password recovery flow (single-use tokens with short expiry). OAuth/OIDC correctly configured if you use social login.

Encryption and data protection

HTTPS across the entire application with TLS 1.2+ (preferably TLS 1.3). Sensitive data encrypted at rest (payment data, health data, critical personal data). Valid SSL/TLS certificates with automatic renewal (Let's Encrypt). HTTP security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options. Cookie policy: Secure, HttpOnly, SameSite.

Secrets management and configuration

No credentials or API keys in the source code or the git repository. Secrets managed with a dedicated service (AWS Secrets Manager, HashiCorp Vault, Doppler). Environment variables separated by environment (dev, staging, prod). .gitignore correctly configured to exclude .env files. Review of the git history to ensure secrets were never committed.

Input validation and injection protection

All user input is validated on the server (never only on the client). Parameterised database queries or an ORM (never string concatenation). HTML sanitisation to prevent XSS (DOMPurify or equivalent). CSRF protection on forms and mutations. Rate limiting on all public APIs.

Access control and authorisation

Principle of least privilege: each user accesses only what they need. Authorisation checks on the server at every endpoint (not just in the frontend). IDOR testing: can user A access user B's resources by changing the ID? Clear separation between roles (admin, user, read-only, etc.). Access to administrative functions restricted by IP or requiring additional MFA.

Logging, monitoring and incident response

Authentication logs: failed attempts, password changes, access from new IPs. Logs of sensitive actions: data deletion, configuration changes, exports. Alerts for anomalous patterns: multiple login failures, scraping, access at unusual hours. Basic documented incident response plan: who to notify, how to contain, how to communicate. Documented breach notification process under GDPR (72 hours to the supervisory authority).

FAQ

Do I have to implement all of this from day one?

The items in the authentication, encryption and secrets management sections: yes, from day one. They're the bare minimum floor for any web application. The rest you can prioritise based on the type of data you handle and the profile of your first users. But bear in mind it's far easier and cheaper to implement them from the start than to remediate later with real users.

Is this checklist enough or do I also need a penetration test?

The checklist helps you avoid the most obvious mistakes. The pentest tells you whether, even after following the checklist, there are vulnerabilities in your specific implementation that an attacker could exploit. The two are complementary: the checklist is your baseline, the pentest validates that you've actually reached it.