Security checklist before launching your SaaS startup
By Kike Gandia · Co-Founder & CEO, OSCP · Last updated:
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). ☐ Multi-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). ☐ Separate environment variables for each environment (dev, staging, prod). ☐ .gitignore correctly configured to exclude .env files. ☐ Git history reviewed to make sure secrets were never committed.
Input validation and injection protection
☐ All user input is validated on the server (never only on the client). ☐ Parameterized database queries or an ORM (never string concatenation). ☐ HTML sanitization to prevent XSS (DOMPurify or equivalent). ☐ CSRF protection on forms and mutations. ☐ Rate limiting on all public APIs.
Access control and authorization
☐ Principle of least privilege: each user accesses only what they need. ☐ Authorization 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 AEPD, the Spanish Data Protection Agency).
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 for any web application. You can prioritize the rest 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.