Web ApplicationSecurity Checklist
Security can feel endless, so it helps to have a fixed list. This checklist is grouped the way the OWASP Application Security Verification Standard is grouped, so it lines up with a real, recognized standard rather than one person's opinion. Each section gives you the plain reason it matters and a link to the full guide. You can also explore the standard interactively in our ASVS Explorer and check a specific stack with the security checklist tool.
How Do You Secure Authentication?
Authentication is how your app knows who a user is. It is the most attacked part of most applications, because a stolen login is a stolen account. The goal is to make guessing passwords slow, to catch already-breached passwords, and to add a second factor for sensitive accounts.
- 1Hash passwords with a slow algorithm such as bcrypt or Argon2, never a plain or fast hash.
- 2Check new passwords against known breached lists so users cannot reuse a leaked password.
- 3Throttle and lock accounts after repeated failed logins to slow brute force and credential stuffing.
- 4Offer multi-factor authentication, and require it for admin and high-value accounts.
- 5Consider passwordless magic links to remove the password as a target entirely.
Go deeper with our guides on password hashing, rate limiting and account lockout, multi-factor authentication, and passwordless magic links. On Node.js, OwlAuth ships these controls, including breached-password checks and login throttling, out of the box.
How Do You Secure Sessions and Tokens?
Once a user logs in, you need a safe way to remember them. That is either a session cookie or a token. Both can be stolen or replayed if you get the details wrong, so the controls here are about generating them safely, protecting them in transit, and being able to revoke them fast.
- 1Set session cookies with HttpOnly, Secure, and SameSite so scripts and other sites cannot steal them.
- 2Generate session IDs and tokens with high entropy so they cannot be guessed.
- 3Rotate the session or refresh token on login and on privilege change to prevent fixation and reuse.
- 4Store only a hash of the token on the server, so a database leak does not hand over live sessions.
- 5Be able to revoke a session or token instantly, and set sensible expiry times.
- 6Detect refresh-token reuse and cut off the whole session when it happens.
See our guides on session management and secure cookies and JWTs vs session tokens. On Node.js, OwlSessionGuard handles high-entropy sessions, rotation with reuse detection, and revocation, while OwlTokenGuard covers JWT issuance, rotation, and fail-shut verification.
How Do You Validate Input and Encode Output?
Almost every classic web vulnerability comes from trusting data you should not. Input validation checks that data is the shape you expect. Output encoding makes sure data is treated as data, not as code, when you show it or send it to a database. Get both right and you close the door on injection and cross site scripting.
- 1Validate input on the server against an allowlist of expected values, never only in the browser.
- 2Use parameterized queries or an ORM so user input can never change the meaning of a database query.
- 3Encode output for its context (HTML, attribute, URL, JavaScript) to stop cross site scripting.
- 4Validate uploaded files by their real bytes and serve them from a separate domain.
- 5Set a Content Security Policy as a backstop for any script that slips through.
Read our guides on SQL injection, cross site scripting, Content Security Policy, file upload security, and serving uploads from a separate domain.
How Do You Enforce Access Control?
Authentication proves who a user is. Access control decides what they are allowed to do. Broken access control is consistently the most common serious flaw, usually because a check is missing on a single endpoint. The rule is simple to state and easy to forget: check permission on the server for every request, not just in the interface.
- 1Deny by default, and grant access only where you have explicitly allowed it.
- 2Check ownership and role on the server for every request, including API calls.
- 3Never rely on hiding a button or a link as a security control.
- 4Protect against cross site request forgery on state-changing requests.
- 5Give each user, service, and token the least privilege it needs, and no more.
See our guides on cross site request forgery, OAuth and OpenID Connect, and least privilege for tokens.
How Do You Handle Configuration, Transport, and Logging?
The last group is the plumbing. It is less exciting than an exploit, but a leaked secret or a missing HTTPS setting can undo everything else. This section is about keeping secrets out of your code, encrypting traffic, and keeping enough of a record to notice and investigate an attack.
- 1Serve everything over HTTPS and send security headers such as HSTS.
- 2Keep secrets out of source code and in a secrets manager or environment configuration.
- 3Turn off debug output and detailed errors in production.
- 4Keep dependencies patched and watch for known vulnerabilities.
- 5Log authentication, access, and admin events, and protect those logs.
Go deeper with our guides on HTTPS and TLS, HTTP security headers, secrets management, and data protection.
The Full Web Application Security Checklist
- 1Hash passwords with bcrypt or Argon2 and block breached passwords.
- 2Throttle logins and lock accounts to stop brute force and credential stuffing.
- 3Require multi-factor authentication for sensitive accounts.
- 4Set session cookies with HttpOnly, Secure, and SameSite, and rotate on login.
- 5Store only hashed tokens and be able to revoke them instantly.
- 6Validate input on the server and use parameterized queries.
- 7Encode output for its context and set a Content Security Policy.
- 8Validate uploads by content and serve them from a separate domain.
- 9Deny by default and check access on the server for every request.
- 10Protect state-changing requests against cross site request forgery.
- 11Serve HTTPS with HSTS and keep secrets out of source code.
- 12Patch dependencies and log security events.