Web App Security Checklist for Engineers

Auth & sessions

0/5

Hash passwords with a slow, purpose-built algorithm like bcrypt or argon2, never a fast general hashFast hashes like MD5 or plain SHA-256 let an attacker with a stolen database try billions of guesses per second.
Regenerate the session ID on login, not just on logoutReusing a pre-login session ID after authentication enables session fixation, where an attacker plants a known ID and waits.
Set session cookies with HttpOnly, Secure, and an appropriate SameSite attributeHttpOnly blocks JavaScript access to the cookie, closing the main way a cross-site scripting bug turns into session theft.
Enforce authorization checks on the server for every request, not just hiding UI on the clientA hidden button is not an access control — anyone can call the underlying endpoint directly.
Expire sessions after inactivity and cap how long a token remains validA session with no expiry stays exploitable indefinitely if it's ever stolen or left logged in on a shared device.

0/5

Use parameterized queries or an ORM for every database call, never string-concatenated SQLThis is what closes off SQL injection at the root, regardless of how input is otherwise validated.
Escape or encode all user-controlled output rendered into HTMLThis is what stops stored or reflected cross-site scripting from executing in another user's browser.
Validate uploaded file type and size on the server, not just via the accept attribute in the formThe accept attribute is a UI hint only — it does nothing to stop a request sent directly to the endpoint.
Enforce a strict allowlist for any input used to build a file path or shell commandPath traversal and command injection both come from trusting input that reaches the filesystem or a shell unchecked.
Set reasonable size and rate limits on every endpoint that accepts user inputWithout limits, a single request can exhaust memory, disk, or downstream services.

0/4

Serve the entire app over HTTPS and redirect any HTTP requestWithout this, credentials and session cookies travel in plaintext on any network between the user and the server.
Set a Content-Security-Policy that restricts script sourcesA working CSP is the strongest remaining defense against XSS even if an injection point slips through.
Set X-Content-Type-Options: nosniff and a restrictive X-Frame-Options or frame-ancestors directiveThese stop MIME-sniffing attacks and clickjacking, where the site is embedded invisibly inside another page.
Enable HSTS so browsers refuse to downgrade the connection to plain HTTPWithout HSTS, a single plain-HTTP request — even a mistyped one — is an opening for a network attacker to intercept.

0/5

Run a dependency vulnerability scan (npm audit or equivalent) as part of CI, not just occasionally by handNew CVEs land in existing dependencies constantly — a one-time check goes stale the day after you run it.
Pin dependency versions and review what actually changes on each upgradeSupply-chain compromises have shipped through minor version bumps that nobody reviewed before deploying.
Keep all secrets and API keys out of source control, loaded from environment variables or a secrets managerOnce a secret is committed, it lives in git history even after the line is deleted, and must be treated as compromised.
Rotate any credential that was ever exposed, even briefly, in a log, ticket, or chat messageThere's no way to know an exposed secret wasn't seen — rotation is the only action that actually closes the risk.
Give each service and integration the minimum permissions it needs, not a broad admin key for convenienceA narrowly scoped credential limits the blast radius if it's ever leaked or misused.

0/4

Log authentication events — logins, failures, password resets — with enough detail to investigate laterThis is usually the first place anyone looks when trying to reconstruct how an account was compromised.
Never log passwords, full tokens, or full card numbers, even in debug outputLogs are read by more people and tools than production data usually is, and they're often kept far longer.
Alert on abnormal patterns like repeated failed logins or a spike in 403s from one sourceAutomated attacks are usually visible in the access pattern well before any single request looks obviously malicious.
Keep logs long enough to investigate an incident, with access to them restricted and auditedLogs that rotate out too fast, or that anyone can read, aren't useful for the investigation they exist for.