Rework guides into uniform format: merge duplicates, clean code fence…

API_Testing/Hidden_API_Functionality_Exposure.md

@@ -1,24 +1,100 @@
 # Hidden API Functionality Exposure
-- Application programming interfaces (APIs) have become a critical part of almost every business. APIs are responsible for transferring information between systems within a company or to external companies. For example, when you log in to a website like Google or Facebook, an API processes your login credentials to verify they are correct.
 
-1. Swagger UI Documentation
-2. Dictionary Attack | Brute force
-3. Common wordlist for API Enum :
-- https://wordlists.assetnote.io/
-- https://github.com/Net-hunter121/API-Wordlist
+APIs are the backbone of modern applications, carrying data between internal systems and external consumers — but teams frequently expose functionality that was never meant to be public: interactive API docs (Swagger/OpenAPI), debug/admin endpoints, unreleased version routes, and entire hidden endpoint trees. Discovering these gives attackers a ready-made map of the attack surface and, when the docs or endpoints lack authentication, direct access to sensitive functionality and data. Impact ranges from full API schema disclosure to unauthenticated CRUD on backend objects.
 
-## Steps to Perform This Attack :
+## Hunting Checklist
+
+1. Capture normal application traffic and note the API base paths and versioning style (`/api/v1/...`).
+2. Check for exposed documentation UIs (Swagger UI, OpenAPI JSON/YAML, ReDoc, Postman/GraphQL equivalents) at common paths.
+3. If no docs are found, brute-force endpoint paths with API-specific wordlists (steps below).
+4. Compare status codes/lengths to filter noise; chase every HTTP 200 on a hidden endpoint.
+5. Recursively fuzz interesting endpoints (`/v1/users` → `/v1/users/export`, `/v1/users/admin`, ...).
+6. Sweep API versions: an endpoint blocked on `/api/v3/` may work unchanged on `/api/v1/` or `/api/v2/`.
+7. Test the same endpoints unauthenticated vs authenticated to find missing auth checks on hidden functionality.
+8. Mine JS bundles for API paths/parameters the UI never renders (routes for admin/staff features).
+9. Correlate with other modules: found endpoints should also be tested for IDOR, BOLA, mass assignment, rate limiting.
+
+## Test Cases & Examples
+
+### 1. Swagger / API documentation exposure
+
+Try the common documentation paths on the API host:
+
+```http
+GET /swagger/index.html HTTP/1.1
+GET /swagger-ui.html HTTP/1.1
+GET /swagger-ui/index.html HTTP/1.1
+GET /api/swagger-ui.html HTTP/1.1
+GET /api-docs HTTP/1.1
+GET /openapi.json HTTP/1.1
+GET /v2/api-docs HTTP/1.1
+GET /v3/api-docs HTTP/1.1
+GET /documentation HTTP/1.1
+GET /apispec.json HTTP/1.1
 ```
-Step 1 : Capture the request into Burp, Send the request to repeater and intruder tab.
-Step 2 : Add the endpoint into the intruder tab and add the payload from the word-list.
-Step 3 : First use dictionary attack with SecLists (https://github.com/danielmiessler/SecLists) on the Endpoint.
-Step 4 : Either use your customized list or use the ones which I have provided in the above step.
-Step 5 : Then simply start the attack, start checking for 200 status.
-Step 7 : Once there is HTTP 200 OK status, start the recursive scan on the same endpoint for juicy information like swagger doc and so on.
-step 8 : Other method is to change the API version and try bruteforcing the same endpoint
-Eg: Redacted.com/api/v1/{Endpoint} ----- Redacted.com/api/v2/{Endpoint}
+
+A 200 on any of these hands you every endpoint, parameter, and model of the API — including hidden admin/debug functions. From the docs (or `swagger.json`/`openapi.json`), extract the endpoint list and feed it into your fuzzer.
+
+### 2. Dictionary attack / endpoint brute force
+
+Steps to perform this attack:
+
+1. Capture a request into Burp, send it to Repeater and Intruder.
+2. Add the endpoint path as the payload position and load an API wordlist.
+3. First use a dictionary attack with [SecLists](https://github.com/danielmiessler/SecLists) against the endpoint.
+4. Then use a customized list or one of the API-specific lists (see Tools below).
+5. Start the attack and filter results for HTTP 200.
+6. Once there is an HTTP 200 OK, start a recursive scan on that same endpoint for juicy information like swagger docs and so on.
+7. Alternative method: change the API version and bruteforce the same endpoint.
+
+Same flow with a CLI fuzzer:
+
+```bash
+ffuf -u 'https://target.com/api/v1/FUZZ' \
+  -w SecLists/Discovery/Web-Content/api/api-endpoints.txt \
+  -mc 200,201,204,401,403,405 -fs 0
 ```
-* Note: There will be minimum limits per request which will be assigned without API keys so make sure to utilize manual approach as much as you can, then the rest can be automated for scanning the vulnerability in API with automated tools.
 
-## Contributor:
+### 3. API version sweeps
+
+```http
+GET https://redacted.com/api/v1/{Endpoint}   → 403/404
+GET https://redacted.com/api/v2/{Endpoint}   → 200 OK
+```
+
+```bash
+for v in v1 v2 v3 beta internal admin; do
+  curl -sk -o /dev/null -w "%{http_code} /api/$v/users\n" "https://target.com/api/$v/users"
+done
+```
+
+### 4. Response-code triage
+
+Hidden endpoints often differ from 404 noise: a `401/403` on an unlinked endpoint proves it exists, `405` means it exists with another verb (try GET/POST/PUT/DELETE/OPTIONS), and `200` on a GET to a normally-POSTed route can leak data or docs.
+
+## Bypass Techniques
+
+- **Rate limits / anti-bot on fuzzing:** there is a minimum request limit per unauthenticated session (no API key) — so utilize a manual approach as much as you can for high-value paths, then automate the rest of the scanning.
+- **Version-based WAF gaps:** `v1` routes are commonly excluded from the rules that protect the current `v3` API.
+- **Trailing slash / dot / case variants:** `/api/users` vs `/api/users/` vs `/API/Users` can evade naive path matching.
+- **Docs JSON without the UI:** `/swagger-ui.html` may be blocked while `/swagger.json`, `/openapi.json`, or `/v2/api-docs` is still served.
+
+## Tools & Resources
+
+- [Assetnote API wordlists](https://wordlists.assetnote.io/) — high-quality, continuously refined API endpoint/prefix lists.
+- [Net-hunter121/API-Wordlist](https://github.com/Net-hunter121/API-Wordlist)
+- [SecLists](https://github.com/danielmiessler/SecLists) — `Discovery/Web-Content/api/`
+- [OWASP API Security Top 10](https://owasp.org/www-project-api-security/) — project-BOLA and API inventory context.
+- Burp Suite (Intruder/Repeater), ffuf, or Kiterunner (routes built from API specs).
+- [Swagger Editor](https://editor.swagger.io/) — render any discovered `spec.json`/`spec.yml`.
+
+## Report Tips
+
+- Show the exact exposed URLs and, for docs, a redacted screenshot proving they describe the *production* API (endpoint count, auth flows listed).
+- Escalate the finding: don't just report Swagger UI — pick one undocumented endpoint it revealed and demonstrate real impact (unauthorized data read, admin action).
+- Quantify enumeration: "successfully enumerated N hidden endpoints / M admin functions, all unauthenticated" gives triage a measurable scope statement.
+- Note if the exposed API schema leaks internal implementation details (stack trace shapes, internal ids, PII field names) that aid further attacks.
+
+## Contributor
+
 - [N3T_hunt3r](https://twitter.com/N3T_hunt3r)

API_Testing/README.md

@@ -0,0 +1,15 @@
+# API Testing
+
+Practical methodology for hunting bugs in APIs.
+
+## Guides
+
+* [Hidden API Functionality Exposure](Hidden_API_Functionality_Exposure.md)
+* [Reverse Engineer an API](Reverse_Engineer_an_API.md)
+
+## Related
+
+* [GraphQL Hunting](../GraphQL/GraphQL.md)
+* [IDOR](../IDOR/IDOR.md) - most API bugs end up as broken object-level authorization
+* [JWT Attacks](../JWT/JWT.md)
+* [Rate Limit Bypasses](../Rate_limit/RateLimitBypass.md)

API_Testing/Reverse_Engineer_an_API.md

@@ -1,19 +1,69 @@
 # Reverse Engineer an API
-<img src="https://pasteboard.co/n2094TfDB8qt.png">
-
-## Tools to use
-1. FoxyProxy
-2. mitmweb
-3. mitmproxy2swagger
-4. https://editor.swagger.io/
-5. Postman
-
-## Steps to Reproduce
-1. **Foxyproxy:** Turn on 8080 port using Foxy Proxy.(Label it anything you want)
-2. **mitmweb:** Run `sudo mitmweb` and then go to mitm.it and install & import the certificate.
-3. **Explore Website w/ API's functionalities:** Go to the website w/ api that you want to gather the API endpoints from and explore it's functionalities. <br>The mitmweb tool will capture it,
-afterwards you can download the captures as a flow file in mitmweb by clicking on file -> save all.
-4. **mitmproxy2swagger:** Here we run `sudo mitmproxy2swagger -i flows -o spec.yml -p <website api> -f flow`. This will turn flows file to a yml file. Afterwards you need to remove the ignore: in the spec.yml and run
-`sudo mitmproxy2swagger -i flows -o spec.yml -p <website api> -f flow --examples`, --examples is added to enhance the documentation of the api endpoints.
-5. **https://editor.swagger.io/:** Now you can import the clean spec.yml file and visualize the different endpoints.
-6. **Postman:** You can also import the spec.yml in postman which will produce a well organized collection.
+
+Many products are driven by private mobile/desktop or undocumented web APIs with no published specification — but security testing of those APIs (auth flaws, hidden endpoints, business-logic abuse) starts with rebuilding their interface. This technique captures live traffic through a proxy, converts the recorded flows into an OpenAPI/Swagger specification, and turns it into a structured, testable API collection. The output becomes your attack-surface inventory for IDOR, rate-limit, and mass-assignment hunting.
+
+## Hunting Checklist
+
+1. Set up a local proxy on a known port (FoxyProxy to flip browser/mobile traffic on and off).
+2. Run `mitmweb`, then visit `mitm.it` from the proxied device to install and trust the CA certificate.
+3. Browse the target application and exercise *every* functional flow so the proxy records a representative corpus of API calls.
+4. Export the recorded traffic (`File → Save all`) to a flows file.
+5. Convert the flows file into a spec with `mitmproxy2swagger` (run twice: clean pass, then `--examples` pass for documentation).
+6. Remove the `ignore:` markers the tool inserts so all endpoints are kept in the spec.
+7. Import the spec into Swagger Editor to visualize and audit every endpoint, verb, and parameter.
+8. Import the same spec into Postman to get a ready-made, organized collection for replay and fuzzing.
+9. Review the collection for endpoints not referenced in the UI (hidden functions), then test authentication and object-level authorization on each.
+
+## Test Cases & Examples
+
+### 1. Start the proxy
+
+```bash
+# FoxyProxy: create a proxy profile pointing at 127.0.0.1:8080 (label it anything you want) and enable it
+sudo mitmweb --listen-port 8080
+```
+
+Then go to `http://mitm.it` through the proxy and install/import the certificate on the testing machine or device.
+
+### 2. Capture and export
+
+Explore the website/app and use its API-backed functionality — mitmweb records everything. Download the captures as a flow file: click `File → Save all`.
+
+### 3. Generate the spec
+
+```bash
+# Pass 1 — baseline spec from the recorded flows file
+sudo mitmproxy2swagger -i flows -o spec.yml -p '<website api>' -f flow
+
+# Edit spec.yml: delete the `ignore:` lines so no endpoint is dropped
+
+# Pass 2 — same command with --examples to embed request/response examples
+# (enhances the documentation of the API endpoints)
+sudo mitmproxy2swagger -i flows -o spec.yml -p '<website api>' -f flow --examples
+```
+
+### 4. Visualize and test
+
+- Import the clean `spec.yml` into [Swagger Editor](https://editor.swagger.io/) to visualize the different endpoints.
+- Import the same `spec.yml` in Postman to produce a well-organized collection — then replay with a second account's credentials and diff responses (auth/authz testing).
+
+## Bypass Techniques
+
+- **HTTPS inspection on mobile/emulators:** mitmweb works once its CA is installed; where certificate pinning blocks interception, standard practice is to bypass pinning on a rooted device/emulator with Frida/objection — only do this on apps you are authorized to test.
+- **Endpoints mitmproxy2swagger lumps together:** regex-path-normalized variables (ids, UUIDs) can hide distinct routes — check the raw flow list in mitmweb and add narrower `-p` patterns if the spec looks under-populated.
+- **Partial captures:** parameters seen only in one client platform (iOS) may be missing from a desktop-only capture; record flows across every client the API serves.
+
+## Tools & Resources
+
+1. [FoxyProxy](https://getfoxyproxy.org/) — browser proxy switcher (port 8080).
+2. [mitmweb](https://docs.mitmproxy.org/stable/tools-mitmweb/) — interactive MITM proxy with web UI.
+3. [mitmproxy2swagger](https://github.com/mitmproxy2swagger/mitmproxy2swagger) — flows file → OpenAPI spec converter.
+4. [Swagger Editor](https://editor.swagger.io/) — visualize/import the generated `spec.yml`.
+5. [Postman](https://www.postman.com/) — import the spec as a collection for replay/fuzzing.
+6. Burp Suite can replace this pipeline once the endpoints are known — use it for the actual security testing.
+
+## Report Tips
+
+- Frame the impact around what the rebuilt spec revealed: "undocumented API surface of N endpoints, including admin/financial functions" is the finding, not the tooling.
+- Attach (redacted) spec snippets and a short replay PoC showing an endpoint performing its function with an unauthorized/other-user session.
+- A reverse-engineered API is the evidence base for stronger chained findings (BOLA, missing rate limits, mass assignment) — reference this inventory in those reports so triage can reproduce quickly.