Manual web application security testing checklist, mapped to OWASP
This web application security testing checklist is a manual security testing checklist you can work through before any release. It is grouped by area: authentication, sessions, access control, input handling, CSRF, file upload, headers and TLS, secrets and errors, dependencies, logging and rate limiting, and APIs. Every item says what to check and what a failure looks like.
Each group is mapped to the OWASP Top 10 (2021) category it covers and to the matching chapter of the OWASP Application Security Verification Standard (ASVS 4.0.3). For the detailed test procedure behind any item, use the OWASP Web Security Testing Guide (WSTG), which this list follows.
How to use this checklist
Run it against a staging environment that mirrors production. Create at least two ordinary users in two different organizations (or tenants) and one admin user. Many of the serious findings in manual security testing come from comparing what user A can reach with what user B can reach, so you need both.
Send your browser traffic through an intercepting proxy such as Burp Suite or ZAP so you can see and replay every request. Record each item as pass, fail or not applicable, and keep the request and response for anything that fails. Automated scanners help with headers, TLS and known vulnerable libraries, but access control, business logic and most authorization problems are only found by a person testing by hand.
Only test systems you own or have written permission to test.
1. Authentication
OWASP Top 10: A07 Identification and Authentication Failures. ASVS: V2 Authentication.
- Login errors do not reveal which accounts exist. A wrong password for a real account and any password for an unknown account should give the same message, status code and roughly the same response time.
- Password reset does not reveal accounts either. Compare the responses for a registered and an unregistered email.
- Reset links are single use and expire. Using a link twice, or after its stated expiry, should fail. The token should be long and random.
- Repeated failed logins are slowed down. Expect a lockout, a delay or a challenge after a small number of failures, and check the same limit applies to password reset and MFA code entry.
- Password rules are sensible. Very short and commonly breached passwords are refused, and long passphrases are accepted.
- MFA cannot be skipped. After the password step, an authenticated page should not load until the second factor is complete, and an old code should not work twice.
- Credentials only travel over HTTPS and never appear in URLs, where they end up in logs and browser history.
2. Session management
OWASP Top 10: A07 (session handling) and A05 Security Misconfiguration (cookie flags). ASVS: V3 Session Management.
- Session cookies carry the right flags. In browser devtools the session cookie should be Secure, HttpOnly and SameSite (Lax or Strict).
- The session identifier changes at login. Note the cookie before and after logging in. The value should be new.
- Logout ends the session on the server. Replaying a request with the old cookie after logout should be refused.
- Sessions expire. An idle session should time out, and there should also be an absolute lifetime.
- A password change ends other sessions. Log in on two browsers, change the password in one, and confirm the other is signed out.
- Tokens stay out of URLs. Session or bearer tokens should not appear in query strings or the Referer header.
3. Access control and IDOR
OWASP Top 10: A01 Broken Access Control. ASVS: V4 Access Control.
This is where many real findings are, and scanners rarely catch them.
- Object IDs are checked on the server. As user A, note the ID of a record. As user B, request that same ID. User B should get a refusal, not the record. Check read, edit, delete and export actions, not only the page you started from. This class is called insecure direct object reference (IDOR).
- Tenants are isolated. Repeat the check with users in different organizations, and include organization or project IDs in the request, not only record IDs.
- Hidden is not protected. An endpoint behind a button the UI hides from normal users should still refuse a normal user who calls it directly.
- Roles cannot be set by the client. Fields such as role or owner in profile update and signup requests should be ignored or refused by the server.
- Every HTTP method is checked. If reading a resource is refused, updating and deleting it should be refused too.
- Workflow steps cannot be skipped. In multi step flows such as checkout or approval, the final step should refuse a request that did not go through the earlier ones.
- Files and exports are protected. Direct links to uploads, invoices and reports should not work when logged out or as another user.
4. Input handling, injection and XSS
OWASP Top 10: A03 Injection (cross site scripting is part of A03 in the 2021 list). ASVS: V5 Validation, Sanitization and Encoding.
- Database queries are parameterized. Unexpected characters in search boxes, filters, sort options and IDs should produce a normal validation message, never a database error. Sort and column parameters deserve extra attention because they are often built as strings. WSTG section 4.7.5 covers SQL injection testing in detail.
- Output is encoded for its context. Text you enter should come back as text wherever it is displayed: in pages, admin screens, emails and PDF exports. If anything you typed is interpreted as markup or script, that is a cross site scripting finding. WSTG sections 4.7.1 and 4.7.2 cover reflected and stored XSS.
- Client side code handles URL values safely. Values the page reads from the query string or fragment should never be written into the page as markup or used as a link target without validation.
- Rich text and Markdown are sanitized. If users can enter formatted text, links should be limited to safe schemes such as https and mailto.
- Other interpreters are covered. If the app builds shell commands, XML, templates or LDAP queries from user input, each needs its own review. XML parsers should have external entities disabled.
- Server side requests are restricted. Features that fetch a URL the user supplies (webhooks, link previews, imports) should not be able to reach internal addresses or cloud metadata endpoints. This is A10 Server Side Request Forgery.
- Input limits are enforced. Very long values, wrong types and out of range numbers are refused on the server, not only in the form.
5. CSRF
OWASP Top 10: A01 Broken Access Control (CSRF is mapped there in 2021). ASVS: V4 Access Control and V3 Session Management.
- State changing requests need a token or a strict cookie policy. For each form or action that changes data, check for an anti CSRF token, or for session cookies set to SameSite Lax or Strict plus a check of the Origin header.
- The token is actually validated. Replaying the request with the token removed or changed should fail.
- Nothing important changes on GET. Deleting, transferring or changing settings should never happen through a plain link.
6. File upload
OWASP Top 10: A04 Insecure Design (unrestricted upload) and A05. ASVS: V12 Files and Resources.
- File type is checked by content, not only by extension or the declared content type.
- Size and count limits are enforced on the server.
- Uploaded files cannot run on your domain. Files should be served from a separate domain or storage bucket, with a download disposition for anything that is not a simple image.
- File names are not trusted. The server should generate its own names so a crafted name cannot change the storage path.
- Access is checked on download (see section 3, item 7).
7. Security headers, TLS and CORS
OWASP Top 10: A02 Cryptographic Failures (TLS) and A05 Security Misconfiguration. ASVS: V9 Communication and V14 Configuration.
- HTTPS everywhere, with HSTS. Plain HTTP redirects to HTTPS, and the Strict Transport Security header is present with a long max age.
- Only modern TLS. TLS 1.2 and 1.3 only, with strong cipher suites. A free scanner such as SSL Labs or testssl.sh checks this in minutes.
- A Content Security Policy is set and does not allow unsafe inline scripts where it can be avoided.
- Framing is controlled with the frame ancestors directive or the X Frame Options header, so pages cannot be embedded by other sites.
- Other headers are present: nosniff for content types, a Referrer Policy, and no version details in Server headers.
- CORS is narrow. The API should not reflect any Origin it receives, and should not allow credentials for untrusted origins.
8. Secrets and error handling
OWASP Top 10: A04 Insecure Design (sensitive data in error messages), A05 and A07 (hard coded credentials). ASVS: V7 Error Handling and Logging, V8 Data Protection, V14 Configuration.
- Errors are generic in production. Force an error with a malformed request and check the response contains no stack trace, query, file path or framework version.
- Debug features are off. Debug pages, admin consoles and API explorers are not reachable from the internet.
- No secrets in the front end. Search the JavaScript bundles for API keys, private tokens and internal URLs. Keys meant to be public (such as a publishable key) are fine; server keys are not.
- No secrets in the repository. Run a secret scanner such as gitleaks over the git history, not only the current files.
- Sensitive data is not over shared. API responses contain only the fields the screen needs, not full user records with password hashes or internal flags.
- Passwords are stored with a slow hash such as Argon2 or bcrypt (A02 Cryptographic Failures, ASVS V2 and V6).
9. Dependencies
OWASP Top 10: A06 Vulnerable and Outdated Components and A08 Software and Data Integrity Failures. ASVS: V14 Configuration.
- Known vulnerable packages are found. Run npm audit, OSV Scanner or Trivy against the lockfile and the container image, and review anything high or critical.
- Versions are pinned. Lockfiles are committed and CI installs from them.
- Third party scripts are controlled. Scripts loaded from a CDN use subresource integrity where possible.
- Unused packages and endpoints are removed.
10. Logging, monitoring and rate limiting
OWASP Top 10: A09 Security Logging and Monitoring Failures and A07. ASVS: V7 Error Handling and Logging, V11 Business Logic.
- Security events are logged: logins, failed logins, password and MFA changes, permission changes and access denied responses.
- Logs contain no secrets. Passwords, tokens and full card numbers never appear in logs.
- Someone is alerted. A burst of failed logins or refused requests reaches a person, not only a log file.
- Expensive actions are rate limited: login, signup, password reset, search, exports and anything that sends email or SMS.
11. API specific checks
OWASP Top 10: A01, A05 and A07, plus the separate OWASP API Security Top 10. ASVS: V13 API and Web Service.
- Every endpoint requires authentication unless it is deliberately public. Check the endpoints the UI does not use, too.
- Object level authorization is checked on every endpoint (section 3 applies to APIs first).
- Responses are filtered on the server, not by the front end hiding fields.
- Pagination and batch sizes are capped, so one request cannot export the whole database.
- Tokens are validated properly: expiry, signature and audience are checked, and expired or tampered tokens are refused.
- Webhooks verify signatures and reject replays.
- Old API versions are retired or held to the same checks as the current one.
Our API testing best practices guide covers contract, performance and reliability testing alongside security.
The one page version
Copy this into your test plan or release ticket:
- Login and reset do not reveal which accounts exist
- Failed logins, reset and MFA are rate limited
- MFA cannot be skipped
- Session cookies are Secure, HttpOnly and SameSite
- Session ID changes at login; logout ends it on the server
- User B cannot read, edit or delete user A's records (IDOR)
- Organizations cannot see each other's data
- Hidden admin endpoints refuse normal users
- Role and owner fields cannot be set by the client
- User input never causes database errors
- User input is displayed as text everywhere, including emails and exports
- URL fetching features cannot reach internal addresses
- State changing requests are protected against CSRF
- Uploads are checked by content, size limited and served from a separate origin
- HTTPS with HSTS, TLS 1.2 or later
- Content Security Policy and framing protection set
- CORS does not reflect arbitrary origins
- Production errors are generic; debug features are off
- No secrets in bundles or git history
- No known critical vulnerabilities in dependencies
- Security events are logged, without secrets, and alerted on
- Every API endpoint checks authentication and object level authorization
When manual testing is not enough
This checklist covers the checks a QA team can run before each release. It does not replace a penetration test for high risk systems, a threat model for new designs, or a compliance audit for PCI DSS, HIPAA or SOC 2. If your app has AI features, they add a separate set of risks: see our OWASP LLM Top 10 testing guide. If much of your code is written by AI assistants, read security testing for vibe coded applications for the failure modes that show up more often there.
For independent testing, BetterQA provides security testing services.
Keeping the checklist in BugBoard
A checklist only helps if it is run every release and the results are kept. In BugBoard you can keep these items as test cases in a test suite, record pass or fail for each release in a test execution, and file failures as bugs with the request, response and screenshots attached. See the BugBoard features page for how test suites and executions work.
FAQ
What should a web application security testing checklist include?
At minimum: authentication, session management, access control, input handling (injection and cross site scripting), CSRF, file upload, security headers and TLS, secrets and error handling, dependencies, logging and rate limiting, and API checks. The OWASP Top 10 gives the categories and the OWASP ASVS gives detailed requirements for each.
Can security testing be done manually?
Yes, and some of it has to be. Scanners find missing headers, weak TLS and known vulnerable libraries, but they cannot tell whether user B should be allowed to see user A's invoice. Access control, business logic and multi step flows need a person with two accounts and an intercepting proxy.
How is this different from a penetration test?
A checklist like this is repeatable QA work run on every release. A penetration test is a time boxed attempt by specialists to break in, usually before a major launch or once a year. Use both: the checklist catches regressions, the pentest finds what the checklist did not think of.
Which OWASP resources should I use?
The OWASP Top 10 (2021) to prioritise, the Application Security Verification Standard (ASVS) for what to verify, and the Web Security Testing Guide (WSTG) for how to test each item. For APIs, add the OWASP API Security Top 10.