The Startup Security Checklist

Short passwords are cracked in seconds with modern GPUs. Require a minimum of 12 characters and encourage passphrases. Use a library like zxcvbn for strength estimation rather than rigid rules.

MD5 and SHA1 are fast hashing algorithms, which is bad for passwords. Attackers can try billions of guesses per second. Use bcrypt (cost factor 12+) or argon2id, which are deliberately slow.

Without lockout, attackers can try unlimited password combinations. Lock accounts after 5 failures for 15 minutes. Also implement progressive delays (1s, 2s, 4s) to slow automated attacks.

Storing tokens in localStorage or sessionStorage exposes them to XSS attacks. HttpOnly cookies prevent JavaScript access. The Secure flag ensures cookies are only sent over HTTPS.

Abandoned sessions are a common attack vector. Set idle timeouts to 30 minutes for regular users, 15 minutes for admin sessions. Implement server-side session invalidation.

Passwords alone aren't enough for privileged accounts. Implement TOTP-based MFA (Google Authenticator, Authy) for all admin and owner roles. WebAuthn/passkeys are even more secure.

Reset tokens sent via email should be single-use and time-limited. One hour is generous. Also invalidate the token if the user logs in before using it.

Client-side token deletion isn't enough. The token might still be valid if intercepted. Add a server-side deny list for logged-out tokens, or use short-lived JWTs with refresh token rotation.

Without rate limits, attackers can brute-force logins, enumerate users, or run up your cloud bill. Implement per-IP and per-user rate limits. Use tiered limits: stricter on auth endpoints, more relaxed on reads.

A wildcard CORS policy (Access-Control-Allow-Origin: *) lets any domain make requests to your API. Restrict to your actual frontend origins. Never reflect the Origin header without validation.

Never trust user input. Validate types, lengths, formats, and ranges on every API endpoint. Libraries like Zod (TypeScript) or Joi (Node.js) make this easy and catch issues early.

URLs appear in server logs, browser history, referrer headers, and analytics tools. Never put tokens, passwords, or PII in query parameters. Use request bodies or headers instead.

Version your API from day one (v1). This lets you make breaking changes without disrupting existing clients. Use URL prefixing (/api/v1/) or header-based versioning.

Without size limits, attackers can send massive payloads to exhaust server memory. Set reasonable limits: 1MB for JSON bodies, smaller for specific endpoints. Use streaming for file uploads.

HSTS tells browsers to always use HTTPS, preventing SSL stripping attacks. Set max-age to at least 31536000 (1 year). Include includeSubDomains and consider preload once stable.

CSP prevents XSS by restricting which scripts can execute. Start with a restrictive policy and loosen as needed. At minimum: default-src 'self'; script-src 'self'.

Prevents your application from being embedded in iframes, blocking clickjacking attacks. Set to DENY unless you specifically need iframe embedding, then use SAMEORIGIN.

Prevents browsers from MIME-sniffing responses, which can lead to XSS via uploaded files. Always set this header. There's no reason not to.

Controls how much URL information is sent in the Referer header. Set to strict-origin-when-cross-origin to prevent leaking internal URLs to third parties.

Restricts which browser features your application can use (camera, microphone, geolocation). Disable everything you don't need to reduce your attack surface.

This header reveals your server technology (Express, PHP, etc.), helping attackers find version-specific exploits. Remove it. It provides no value to legitimate users.

All traffic must be encrypted. Redirect HTTP to HTTPS. Use HSTS to ensure browsers never attempt unencrypted connections. Get certificates from Let's Encrypt. They're free.

Never hardcode API keys, database passwords, or tokens in source code. Use environment variables and a secrets manager (AWS Secrets Manager, Doppler, or .env files locally).

Any key in your frontend bundle is public. Use server-side API routes to proxy requests that need secret keys. Audit your bundles regularly for leaked credentials.

Automated daily backups aren't enough. You must test restores. An untested backup is not a backup. Schedule quarterly restore tests and document the procedure.

Encrypt personally identifiable information in your database using AES-256. Use column-level encryption for sensitive fields. Ensure encryption keys are stored separately from data.

Audit your logging to ensure sensitive data is never written to logs. Redact passwords, tokens, and PII before logging. Use structured logging with explicit field selection.

Run npm audit, pip audit, or equivalent regularly. Better yet, automate it with Dependabot, Snyk, or Cybrove's GitHub Scanning. One vulnerable dependency can compromise everything.

Search your codebase for strings like "password", "secret", "api_key". Check git history too. Deleted secrets are still in old commits. Use Cybrove's GitHub Scanner to automate this.

Source maps expose your original source code to anyone who opens browser devtools. Disable them in production builds. If you need them for error tracking, use private source maps.

Environment files contain secrets and should never be committed. Add .env* to .gitignore before your first commit. If already committed, rotate all secrets immediately.

Automated dependency updates catch vulnerabilities before you notice them. Enable Dependabot, Renovate, or a similar tool to submit PRs when new versions fix security issues.

Your database should only accept connections from your application servers, never from the public internet. Use VPC/private networking and firewall rules to restrict access.

Password-based SSH is vulnerable to brute force. Use SSH key pairs, disable password authentication, and disable root login. Consider using a bastion host for production access.

Only expose the ports you need (typically 80, 443). Close everything else. Use security groups or iptables to restrict traffic. Audit open ports regularly.

You need to know when things break. Set up uptime monitoring, error tracking (Sentry), and resource alerts (CPU, memory, disk). Include security event alerts for failed logins and suspicious activity.

When a security incident happens (not if), you need a plan. Document: who to contact, how to contain, how to investigate, and how to communicate. Practice it before you need it.