Web application vulnerability assessment checklist
A vulnerability assessment identifies the security weaknesses in a web application and rates each one by severity. This checklist covers the whole process in 14 sections and 118 checks, from planning to retesting. It follows the way the OWASP Web Security Testing Guide organises an assessment.
Each check shows how it is usually carried out:
- Automated: Vooki Pro tests this for you.
- Automated + manual review: Vooki Pro tests for it, but a person should confirm the result or look deeper.
- Manual: a person has to do or check this.
97 of the 118 checks can be automated in full or in part, which leaves your team free for the ones that need human judgement.
1. Plan and scope
Agree these before any testing starts.
| Check | How |
|---|---|
| Get written authorisation to test, naming the systems and dates | Manual |
| List every application, API, subdomain and environment in scope | Manual |
| Record what is out of scope: third-party services, payment providers, production data | Manual |
| Create test accounts for each user role, plus a second account at the same level | Manual |
| Agree testing windows, request-rate limits and who to contact if something breaks | Manual |
| Confirm backups exist and the test environment can be restored | Manual |
| Build a simple threat model: what is most valuable, and who would attack it | Manual |
| Tell operations and monitoring teams, and allow-list the scanner in the WAF if needed | Manual |
2. Discover the attack surface
You cannot test what you have not found.
| Check | How |
|---|---|
| Map all pages, forms and parameters, including areas behind the login | Automated |
| Capture background API calls (XHR/fetch) made by the front end | Automated |
| Record critical multi-step journeys such as checkout and onboarding | Automated |
| Import API definitions (OpenAPI, Postman, HAR) so unused endpoints are covered | Automated |
| Identify server, framework, CMS and library versions | Automated |
| Check robots.txt and sitemap.xml for hidden paths | Automated |
| Look for exposed API documentation (Swagger/OpenAPI) | Automated |
| Look for old API versions and undocumented endpoints | Automated + manual review |
| Check subdomains for dangling DNS records | Automated |
| Review the discovered sitemap against what the application really contains | Manual |
3. Configuration and deployment
| Check | How |
|---|---|
| Only TLS 1.2 and 1.3 are enabled; no weak ciphers | Automated |
| Certificate is valid and not close to expiry | Automated |
| HSTS is set | Automated |
| Content-Security-Policy is present and not weak | Automated |
| X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are set | Automated |
| CORS allows only trusted origins | Automated |
| No version details in headers such as Server or X-Powered-By | Automated |
| Unneeded HTTP methods (TRACE, PUT, DELETE) are disabled | Automated |
| Debug mode is off; no stack traces or verbose errors | Automated |
| No default credentials on the application or its admin tools | Automated |
| Admin panels and management endpoints are not publicly reachable | Automated |
| Directory listing is disabled | Automated |
| No exposed .git, .env, backup files, source maps or phpinfo pages | Automated |
| Cloud storage buckets are not publicly listable | Automated |
| Frameworks, libraries and server software have no known CVEs | Automated |
4. Authentication
| Check | How |
|---|---|
| Login and password reset do not reveal which usernames exist | Automated |
| Repeated failed logins are rate-limited or locked out | Automated |
| Password policy rejects weak passwords | Automated |
| Credentials are never sent over HTTP or in URLs | Automated |
| Passwords are never returned in responses | Automated |
| Password reset tokens are single-use, random and expire | Automated + manual review |
| Every protected page and endpoint requires authentication | Automated |
| JWTs are validated properly: algorithm, signature, expiry | Automated |
| OAuth / OpenID Connect / SAML flows are implemented securely | Automated |
| Multi-factor authentication is available for sensitive accounts and cannot be bypassed | Manual |
5. Session management
| Check | How |
|---|---|
| Session cookies have Secure, HttpOnly and SameSite flags | Automated |
| Session IDs are long and unpredictable | Automated |
| A new session ID is issued at login | Automated |
| Sessions expire after inactivity | Automated |
| Session tokens never appear in URLs | Automated |
| Logout invalidates the session on the server | Manual |
| Concurrent sessions are handled as intended | Automated + manual review |
| State-changing requests are protected against CSRF | Automated |
6. Authorization and access control
Test these with at least two accounts.
| Check | How |
|---|---|
| Users cannot read or change other users' data by changing an ID (IDOR / BOLA) | Automated + manual review |
| Users cannot reach admin functions (vertical privilege escalation) | Automated + manual review |
| Users cannot act as another user of the same role (horizontal) | Automated + manual review |
| Protected pages cannot be opened directly without the right role (forced browsing) | Automated |
| Access rules cannot be bypassed by changing the HTTP method or using method-override headers | Automated |
| Access rules cannot be bypassed with path tricks such as ../ or encoded characters | Automated |
| API requests cannot set fields they should not control (mass assignment) | Automated |
| Role and permission changes take effect immediately | Manual |
7. Input validation and injection
Test every parameter, header, cookie and body field.
| Check | How |
|---|---|
| SQL injection, including blind | Automated |
| NoSQL injection | Automated |
| OS command injection | Automated |
| Cross-site scripting: reflected, stored and DOM-based | Automated |
| Server-side template injection | Automated |
| XML external entities (XXE) and XML injection | Automated |
| LDAP and XPath injection | Automated |
| Server-side request forgery (SSRF) | Automated |
| CRLF and host header injection | Automated |
| HTTP parameter pollution | Automated |
| Open redirects | Automated |
| Local and remote file inclusion | Automated |
| Insecure deserialization | Automated |
| Prototype pollution | Automated |
| HTTP request smuggling | Automated |
8. File upload and download
| Check | How |
|---|---|
| Uploads are restricted by type, and the content is verified, not just the extension | Automated |
| Disguised and polyglot files are rejected | Automated |
| Upload size limits are enforced | Automated |
| File names cannot escape the upload folder; archives are safe to extract (zip slip) | Automated |
| Uploaded files are stored outside the web root and cannot be executed | Manual |
| Downloads check that the user is allowed to access the file | Manual |
9. Client-side security
| Check | How |
|---|---|
| Pages cannot be framed by other sites (clickjacking) | Automated |
| No unsafe JavaScript patterns such as innerHTML or eval with untrusted data | Automated |
| postMessage handlers validate the sender | Automated |
| No sensitive data in localStorage or sessionStorage | Automated |
| Third-party scripts use Subresource Integrity | Automated |
| Links that open new tabs cannot hijack the opener (tabnabbing) | Automated |
| JavaScript libraries are up to date | Automated |
| No mixed content | Automated |
10. API-specific checks
| Check | How |
|---|---|
| Object-level and function-level authorization on every endpoint | Automated + manual review |
| Responses return only the fields the client needs | Automated + manual review |
| Rate limits and size limits are in place | Automated |
| GraphQL introspection is disabled in production; query depth is limited | Automated |
| Old API versions are retired | Automated + manual review |
| Data from third-party APIs is validated before use | Automated + manual review |
11. Business logic
Automated tools help here, but a person who understands the business must review it.
| Check | How |
|---|---|
| Prices, quantities and totals cannot be manipulated | Automated + manual review |
| Workflow steps cannot be skipped or repeated | Automated + manual review |
| Coupons, credits and limits cannot be abused | Automated + manual review |
| Race conditions do not allow double spending or duplicate actions | Automated + manual review |
| Sensitive actions require confirmation or re-authentication | Manual |
12. Data protection and error handling
| Check | How |
|---|---|
| No personal data, API keys or secrets in responses or JavaScript | Automated |
| Sensitive pages are not cached by browsers or proxies | Automated |
| Error pages are generic and reveal no internal details | Automated |
| No internal IP addresses, database strings or sensitive comments in responses | Automated |
| Sensitive data is encrypted at rest | Manual |
| Security events (logins, failures, permission changes) are logged and monitored | Manual |
13. Triage and report
| Check | How |
|---|---|
| Verify each finding using its evidence; mark false positives | Manual |
| Rate findings by severity, using CVSS | Automated + manual review |
| Remove duplicates that share one root cause | Automated + manual review |
| Record evidence and steps to reproduce for each finding | Automated |
| Assign each finding to an owner, with a ticket | Automated + manual review |
| Write the report: scope, method, findings by severity, remediation | Automated + manual review |
| Map findings to the frameworks you report against (OWASP Top 10, PCI DSS, ISO 27001, SOC 2) | Automated |
| Walk stakeholders through the risks that concern them | Manual |
14. Fix, retest and repeat
| Check | How |
|---|---|
| Fix Critical and High findings first | Manual |
| Retest each fix against the live application | Automated |
| Run a full rescan to catch regressions | Automated |
| Schedule the next assessment, and scan after every significant release | Automated |
| Feed recurring issues back into developer training and coding standards | Manual |
How to use this checklist
- Work through the sections in order for a first assessment. For later ones, start from section 2.
- Run the automated checks first, with authentication configured, then spend your manual time on authorization, business logic and the findings that need confirming.
- Only test systems you own or have written permission to test.
- A checklist is a minimum. Adapt it to your application's technology and risks.
How Vooki Pro helps
- Automates 97 of the 118 checks in this list, fully or in part, in a single scan.
- Tests behind the login with auth profiles and automatic re-login, which sections 4 to 7 depend on.
- Gives every finding evidence, steps to reproduce, a CVSS score and remediation guidance, ready for triage.
- Creates tickets in Jira, GitHub, GitLab, Linear or Azure DevOps, and produces standard and compliance reports.
- Retests each fix and keeps triage states between scans, so every assessment builds on the last.
Frequently asked questions
What is a vulnerability assessment?
A structured process to identify, rate and report security weaknesses in an application.
How is it different from a penetration test?
An assessment aims to find as many weaknesses as possible; a penetration test tries to exploit them to show real impact.
How often should I run a vulnerability assessment?
At least quarterly for internet-facing applications, and after every significant release. Automated scanning can run far more often, for example weekly or on every build.
Can a vulnerability assessment be fully automated?
No. Most technical checks can be automated, but scoping, authorization logic, business logic and the final triage need a person.
Try Vooki Pro free for 7 days
Run this checklist against your own application with Vooki Pro. The trial unlocks every feature for 7 days, and scanning runs on your own machine.
Related: Web application penetration testing checklist · Scoping a security scan correctly · Compliance reporting from DAST results