Update cloudflare-workers-pass-through-proxy-ip-rotation.md

Author: carlospolop

src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md

@@ -4,21 +4,21 @@
 
 Cloudflare Workers can be deployed as transparent HTTP pass-through proxies where the upstream target URL is supplied by the client. Requests egress from Cloudflare's network so the target observes Cloudflare IPs instead of the client's. This mirrors the well-known FireProx technique on AWS API Gateway, but uses Cloudflare Workers.
 
-Key capabilities:
+### Key capabilities
 - Support for all HTTP methods (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
 - Target can be supplied via query parameter (?url=...), a header (X-Target-URL), or even encoded in the path (e.g., /https://target)
 - Headers and body are proxied through with hop-by-hop/header filtering as needed
 - Responses are relayed back, preserving status code and most headers
 - Optional spoofing of X-Forwarded-For (if the Worker sets it from a user-controlled header)
 - Extremely fast/easy rotation by deploying multiple Worker endpoints and fanning out requests
 
-How it works (flow):
-1) Client sends an HTTP request to a Worker URL (<name>.<account>.workers.dev or a custom domain route).
+### How it works (flow)
+1) Client sends an HTTP request to a Worker URL (`<name>.<account>.workers.dev` or a custom domain route).
 2) Worker extracts the target from either a query parameter (?url=...), the X-Target-URL header, or a path segment if implemented.
 3) Worker forwards the incoming method, headers, and body to the specified upstream URL (filtering problematic headers).
 4) Upstream response is streamed back to the client through Cloudflare; the origin sees Cloudflare egress IPs.
 
-Worker implementation example
+### Worker implementation example
 - Reads target URL from query param, header, or path
 - Copies a safe subset of headers and forwards the original method/body
 - Optionally sets X-Forwarded-For using a user-controlled header (X-My-X-Forwarded-For) or a random IP
@@ -135,7 +135,8 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
 
 </details>
 
-Automating deployment and rotation with FlareProx
+### Automating deployment and rotation with FlareProx
+
 FlareProx is a Python tool that uses the Cloudflare API to deploy many Worker endpoints and rotate across them. This provides FireProx-like IP rotation from Cloudflare’s network.
 
 Setup
@@ -148,7 +149,7 @@ cd flareprox
 pip install -r requirements.txt
 ```
 
-Create config file flareprox.json:
+**Create config file flareprox.json:**
 
 ```json
 {
@@ -159,7 +160,8 @@ Create config file flareprox.json:
 }
 ```
 
-CLI usage
+**CLI usage**
+
 - Create N Worker proxies:
 ```bash
 python3 flareprox.py create --count 2
@@ -177,7 +179,7 @@ python3 flareprox.py test
 python3 flareprox.py cleanup
 ```
 
-Routing traffic through a Worker
+**Routing traffic through a Worker**
 - Query parameter form:
 ```bash
 curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
@@ -208,14 +210,16 @@ curl -X DELETE \
   "https://your-worker.account.workers.dev?url=https://httpbin.org/delete"
 ```
 
-X-Forwarded-For control
-If the Worker honors X-My-X-Forwarded-For, you can influence the upstream X-Forwarded-For value:
+**`X-Forwarded-For` control**
+
+If the Worker honors `X-My-X-Forwarded-For`, you can influence the upstream `X-Forwarded-For` value:
 ```bash
 curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
      "https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
 ```
 
-Programmatic usage
+**Programmatic usage**
+
 Use the FlareProx library to create/list/test endpoints and route requests from Python.
 
 <details>
@@ -274,30 +278,16 @@ except Exception as e:
 
 </details>
 
-Burp/Scanner integration
+**Burp/Scanner integration**
 - Point tooling (for example, Burp Suite) at the Worker URL.
 - Supply the real upstream using ?url= or X-Target-URL.
 - HTTP semantics (methods/headers/body) are preserved while masking your source IP behind Cloudflare.
 
-Operational notes and limits
+**Operational notes and limits**
 - Cloudflare Workers Free plan allows roughly 100,000 requests/day per account; use multiple endpoints to distribute traffic if needed.
 - Workers run on Cloudflare’s network; many targets will only see Cloudflare IPs/ASN, which can bypass naive IP allow/deny lists or geo heuristics.
 - Use responsibly and only with authorization. Respect ToS and robots.txt.
 
-Detection and mitigation (defender notes)
-If your application is the target and you wish to prevent access via generic Cloudflare-originated proxies (Workers, other Cloudflare egress):
-- Do not rely solely on IP allow/deny lists; Cloudflare Workers share Cloudflare IP space and ASN (AS13335). Blocking all Cloudflare IPs is often impractical.
-- Require strong request authentication at the application layer (tokens, HMAC-signed headers, mTLS, per-client API keys), and validate them server-side.
-- For Cloudflare-protected origins you control, consider:
-  - Authenticated Origin Pulls or mTLS between Cloudflare and origin so only your own zone can reach the origin.
-  - WAF/Firewall Rules that require a secret header or signed token and block requests missing them.
-  - API Shield (schema validation, mTLS, JWT validation) and Bot Fight Mode/Super Bot Fight Mode to reduce automated abuse.
-  - Rate limiting by path/user token; challenge or block requests lacking expected cookies/headers from your first-party app flows.
-- Monitor for anomalies: unusual user agents, inconsistent headers, rapidly shifting Cloudflare IPs, or requests to endpoints that should only be hit by your front-end.
-
-Related techniques
-- FireProx (AWS API Gateway) pioneered pass-through proxying for IP rotation and header control; Workers provide a similar pattern with Cloudflare egress.
-
 ## References
 - [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
 - [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)