Most testers fall into habits. They test what they always test and skip what they always skip. The bugs that cause real damage tend to hide in the places nobody looks: the password reset flow, the file upload nobody has touched in two years, the admin endpoint that never got a permission check.
This is a working checklist for web application VAPT (Vulnerability Assessment and Penetration Testing). Use it to plan a test, to judge what a provider is really offering, or to check whether your own team has been skipping something.
At Sunvak Boreal, we combine automated checks with manual testing. Tools are great at catching the obvious problems quickly, which leaves a real person free to spend their time on the issues that only exist in your application.
What is web application VAPT?
It’s two jobs in one. The vulnerability assessment is the broad sweep: automated tools, configuration checks, and technology analysis that flag possible weaknesses. The penetration test is the human part, where someone tries to confirm those weaknesses by hand and find out whether they can actually be exploited.
Together, they cover authentication, authorization, sessions, input handling, access controls, business logic, APIs, file uploads, configuration, sensitive data, and behavior on both the client and the server.
Why bother with a checklist?
A checklist stops important areas from slipping through the cracks. It gives developers, testers, and auditors one shared reference, makes fixes easier to track, and lets you compare providers by what each would actually cover.
Treat it as a starting point rather than a finish line. Adapt it to your architecture, features, stack, and business.
The checklist
1. Scope and information gathering
Before anyone touches anything, agree on what’s being tested. Confirm the URLs and whether you’re testing production or a test environment. Write down the in-scope domains, subdomains, APIs, user roles, and third-party integrations. Set up test accounts, note how authentication works, and be explicit about restrictions and anything out of scope.
2. Application discovery
Map the application before you attack it. Find the public and logged-in pages, admin functions, API endpoints, parameters, and HTTP methods. Locate upload and download features, hunt for hidden functionality, note which technologies are in use, and read the client-side code.
3. Authentication
Test login, password policy, lockout, and brute-force protection. Give extra attention to password reset and account recovery, since that’s where teams tend to cut corners. Look at multi-factor authentication, error messages, session creation, “remember me” behavior, and how credentials are handled. Then try to get around authentication entirely.
4. Authorization
Two questions drive this section. Can one user get to another user’s data (horizontal)? Can an ordinary user reach admin features (vertical)? Cover role permissions, admin functions, object-level and function-level checks, direct URL access, API authorization, privilege escalation, and tenant isolation.
5. Session management
Review session IDs, expiration, idle timeouts, logout, and invalidation. Check concurrent sessions, cookie attributes, fixation, and hijacking risk, and make sure sensitive session data is protected.
6. Input validation
Try query parameters, form fields, headers, JSON and XML input, file names, path parameters, special characters, and unusual encodings. Confirm that validation happens on the server and not just in the browser.
7. Injection
Look for SQL, NoSQL, command, LDAP, and XPath injection, along with template injection, expression language injection, and header and host header injection. Also look for any injection points that are unique to your application.
8. Cross-site scripting (XSS)
Cover reflected, stored, and DOM-based XSS. Review input and output encoding in HTML, JavaScript, and URL contexts, along with the Content Security Policy and any user-generated content.
9. Cross-site request forgery (CSRF)
Check whether sensitive actions can be triggered without the user meaning to. Review anti-CSRF tokens, SameSite settings, and state-changing requests, especially password changes, transactions, account actions, and admin actions.
10. File upload and handling
Uploads are risky, so slow down here. Test file type, extension, and MIME validation, size limits, filename handling, storage location, restrictions on executable files, malicious uploads, download authorization, and path traversal through filenames.
11. Path traversal and file access
Test for path and directory traversal, and for local or remote file inclusion where it’s relevant. Check file access authorization, and look for exposed sensitive, backup, and temporary files.
12. API security
Most modern web apps are really front ends for APIs, so test them that way. Discover the endpoints first, then test authentication, authorization, BOLA, function-level authorization, excessive data exposure, input validation, rate limiting, HTTP method controls, tokens, error handling, and API business logic.
13. Business logic
This is where scanners struggle and human testers earn their keep. Try to bypass workflows, skip steps, change prices, quantities, or transactions, repeat a transaction, dodge approvals, abuse coupons, and bend account workflows and other business rules.
14. Sensitive data exposure
Look for personal information, credentials, API keys, tokens, internal identifiers, database details, debug output, and source code. Check URLs, error messages, and browser storage too.
15. Security headers
Where they apply, review Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, frame protection, and secure cookie settings. The right setup depends on what your application does.
16. HTTPS and transport security
Confirm HTTPS is enforced and that HTTP redirects to it. Review the TLS configuration, certificate validity, insecure protocols, mixed content, and secure cookies, and make sure sensitive data always travels securely.
17. Security misconfiguration
Confirm debug mode is off, default credentials are gone, and unneeded services and HTTP methods are disabled. Directory listing should be off and detailed errors restricted. Review production settings, and protect admin interfaces and backup files.
18. Error handling and information disclosure
Look for stack traces, database and framework errors, server versions, internal file paths, debug messages, and API errors that say more than they should.
19. Access control and privilege escalation
Test access across standard, privileged, and admin roles. Cover horizontal and vertical escalation, object-level and function-level access, tenant isolation, and API access controls. Yes, this overlaps with authorization. Access control bugs are common enough that a second pass is worth it.
20. Client-side security
Check for client-side validation that can be bypassed, sensitive data or API keys in JavaScript, exposed source maps, browser storage, DOM manipulation, client-side access controls, third-party scripts, and sensitive details in page source. Client-side controls never replace server-side ones.
21. Vulnerable components
Review framework versions, JavaScript libraries, server components, packages, plugins, CMS components, and unsupported software. Tools can list what you’re running, but a person should decide whether each known vulnerability is actually reachable.
22. Logging and monitoring
Where it’s in scope, check that authentication events and privileged actions are logged. Failed logins and suspicious activity should be watched, logs retained and protected, sensitive data kept out of them, and alerts should fire when they’re supposed to.
23. Vulnerability validation
Review the automated findings, chase down false positives, and validate by hand. Assess exploitability, confirm impact, identify the affected assets, and collect evidence. A finding isn’t a finding until someone has confirmed it.
24. Risk rating and reporting
Every reported issue needs a title, severity, affected asset, description, technical details, evidence, reproduction steps, impact, remediation advice, and references.
25. Remediation and retesting
The work doesn’t end when the report lands. Assign findings to owners, fix the critical ones first, and retest. Document any fixes that failed, check that fixes didn’t create new problems, and record the final status of every finding.
What a web app VAPT commonly finds
Broken access control, authentication and authorization flaws, BOLA, injection, cross-site scripting, CSRF, SSRF, file upload vulnerabilities, path traversal, security misconfiguration, sensitive data exposure, weak session management, business logic flaws, privilege escalation, API weaknesses, vulnerable components, information disclosure, and cryptographic weaknesses.
What turns up in your application will depend on its architecture, functionality, and scope.
Web application VAPT vs. vulnerability scanning
| Vulnerability scanning | Web application VAPT |
| Mostly automated | Automated and manual testing combined |
| Good at known vulnerabilities | Can dig into complex application weaknesses |
| Fast and scalable | More detailed and context-aware |
| Runs predefined checks | Testers adapt to how the application behaves |
| Can produce false positives | Findings can be validated by hand |
| Limited business logic testing | Can test business logic |
| Limited authorization testing | Can test authorization in depth |
| Useful for regular monitoring | Useful for deeper assessment |
Who needs it?
SaaS companies, e-commerce businesses, fintech and healthcare platforms, educational platforms, government applications, enterprises, startups, customer portals, and online marketplaces. It matters most when your application handles personal, financial, healthcare, business, or login data.
When to do it
Consider testing before you launch or ship a major release, and after big changes to the application, architecture, authentication, or infrastructure. It also makes sense after you add APIs, before compliance assessments, after a security incident, and as part of a regular testing cycle. Your application keeps changing, so your testing has to keep up.
Beyond the checklist
A checklist works best as one part of a wider security program. That includes secure development practices, strong authentication, server-side authorization, input validation, protected sensitive data, updated dependencies, secure configuration, monitoring, regular scanning, manual penetration testing, and retesting after fixes. Most of all, it means building security into how you make software in the first place.
Why Sunvak Boreal?
We pair automated assessment with manual penetration testing, so you get both breadth and depth. Our work can cover vulnerability assessment, authentication and authorization testing, API and BOLA testing, business logic testing, input validation and session testing, configuration review, vulnerability validation, detailed reporting, and retesting.
What we care about most is which vulnerabilities actually matter, how they can be exploited, and what practical steps fix them.
Final thoughts
A VAPT checklist gives you a structured way to review authentication, authorization, input handling, APIs, business logic, sessions, and configuration. Automated scanning handles the known problems well. Manual testing finds the ones specific to your application, and clear reporting plus retesting closes the loop.
If you’d like an assessment built around your own application and stack, we’re happy to talk it through.
[Get a Web Application VAPT Assessment]
Frequently asked questions
What is a VAPT checklist for web applications?
It’s a structured list of security areas and tests used to assess a web application’s vulnerabilities, access controls, authentication, APIs, business logic, configuration, and other security controls.
What does web application VAPT include?
Vulnerability scanning and manual penetration testing, plus authentication and authorization testing, input validation, session testing, API security testing, business logic testing, and configuration review. It also covers reporting and verifying that fixes worked.
Is vulnerability scanning enough for web application security?
Scanning is useful for known vulnerabilities, but it can miss complex authorization, business logic, workflow, and application-specific issues. Manual testing goes deeper and validates what the scanner finds.
Does VAPT include manual testing?
A comprehensive engagement combines automated assessment with manual penetration testing. The exact approach depends on your scope and requirements.
How often should web applications undergo VAPT?
That depends on the application’s risk, how often it changes, your business requirements, and your compliance obligations. Testing is commonly done before major releases and after significant changes.
Does VAPT test APIs?
Yes. APIs can be included, covering authentication, authorization, BOLA, input validation, rate limiting, data exposure, tokens, and business logic.
Does VAPT identify OWASP Top 10 vulnerabilities?
A web application VAPT can include testing for the relevant OWASP risks. Coverage depends on the scope and what your application does.
What happens after a VAPT assessment?
You receive a report with validated findings, severity ratings, evidence, impact, and remediation recommendations. Once you’ve made fixes, post-remediation testing can confirm they worked.