A practical website and web application VAPT checklist covering authentication, access control, input handling, APIs, headers, configuration and data protection, mapped to OWASP guidance.
How to use this checklist
This checklist helps development teams catch common issues before a formal website VAPT. It is based on public guidance such as the OWASP Top 10, OWASP ASVS and the OWASP Web Security Testing Guide. Work through it in a staging environment, record what you checked and fix obvious issues first, so the penetration testers can spend their time on deeper problems.
Authentication and sessions
1. Passwords are hashed with a modern algorithm such as bcrypt, scrypt or Argon2. 2. Login, signup and password reset are rate limited. 3. Password reset tokens are single use, random and expire quickly. 4. Error messages do not reveal whether an account exists. 5. Multi-factor authentication is available for admins at minimum. 6. Session cookies use Secure, HttpOnly and an appropriate SameSite value. 7. Sessions are invalidated on logout and password change.
Access control
8. Every request checks authorisation on the server, not only in the interface. 9. Changing an ID in a URL or request body cannot expose another user's data. 10. Regular users cannot reach admin routes or functions. 11. Users cannot change their own role or organisation through hidden fields. 12. File downloads check ownership. 13. Deleted or disabled accounts lose access immediately.
Input handling
14. Database queries use parameterised statements. 15. Output is encoded to prevent cross-site scripting. 16. File uploads restrict type and size, are stored outside the web root and are scanned where possible. 17. Server-side requests to user-supplied URLs are restricted to prevent SSRF. 18. Rich text input is sanitised. 19. Forms that change state are protected against CSRF.
APIs
20. All API endpoints require authentication unless intentionally public. 21. Responses return only the fields the client needs. 22. Clients cannot set sensitive fields such as role or price through mass assignment. 23. APIs are rate limited. 24. Old or undocumented API versions are removed or protected.
Configuration and headers
25. HTTPS is enforced with HSTS and TLS configuration is current. 26. Security headers such as Content-Security-Policy, X-Content-Type-Options and frame protections are set. 27. Debug modes, stack traces, directory listings and default admin pages are disabled in production. 28. Dependencies are checked for known vulnerabilities and patched.
Data protection
29. Secrets such as API keys are not present in front-end code or public repositories. 30. Personal data is collected only where needed, encrypted in transit, protected at rest and logged access is reviewed. Organisations in India should also consider their obligations under the Digital Personal Data Protection Act, 2023.
The limits of a checklist
A checklist catches common mistakes but cannot find business logic flaws unique to your product, such as applying a discount twice, skipping a payment step or abusing an approval workflow. Those require a skilled tester who understands how your application is supposed to work. Use this checklist as preparation, then run a manual website VAPT for assurance that customers and auditors will accept.