Web Security for SaaS Founders: A Practical Checklist (2026)

Web Security for SaaS Founders: A Practical Checklist (2026)

Security debt in SaaS compounds faster than technical debt. A startup that skips rate limiting and proper session management at launch will eventually face credential stuffing attacks, account takeovers, or a data breach — at exactly the moment when the company has enough users to make the damage significant and enough visibility to make the reputational cost severe.

This checklist is organized into six categories and distinguishes between items that must be in place before you accept your first paying customer versus items that can be implemented progressively after launch. It is not exhaustive — security is never truly finished — but it covers the vulnerabilities that consistently appear in post-breach investigations of SaaS companies.

Pre-Launch vs. Post-Launch: The Right Mental Model

Not all security controls carry equal urgency. A rigid "implement everything before launch" approach delays you indefinitely. A cavalier "ship now, secure later" approach is how companies end up on breach notification pages.

The framework: anything that is significantly harder to retrofit than to build correctly the first time belongs pre-launch. Authentication architecture, data encryption, and session management fall here. A security awareness training program for employees does not.

Category 1: Authentication and Session Management

Authentication is the boundary between your application and the internet. Getting it wrong has outsized consequences.

Pre-Launch

• [ ] 1. Implement password hashing with bcrypt or Argon2 (minimum cost factor 12 for bcrypt). Never SHA-256, MD5, or plain text. This cannot be changed after you have users without forcing password resets.

• [ ] 2. Enforce minimum password complexity — 12 characters minimum, no maximum below 64 characters. Reject the 100 most common passwords (use the Have I Been Pwned password list). Do not require complexity rules that reduce entropy (forced special chars actually make passwords weaker on average).

• [ ] 3. Implement proper session management — generate cryptographically random session IDs (128 bits minimum), invalidate sessions on logout at the server side, rotate session IDs after privilege changes (login, role change), expire sessions after configurable inactivity.

• [ ] 4. Prevent brute force attacks — rate limit login attempts by IP and by account (5 attempts per 5 minutes is reasonable), implement exponential backoff for repeated failures, lock accounts after sustained attack with user notification.

• [ ] 5. Implement secure cookie attributes:

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=86400

HttpOnly prevents JavaScript cookie access. Secure prevents transmission over HTTP. SameSite=Strict prevents CSRF via cross-origin form submissions.

Post-Launch (within 90 days)

• [ ] 6. Add multi-factor authentication — TOTP (Google Authenticator/Authy) as a minimum, WebAuthn/passkeys for higher security tiers. Make MFA optional initially; make it enforceable by admins for B2B customers.

• [ ] 7. Implement OAuth/SSO for enterprise customers — SAML 2.0 or OIDC. This is a sales requirement for enterprise deals, not just a security feature.

• [ ] 8. Monitor for credential stuffing — detect accounts being logged into with breached credential lists. Services like Have I Been Pwned''s API can check new signups against known breach data.

Category 2: Data Security

• [ ] 9. Encrypt all data in transit — TLS 1.2 minimum, TLS 1.3 preferred, on every endpoint. No mixed content. Deploy HSTS:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• [ ] 10. Encrypt database at rest — verify your managed database provider has encryption at rest enabled (most do by default; confirm it). For backups, ensure they are also encrypted.

• [ ] 11. Implement field-level encryption for sensitive PII — SSNs, payment card data (or better: never store it and use Stripe''s tokenization), health data, government ID numbers. Disk-level encryption is not sufficient for these categories.

• [ ] 12. Define and enforce data retention policies — delete user data when accounts are closed (or within your defined retention window). Automated deletion is better than manual processes. Document retention periods for GDPR/CCPA compliance.

• [ ] 13. Prevent SQL injection everywhere — use parameterized queries or prepared statements in all database interactions. Audit raw query methods. Establish a code review policy requiring sign-off on any $queryRaw, literal(), or string-concatenated query.

Category 3: API Security

APIs are frequently the least-protected attack surface in SaaS applications, especially when built quickly to support integrations.

Pre-Launch

• [ ] 14. Implement authentication on every API endpoint — no unauthenticated endpoints except those explicitly designed for public access. Default to requiring authentication; add public access deliberately.

• [ ] 15. Implement authorization checks, not just authentication — verify that the authenticated user is authorized to access the specific resource they are requesting. Insecure Direct Object Reference (IDOR) vulnerabilities are among the most common SaaS API findings:

// Vulnerable — only checks authentication
app.get(''/api/invoices/:id'', authenticate, async (req, res) => {
  const invoice = await Invoice.findById(req.params.id);
  res.json(invoice);
});

// Secure — checks authorization too
app.get(''/api/invoices/:id'', authenticate, async (req, res) => {
  const invoice = await Invoice.findOne({
    _id: req.params.id,
    organizationId: req.user.organizationId // Must belong to user''s org
  });
  if (!invoice) return res.status(404).json({ error: ''Not found'' });
  res.json(invoice);
});

• [ ] 16. Rate limit all API endpoints — both public and authenticated. Implement per-user, per-IP, and per-endpoint limits. Return 429 Too Many Requests with a Retry-After header.

Post-Launch

• [ ] 17. Implement API key rotation — allow customers to rotate their API keys without service interruption. Log API key usage with request metadata (endpoint, timestamp, IP) for security investigation.

• [ ] 18. Add API versioning and deprecation policy — older API versions maintained past their useful life accumulate security debt. Define a deprecation window and enforce it.

Category 4: Infrastructure Security

• [ ] 19. Deploy all security headers:

Content-Security-Policy: default-src ''self''; script-src ''self''; ...
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), interest-cohort=()

• [ ] 20. Harden your cloud storage — no public S3 buckets (or GCS, Azure Blob) unless serving deliberate public content. Enable Block Public Access settings at the account level. Use pre-signed URLs for temporary access to private assets.

• [ ] 21. Manage secrets properly — no secrets in source code, environment files committed to repositories, or logs. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for production credentials. Rotate secrets on employee departure.

• [ ] 22. Keep dependencies updated — run npm audit or pip-audit in CI. Configure Dependabot or Renovate for automated pull requests on dependency updates. Establish SLA: critical CVEs patched within 72 hours.

• [ ] 23. Implement CORS correctly — explicit allowlist of trusted origins, not Access-Control-Allow-Origin: * for authenticated APIs. Review CORS configuration when adding new frontend domains.

Category 5: Monitoring and Incident Response

Post-Launch (start as soon as you have users)

• [ ] 24. Implement centralized logging — structured logs (JSON) for all requests, authentication events, errors, and data access. Retain for 90 days minimum (1 year for regulated industries).

• [ ] 25. Set up security alerting — alert on: repeated authentication failures, admin panel access from new IPs, unusually large data exports, configuration changes to production infrastructure.

• [ ] 26. Monitor for dependency vulnerabilities — GitHub Dependabot alerts, Snyk, or similar. A known CVE in your production dependencies is not a theoretical risk — it is a timer.

• [ ] 27. Run continuous security scanning — deploy ZeriFlow to scan your production URL on a schedule and alert when your security score drops (headers removed, TLS downgraded, DNS records changed). Integrate with your Slack or Discord for real-time notifications.

• [ ] 28. Document an incident response plan — who gets called at 2am? What is the triage process? What is the template for breach notification emails? Prepare this before you need it.

Category 6: Compliance and Trust

• [ ] 29. Publish a vulnerability disclosure policy — make it easy for security researchers to report issues responsibly. A simple security.txt file at /.well-known/security.txt and a security@yourcompany.com address is a minimum:

# /.well-known/security.txt
Contact: mailto:security@yourcompany.com
Expires: 2027-01-01T00:00:00z
Preferred-Languages: en

• [ ] 30. Prepare for SOC 2 early — SOC 2 Type II certification is required for enterprise sales in most verticals. Starting the documentation process early (user access reviews, change management, incident logging) means you are building evidence continuously rather than scrambling to reconstruct it before an audit.

The Shortcuts That Cause Problems

A few specific patterns appear repeatedly in SaaS breach post-mortems:

Storing secrets in source code — developers add API keys to code "temporarily" and forget them. A public GitHub repository with live credentials is typically exploited within minutes. Audit your entire commit history before making any repository public.

CORS wildcard on authenticated APIs — added during development for convenience, left in place at launch. Enables CSRF attacks against authenticated users.

No rate limiting on password reset — password reset flows are frequently used for account enumeration (different responses for existing vs. non-existing accounts) and for spam attacks. Rate limit and normalize responses.

JWT without expiry — JWTs issued without an exp claim do not expire. An attacker who captures one has permanent access. Set short lifetimes (15-60 minutes) with refresh token rotation.

Logging sensitive data — logging full request bodies or user-provided data for debugging, then forgetting to remove it before production. Review your log output explicitly for sensitive data patterns.

ZeriFlow automates the infrastructure and header security portion of this checklist — running 80+ checks against your live URL and giving you a prioritized remediation list with your security score. Use it after each deployment to verify your security posture has not regressed. Free tier at zeriflow.com, no credit card required.