Back to blog
Security 8 min read28 May 2026

Web App Security Checklist for SaaS Founders (2026)

The security issues that get SaaS startups breached aren't exotic zero-days — they're boring, preventable mistakes. Here's the checklist we run on every product we ship.

Security SaaS OWASP Authentication Best Practices
H

Hanuman Singh

Founder & Lead Engineer · Hanuman Software Services

Security is a feature, not an afterthought

Most SaaS breaches don't happen because of sophisticated attacks. They happen because of SQL injection in a forgotten endpoint, an S3 bucket left public, or a JWT secret committed to GitHub. These are preventable. Here's the checklist we run through before every production launch.

Authentication & sessions

  • Use an auth provider (Clerk, Auth0, Supabase Auth). Don't roll your own auth. The surface area for mistakes is enormous.
  • Enforce MFA for admin accounts. A compromised admin account is a compromised product.
  • Set secure, httpOnly, sameSite cookies. Never store JWTs in localStorage — XSS can steal them. Use httpOnly cookies instead.
  • Short-lived access tokens (15–60 min) with refresh token rotation. If a token leaks, the damage window is small.
  • Rate-limit login endpoints. 5 attempts, then lockout or CAPTCHA. Without this, credential stuffing is trivial.

Data & database

  • Parameterised queries everywhere. No string concatenation in SQL. Ever. ORM default behaviour is usually safe — raw queries are where mistakes happen.
  • Encrypt sensitive fields at rest. PII, payment data, health records — encrypt at the column level, not just disk encryption.
  • Database connection via private network only. Your RDS/Postgres instance should not be publicly accessible. Only your application server should reach it.
  • Daily automated backups with tested restores. Backups you've never restored are not backups.
  • Principle of least privilege on DB users. Your app's database user should not have DROP TABLE permissions.

API security

  • Validate and sanitise all input at the API boundary. Use Zod, Joi, or equivalent. Assume every request is malicious.
  • Authorisation checks on every endpoint. "Can this user perform this action on this resource?" — not just "is this user logged in?"
  • Rate limiting on all public endpoints. AWS WAF, Cloudflare, or a simple Redis-backed rate limiter.
  • CORS configured correctly. Don't use * in production. Explicitly list allowed origins.

Infrastructure

  • No secrets in environment variables committed to git. Use a secrets manager (AWS Secrets Manager, Doppler, or at minimum a .env file in .gitignore).
  • S3 buckets private by default. Block all public access at the account level. Use pre-signed URLs for user file access.
  • Enable CloudTrail / audit logging. You need to know who did what and when, especially after an incident.
  • Dependency scanning in CI. npm audit, Snyk, or Dependabot. Known vulnerabilities in dependencies are the easiest attack vector.

Before you launch

Run through OWASP Top 10. Set up error monitoring (Sentry) so you see when unusual errors spike. Enable alerts for failed login attempts and unusual API traffic patterns.

Security doesn't have to be expensive. Most of this list costs nothing but time. The cost of getting it wrong — a breach, GDPR fines, loss of customer trust — is orders of magnitude higher.

We include a security review as part of every production launch we ship. Talk to us if you want a second pair of eyes on your architecture.

Interested in working together?

Free 30-minute discovery call — no commitment.

Book a call