Web Application Security Checklist:
20 Things Before Launch.
A production-ready security checklist covering OWASP Top 10, transport security, authentication hardening, input validation, CSRF protection, and infrastructure configuration. Run this before you ship — and after every major release.
Written by
Sophie Hazel
Lead Developer & Founder, Gigassoftware
Security is the thing developers consistently push to "after launch." The checklist is always there, the deadline is always sooner, and the rationalizations are always available: "we'll add security before we onboard real users," "it's just an MVP," "we don't have any real data yet."
This is how breaches happen. Not through sophisticated zero-day exploits — through missing CSRF tokens, unvalidated redirects, and session tokens stored in localStorage instead of httpOnly cookies. The boring stuff. The checklist stuff.
Here are 20 security items that should be verified before any web application goes to production. This is what we check on every Gigassoftware build before a client sees the final deployment.
Transport Security
HTTPS on every endpoint — including subdomains
There should be no HTTP URLs in your application. Every link, every API call, every asset request should use HTTPS. Verify with a site crawler that no mixed content warnings exist.
HSTS header with long max-age and includeSubDomains
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. The max-age should be at least 1 year. includeSubDomains extends the policy to all subdomains. preload submits your domain to browser HSTS preload lists.
SSL/TLS rating of A or A+ on SSL Labs
Run your domain through ssllabs.com/ssltest. An A+ requires HSTS with preloading. Anything below A indicates misconfiguration — weak cipher suites, outdated TLS versions, or certificate chain issues.
HTTP redirects to HTTPS at the server level
Your web server (Nginx, Apache, Caddy) should redirect all HTTP traffic to HTTPS before your application code runs. Not handled in application code — handled in server config.
Security Headers
Content-Security-Policy (CSP)
Define exactly which sources your application loads scripts, styles, images, and fonts from. Start restrictive (default-src 'self') and add exceptions only as needed. CSP is the most effective mitigation for XSS attacks — injected scripts can't execute if they're not from an allowed source.
X-Frame-Options: DENY
Prevents your pages from being embedded in iframes, which eliminates clickjacking attacks. If you need to embed your own pages in iframes for legitimate reasons, use SAMEORIGIN instead of DENY.
X-Content-Type-Options: nosniff
Forces browsers to honor your declared Content-Type and prevents MIME-type sniffing. Without this, browsers may execute uploaded files as scripts even if served with a non-script content type.
Referrer-Policy: strict-origin-when-cross-origin
Controls how much referrer information is sent with cross-origin requests. This protects session tokens and user data from appearing in server logs of third-party sites you link to.
Permissions-Policy (formerly Feature-Policy)
Explicitly disable browser features you don't use: camera, microphone, geolocation, payment. Reduces the attack surface from XSS payloads and malicious third-party scripts.
Authentication and Session Management
Passwords hashed with bcrypt, Argon2, or scrypt
Never store plaintext passwords. Never use MD5 or SHA-1 for password hashing — these are not password hashing algorithms. Bcrypt with a work factor of 12+ is the minimum. Argon2id is the current best practice.
Rate limiting on authentication endpoints
Login, password reset, and account creation endpoints must have rate limiting. Without it, brute-force attacks are trivial. Implement per-IP and per-account rate limiting with exponential backoff and lockout after repeated failures.
Session tokens in httpOnly, Secure, SameSite cookies
Never store session tokens or JWTs in localStorage — they're accessible to any JavaScript on the page, which means any XSS vulnerability exposes every session. Use httpOnly cookies (not accessible to JS), Secure flag (HTTPS only), and SameSite=Strict or Lax.
JWT expiration and refresh token rotation
Access tokens should expire in 15–60 minutes. Refresh tokens enable seamless re-authentication without requiring login. Refresh token rotation means each use of a refresh token issues a new one and invalidates the old — detecting stolen refresh tokens.
Account enumeration protection on all auth flows
Login error messages should say 'Invalid email or password' — never 'No account found for this email.' Password reset flows should say 'If an account exists, we've sent an email' — never confirm or deny whether the email is registered. Account enumeration is a low-effort attack with high value for attackers.
Input Validation and Injection Prevention
Parameterized queries for all database operations
Never concatenate user input into SQL strings. Use parameterized queries or prepared statements in every database interaction. This eliminates SQL injection — the most destructive class of attack against web applications — entirely.
Server-side input validation on all endpoints
Client-side validation is a UX feature, not a security feature. Any attacker can bypass it with a direct API call. Validate type, format, length, and allowed values on every server endpoint, regardless of what the client sent.
File upload validation — type, size, and execution prevention
If your application accepts file uploads, validate MIME type server-side (not just file extension), enforce size limits, store uploads outside the webroot, and never execute uploaded files. Scan uploads with a malware detection library if handling untrusted sources.
CSRF protection on all state-changing requests
Cross-Site Request Forgery tricks authenticated users into making requests they didn't intend. Mitigation: synchronizer token pattern (CSRF token in form + cookie, validated server-side), or SameSite=Strict cookies for session management. Verify the Origin/Referer header on sensitive state-changing endpoints.
Error Handling and Information Exposure
Production error messages expose nothing internal
Stack traces, database error messages, file paths, and server version information should never reach production users. Log errors server-side with full detail. Return generic error messages to clients. Verify by triggering deliberate errors in production and checking what the user sees.
Dependency vulnerability scanning in CI/CD
Your application inherits the vulnerabilities of every package it depends on. Run npm audit, composer audit, or the equivalent for your package manager on every build. Configure automated alerts for newly discovered vulnerabilities in your dependencies. Update dependencies on a regular schedule, not just when forced to.
Beyond the Checklist: Infrastructure Security
The 20 items above cover application-level security. Production infrastructure has its own security requirements that this checklist doesn't cover in depth:
- Firewall rules: Only expose the ports your application actually uses. Database ports (5432, 3306) should never be publicly accessible.
- Database access controls: The database user your application uses at runtime should have minimum permissions. No superuser access, no access to tables the application doesn't use.
- Environment variable security: Secrets (API keys, database passwords, signing keys) should never be in code or version control. Use environment variables and a secrets management solution.
- Server access: SSH with key authentication only — no password-based SSH access. Disable root SSH login. Use a bastion host for production server access.
- Backup encryption: Database backups should be encrypted at rest. Test backup restoration regularly — an untested backup is not a backup.
This Checklist and the OWASP Top 10
The OWASP Top 10 is the standard reference for web application security risks. Here's how this checklist maps to the 2021 OWASP Top 10:
For a deeper implementation guide on zero trust principles that underpin several of these items, see our zero trust security guide. If you want an external team to run through these items on your application and produce a written report with remediation guidance, our security audit service covers all 20 items above plus infrastructure review.
FAQ: Web Application Security
What should be on a web application security checklist?
At minimum: HTTPS and HSTS, security headers (CSP, X-Frame-Options, etc.), authentication hardening (rate limiting, secure session management), input validation and SQL injection prevention, CSRF protection, dependency vulnerability scanning, and production error handling that doesn't expose internals.
What is the OWASP Top 10?
The OWASP Top 10 is the authoritative list of the most critical web application security risks, maintained by the Open Web Application Security Project. The 2021 list covers Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Software Integrity Failures, Logging Failures, and SSRF.
How often should I run a security checklist?
Run the full checklist before every major release and after any significant infrastructure change. Dependency vulnerability scanning should run continuously in CI/CD. A formal external security audit should happen annually or before processing sensitive user data.
What is the difference between a security checklist and a security audit?
A security checklist is self-administered verification of known controls. A security audit is an external expert evaluation including manual testing, code review, and threat modeling. Checklists catch configuration mistakes; audits find architectural flaws and novel vulnerabilities that checklists don't cover.
Want an Expert Eye on Your Security?
Our security audit covers all 20 checklist items plus infrastructure review, with a written report and remediation guide delivered within 5 business days.