Publish Latest 2026-06-29

latest/4-Web_Application_Security_Testing/12-API_Testing/01-API_Reconnaissance.md

@@ -89,7 +89,7 @@ Even if you have the API documentation browsing the application is a good idea.
 
 Browsing the application with an intercepting proxy such as ZAP or Burp Suite records endpoints for later inspection. In addition, using their built-in spidering functionality, intercepting proxies can help generate a comprehensive list of endpoints. From the spidered URLs look for links with obvious API URL naming schemes. These include:
 
-- `https://example.com/api/v1` (or v2 etc)
+- `https://example.com/api/v1` (or v2 etc)  
 - `https://example.com/graphql`
 
 Or subdomains the the applications may consume or depend upon:
@@ -100,6 +100,18 @@ It is important that the pentester attempts to exercise as much functionality in
 
 Once completed, the endpoint information obtained from browsing and spidering of the application can help the pentester compose API documentation of the target using other tools such as Postman.
 
+### Analyze Intercepted Requests
+
+When auditing REST APIs, use an interception proxy to collect full HTTP requests. REST services utilize more than just URL parameters, so capturing the complete request body and headers is critical.
+
+Analyze the collected requests to identify non-standard or hidden parameters:
+
+- Identify HTTP headers that influence application behavior or resource selection.
+- Determine if a URL segment has a repeating pattern across multiple URLs. Patterns containing dates, numbers, or identifier values may indicate a URL-embedded parameter. For example, in the URL `https://api.example.com/user/2026-10-03/profile`, the date segment may represent a parameter value.
+- Identify structured parameter values formatted in JSON, XML, or other custom structures.
+- Examine the final element of a URL. If it lacks a file extension, it may be a parameter.
+- Look for highly varying URL segments. If a single segment changes frequently across hundreds of requests, it is more likely to represent a parameter value than a static path component.
+
 ### Google Dorking
 
 Using passive reconnaissance techniques such as Google Dorking with directives such as `site` and `inurl` allows us to tailor a search for common API keywords that the Google indexer may have found. Review [Conduct Search Engine Discovery Reconnaissance for Information Leakage](../01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md) for additional information.
@@ -132,7 +144,7 @@ An excellent source of API and other information is the HTML and JavaScript that
 
 There are a variety of tools that we can use to help us extract sensitive information from JavaScript transmitted to the browser. These tools are typically based on one of two approaches: Regular Expressions or Abstract Syntax Trees (AST). Then there are generalized tools that help us organize or manage JS files for investigation by AST and Regular Expression tools.
 
-Regex is more straightforward by searching JS or HTML content for known patterns. However, this approach can miss content not explicitly identified in the Regular Expression. Given the structure of some JS this approach can miss a lot. ASTs on the other hand are tree-like structures that represent the syntax of source code. Each node in the tree corresponds to a part of the code. For JavaScript, an AST breaks the code into basic components, allowing tools and compilers to understand and modify the code easily.
+Regular expression is more straightforward by searching JS or HTML content for known patterns. However, this approach can miss content not explicitly identified in the Regular Expression. Given the structure of some JS this approach can miss a lot. ASTs on the other hand are tree-like structures that represent the syntax of source code. Each node in the tree corresponds to a part of the code. For JavaScript, an AST breaks the code into basic components, allowing tools and compilers to understand and modify the code easily.
 
 #### General Tools
 
@@ -180,7 +192,7 @@ kr scan https://example.com/api -w /usr/share/wordlists/apis/routes-large.kite -
 
 All three of FFUF, DirBuster, and GoBuster are designed to discover hidden paths and files on web servers through brute-forcing techniques. All three use customizable wordlists to generate requests to the target web server, attempting to identify valid directories and files. All three support multi-threaded or highly efficient processing to speed up the brute-forcing process.
 
-Some common wordlist files for APIs include: [SecLists](https://github.com/danielmiessler/SecLists) in the Discovery/Web-Content/api section, [GraphQL Wordlist](https://github.com/Escape-Technologies/graphql-wordlist), and [Assetnote](https://wordlists.assetnote.io/).
+Some common wordlist files for APIs include: [SecLists](https://github.com/danielmiessler/SecLists) in the Discovery/Web-Content/API section, [GraphQL Wordlist](https://github.com/Escape-Technologies/graphql-wordlist), and [Assetnote](https://wordlists.assetnote.io/).
 
 GoBuster Example:
 

latest/4-Web_Application_Security_Testing/12-API_Testing/03-Testing_for_Excessive_Data_Exposure.md

@@ -108,6 +108,10 @@ Example: An order endpoint returning an embedded customer object, a payment obje
 
 Each nested object should be reviewed for fields that exceed what the consuming client needs.
 
+### Test for Mass Assignment
+
+For endpoints that accept a JSON or XML body, test for mass assignment vulnerabilities by adding extra fields to the request body beyond those displayed in the application interface. Fields such as role identifiers, privilege flags, or account status attributes are high-value targets.
+
 ### Check for Sensitive Data in GraphQL Responses
 
 GraphQL APIs present a specific form of this issue. While GraphQL allows clients to select which fields they want, the schema may expose sensitive fields that the default UI queries do not request but that an attacker can add to a custom query.

latest/4-Web_Application_Security_Testing/12-API_Testing/04-API_Broken_Function_Level_Authorization.md

@@ -54,11 +54,11 @@ Authorization: Bearer <regular_user_token>
 
 ### Test Function-Level Access with Different HTTP Methods
 
-Test various **HTTP methods** for BFLA vulnerabilities:
+Test various **HTTP methods** for BFLA vulnerabilities. Test each identified resource with alternative HTTP methods. Issue requests using methods other than those documented (such as `PUT`, `DELETE`, or `PATCH`) against endpoints that normally accept only `GET` or `POST`. Record any difference in response behavior or authorization outcome.
 
-- **GET**: Attempt to access information available only to high-privilege users (e.g., administrators).
+- **GET**: Attempt to access information available only to high-privilege users, such as administrators.
     - Example: `GET /api/admin/getAllUsers`
-- **POST/PUT/PATCH**: Attempt to modify or create sensitive resources (e.g., changing user roles, creating or deleting system-critical data).
+- **POST/PUT/PATCH**: Attempt to modify or create sensitive resources, such as changing user roles or system-critical data.
     - Example: `POST /api/admin/promoteUser { "userId": "12345", "newRole": "admin" }`
 - **DELETE**: Attempt to delete sensitive resources, such as removing user accounts or data.
     - Example: `DELETE /api/admin/deleteUser/12345`