Short answer: A VAPT checklist is a pre-launch list of security areas to test before releasing software — covering authentication, access control, input validation and injection, the OWASP Top 10, API security, configuration hardening, secrets management, dependencies and logging. Working through it before go-live catches the flaws attackers hunt for first.
How to use this checklist
Treat each section as a gate rather than a suggestion. Assign an owner to every area, mark each item pass or fail with evidence, and do not go live with any open critical or high-risk item. Run the list against a staging environment that mirrors production, test with real credentials for each user role, and repeat it before every significant release — not just the first launch. The sections are ordered roughly by how often attackers succeed, so if time is short, start at the top.
Why you need a VAPT checklist before going live
Most breaches exploit predictable, well-known weaknesses — not exotic zero-days. A structured checklist forces your team to verify each of those weak points before real users (and real attackers) arrive. Use this as an internal readiness pass; a professional VAPT then independently confirms it. Bookmark it and run through every section before each release.
1. Authentication
- Passwords stored using a strong, slow hash (bcrypt, Argon2) — never plaintext or MD5/SHA1.
- Enforced password strength and protection against credential stuffing.
- Account lockout or rate limiting on login and OTP endpoints.
- Multi-factor authentication available for sensitive accounts.
- Secure password reset — tokens expire, are single-use, and are not guessable.
- No user enumeration via different error messages or response times.
2. Session management
- Session tokens are long, random and regenerated on login.
- Cookies flagged HttpOnly, Secure and with appropriate SameSite.
- Sessions expire on logout and after inactivity.
- No session fixation — the token changes after authentication.
3. Access control (authorization)
This is the single most commonly missed area, because automated tools cannot understand your business rules.
- Every sensitive action checks authorization server-side — never rely on hiding a button.
- Test for IDOR/BOLA: can user A access user B's records by changing an ID?
- Test vertical escalation: can a normal user reach admin functions?
- Test each role separately with its own credentials.
- No direct object references exposed without an ownership check.
4. Input validation and injection
- SQL/NoSQL injection: use parameterised queries everywhere.
- Command injection: never pass user input to shell commands unsanitised.
- Cross-site scripting (XSS): output-encode all user data; use a Content Security Policy.
- Template injection, LDAP injection, XML/XXE handling.
- File upload restrictions — type, size, and stored outside the web root.
- Server-side request forgery (SSRF) protections on any URL-fetching feature.
5. OWASP Top 10 coverage
Explicitly verify each category from the OWASP Top 10, the industry baseline for web risks:
| OWASP category | Checked? |
|---|---|
| Broken Access Control | Per-role and IDOR tests done |
| Cryptographic Failures | TLS enforced, data encrypted at rest |
| Injection | Parameterised queries, output encoding |
| Insecure Design | Threat modelling done for key flows |
| Security Misconfiguration | Hardening reviewed (see below) |
| Vulnerable Components | Dependencies scanned and updated |
| Auth Failures | Section 1 above completed |
| Data Integrity Failures | Deserialization and CI/CD reviewed |
| Logging & Monitoring Failures | Section 9 below completed |
| SSRF | URL-fetch features restricted |
6. API security
- Every endpoint enforces authentication and authorization (OWASP API Top 10).
- BOLA/BFLA: object- and function-level access checked on each call.
- Rate limiting and throttling to prevent abuse and scraping.
- Mass assignment prevented — clients cannot set fields they shouldn't.
- Excessive data exposure avoided — return only what the client needs.
- Input validated on the server, never trusting the client.
7. Configuration hardening
- Default credentials changed; unused accounts removed.
- Debug modes, verbose errors and stack traces disabled in production.
- Security headers set: HSTS, X-Content-Type-Options, X-Frame-Options/CSP, Referrer-Policy.
- Unnecessary ports, services and admin panels closed or IP-restricted.
- Directory listing disabled; no sensitive files (.git, .env, backups) web-accessible.
- TLS 1.2+ only, strong ciphers, valid certificate.
8. Secrets management
- No API keys, passwords or tokens hardcoded in source or client-side code.
- Secrets stored in a vault or environment variables, not in the repo.
- Git history scanned for previously committed secrets.
- Keys rotated and scoped to least privilege.
9. Dependencies and supply chain
- All libraries and frameworks scanned for known CVEs (SCA tools).
- No end-of-life or unmaintained components in production.
- Lockfiles used; dependency updates monitored.
10. Logging and monitoring
- Security events (logins, failures, privilege changes) are logged.
- Logs do not contain passwords, tokens or full card numbers.
- Alerts exist for suspicious activity; logs are tamper-resistant and retained.
11. Data protection and privacy (DPDP-aligned)
India's DPDP Act 2023 makes how you handle personal data a legal matter, not just good practice. Verify:
- Personal data is encrypted in transit (TLS) and at rest.
- Data collection is minimised — you store only what you need.
- Access to personal data is restricted by role and logged.
- Deletion and data-retention controls exist and actually work.
- Third parties and processors handling your data are assessed.
- Backups are encrypted and access-controlled.
12. Business logic
Logic flaws are unique to your application and invisible to scanners, which makes them the flaws attackers love. Walk through your critical flows and ask "what if a user does this out of order, or with a tampered value?":
- Can a checkout be manipulated to change price, quantity or discount?
- Can a workflow step be skipped (e.g. reaching a paid feature without paying)?
- Can rate-limited actions (OTP, coupons, referrals) be abused at scale?
- Can negative or extreme values break calculations?
- Are server-side checks enforced, not just client-side validation?
13. Infrastructure and cloud
- Cloud storage buckets are private by default — no public S3/blob exposure.
- IAM follows least privilege; no over-permissioned or unused keys.
- Security groups and firewalls expose only required ports.
- Databases are not directly reachable from the internet.
- CIS Benchmark hardening applied to servers and cloud config.
- Patching is current on OS, runtimes and containers.
14. Third-party integrations and webhooks
Modern apps lean heavily on external services, and each integration widens your attack surface. Verify:
- Webhooks validate signatures so attackers cannot forge inbound events.
- OAuth and SSO redirect URIs are strictly whitelisted — no open redirects.
- Third-party API keys are scoped to least privilege and rotated.
- Payment gateway callbacks are verified server-side, never trusted from the client.
- Data shared with processors is minimised and covered by an agreement (DPDP relevance).
15. Error handling and information disclosure
- Errors return generic messages to users; full details go to server logs only.
- No stack traces, framework versions or internal paths leaked in responses.
- API responses do not reveal whether a username or email exists.
- HTTP response headers do not advertise exact server/software versions.
Priority order: what to fix first
You will rarely finish every item before a deadline, so triage using this order:
| Priority | Focus area | Why |
|---|---|---|
| 1 | Access control & authentication | Highest-impact, most-exploited, scanner-blind |
| 2 | Injection & input validation | Direct route to data compromise |
| 3 | Secrets & configuration | Easy wins that prevent full compromise |
| 4 | Dependencies & patching | Known CVEs are actively scanned by attackers |
| 5 | Logging & monitoring | Detect and respond when prevention fails |
Automated scan vs manual testing on this checklist
It helps to know which of these items an automated scanner can meaningfully check and which genuinely require a human. This is the clearest argument for a professional test rather than relying on a tool alone:
| Checklist area | Automated scanner | Manual tester |
|---|---|---|
| Known CVEs in dependencies | Strong | Confirms exploitability |
| Missing security headers / TLS config | Strong | Adds context |
| Reflected XSS, basic injection | Partial | Confirms and extends |
| Broken access control (IDOR/BOLA) | Weak / blind | Essential |
| Business-logic abuse | Cannot detect | Essential |
| Chained multi-step attacks | Cannot detect | Essential |
Roughly the top of this checklist (auth, access control, business logic) is where humans are irreplaceable, and it is exactly where the most damaging real-world breaches originate. A scanner is a useful first pass, but signing off go-live on scanner output alone leaves your highest-impact risks unexamined.
From checklist to independent assurance
A self-checklist is essential, but you cannot fully mark your own homework — teams are blind to their own assumptions. That is why a compliance auditor (ISO 27001, PCI-DSS) or a DPDP Act 2023 due-diligence review expects an independent test. A professional VAPT works through everything above and more, then proves exploitability rather than just ticking boxes. Learn how the two differ in vulnerability assessment vs penetration testing, or start with what is VAPT.
Cyber Defence is ISO-certified and GeM-registered, led by Amit Kumar (CEH, CRTA). Honestly stated: we are not CERT-In empanelled and never claim to be. See our VAPT services in Haryana and VAPT services in Delhi, or train your team with our VAPT training.
FAQ
What is a VAPT checklist?
It is a pre-launch list of security areas to verify before releasing software — authentication, access control, injection, OWASP Top 10, API security, configuration, secrets, dependencies and logging — so common attack points are covered before go-live.
Can I run this VAPT checklist myself?
Yes, use it as an internal readiness pass. But compliance audits and serious security assurance need an independent professional VAPT, because teams tend to miss their own blind spots, especially in access-control logic.
Which checklist item is most often missed?
Broken access control — particularly IDOR/BOLA — because automated scanners cannot understand your business rules about who should see what. It needs manual, per-role testing.
Does this checklist cover the OWASP Top 10?
Yes. Section 5 maps directly to every OWASP Top 10 category, and the other sections expand on authentication, API security and configuration in more detail.
How often should I run through this checklist?
Before every major release or significant change, and at least annually. Pair it with a professional VAPT on your compliance cycle.
Does a VAPT checklist replace a penetration test?
No. It prepares you and reduces obvious issues, but a penetration test independently proves exploitability and produces a report auditors and clients accept.
Want an independent team to work through this checklist and prove your app is safe to launch? Call Cyber Defence at +91-75175-72000.