[Fundamentals, SSL, Workers] Clarify visitor IP header trust

src/content/docs/dns/proxy-status/use-cases.mdx

@@ -26,10 +26,12 @@ When traffic is proxied through Cloudflare, the following behaviors apply. You m
 
 ### Source IP changes
 
-Your origin server sees Cloudflare IP addresses as the source of all requests instead of the end-user's IP address. Applications that rely on the source IP for authentication, rate limiting, or geolocation will not function as expected without additional configuration.
+Your origin server sees Cloudflare IP addresses as the source of all requests instead of the end-user's IP address. Applications that use source IPs for access restrictions, rate limiting, or geolocation need additional configuration.
 
 Cloudflare includes the original visitor IP address in the [`CF-Connecting-IP`](/fundamentals/reference/http-headers/) and `X-Forwarded-For` request headers. Configure your origin server to read the visitor IP from these headers. For more information, refer to [Restoring original visitor IPs](/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/).
 
+Do not use these headers as proof of a user's or client's identity. Before using their values for IP-based access restrictions or rate limiting, [authenticate traffic reaching your origin](/fundamentals/reference/http-headers/#trust-visitor-ip-headers). Allowlisting Cloudflare IP ranges alone does not identify your zone. [Worker subrequests](/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests) can also change visitor IP header values, depending on their destination.
+
 ### Client certificate (mTLS) validation
 
 When a record is proxied, TLS terminates at Cloudflare's global network. Cloudflare establishes a separate TLS connection to your origin server. This means the origin never receives the end-user's client certificate during the TLS handshake. You can achieve mTLS through the following:

src/content/docs/fundamentals/concepts/cloudflare-ip-addresses.mdx

@@ -50,7 +50,9 @@ For more specific guidance, contact your hosting provider or website administrat
 
 ### Block other IP addresses (recommended)
 
-If someone discovers your origin server's IP address — for example, through historical DNS records or mail server configuration — they could send traffic directly to your server, bypassing Cloudflare's security protections entirely. To prevent this, block all traffic that does not come from Cloudflare IP addresses or the IP addresses of your trusted partners, vendors, or applications.
+If someone discovers your origin server's IP address — for example, through historical DNS records or mail server configuration — they could send traffic directly to your server, bypassing Cloudflare's security protections entirely. To restrict direct access, block all traffic that does not come from Cloudflare IP addresses or the IP addresses of your trusted partners, vendors, or applications.
+
+Cloudflare IP ranges are shared across customers. Allowlisting them does not prove that a request passed through your zone or its security rules. Combine this network filter with [origin authentication](/fundamentals/reference/http-headers/#trust-visitor-ip-headers), especially before trusting visitor IP headers for security decisions.
 
 For example, you might [update your iptables](https://www.linode.com/docs/guides/control-network-traffic-with-iptables/#block-or-allow-traffic-by-port-number-to-create-an-iptables-firewall) with the following commands:
 

src/content/docs/fundamentals/reference/http-headers.mdx

@@ -22,8 +22,7 @@ For incoming requests, the value of this header will always be set to `accept-en
 
 ### CF-Connecting-IP
 
-`CF-Connecting-IP` provides the client IP address connecting to Cloudflare to the origin web server.
-This header will only be sent on the traffic from Cloudflare's edge to your origin web server.
+`CF-Connecting-IP` provides the client IP address connecting to Cloudflare to the origin web server. For requests made by Workers, the value depends on the subrequest destination. Refer to [CF-Connecting-IP in Worker subrequests](#cf-connecting-ip-in-worker-subrequests).
 
 For guidance on logging your visitor's original IP address, refer to [Restoring original visitor IPs](/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/).
 
@@ -35,12 +34,26 @@ In same-zone Worker subrequests, the value of `CF-Connecting-IP` reflects the va
 
 In cross-zone subrequests from one Cloudflare zone to another Cloudflare zone, the `CF-Connecting-IP` value will be set to the Worker client IP address `'2a06:98c0:3600::103'` for security reasons.
 
-For Worker subrequests destined for a non-Cloudflare customer zone, the Worker script controls the client IP headers: both `CF-Connecting-IP` and `x-real-ip` can be altered by the Worker. If the subrequest forwards the original request's headers unchanged, both headers reflect the client's IP address.
-
-To authenticate that traffic originates from your own zone, use zone-level or per-hostname [Authenticated Origin Pulls](/ssl/origin-configuration/authenticated-origin-pull/) with your own certificate, or [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/).
+For Worker subrequests to destinations not proxied by Cloudflare, the Worker can set or overwrite `CF-Connecting-IP`. The destination can therefore receive a value chosen by the Worker. `x-real-ip` is an internal Cloudflare header and is stripped before delivery to these destinations.
 
 When no Worker subrequest is triggered, `cf-connecting-ip` reflects the client's IP address and the `x-real-ip` header is stripped.
 
+#### Trust visitor IP headers
+
+:::caution[Protect the Cloudflare-to-origin connection]
+Visitor IP headers are not authentication credentials for users or clients. An IP address can be shared by multiple users.
+
+A connection from a [Cloudflare IP address](/fundamentals/concepts/cloudflare-ip-addresses/) does not prove that a request passed through your zone or its security rules. Cloudflare IP ranges are shared across customers.
+
+Before using `CF-Connecting-IP`, `True-Client-IP`, or `X-Forwarded-For` for IP-based access restrictions or rate limiting, authenticate the Cloudflare-to-origin connection.
+
+For public HTTPS origins, we recommend mutual TLS (mTLS) using [zone-level](/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/) or [per-hostname Authenticated Origin Pulls](/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/). Use a certificate dedicated to your zone or hostname, and configure your origin to require and verify client certificates. Reject requests with missing or untrusted certificates. Global AOP uses a shared certificate and does not identify your zone.
+
+Alternatively, use [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/) and block direct public access to your origin.
+
+Your own Workers must also preserve or set visitor IP headers according to your application's trust requirements.
+:::
+
 ### CF-Connecting-IPv6
 
 Cloudflare provides [free IPv6 support](/network/ipv6-compatibility/) to all domains without requiring additional configuration or hardware. To support migrating to IPv6, Cloudflare's [Pseudo IPv4](/network/pseudo-ipv4/) provides an IPv6 to IPv4 translation service for all Cloudflare domains.
@@ -61,6 +74,8 @@ If [Pseudo IPv4](/network/pseudo-ipv4/) is set to `Add Header` - Cloudflare auto
 
 There is no difference between the `True-Client-IP` and `CF-Connecting-IP` headers besides the name of the header. Some Enterprise customers with legacy devices need `True-Client-IP` to avoid updating firewalls or load-balancers to read a custom header name.
 
+`True-Client-IP` does not provide additional authentication. The same [visitor IP header trust requirements](#trust-visitor-ip-headers) apply.
+
 To add a `True-Client-IP` HTTP header to requests, [enable the **Add "True-Client-IP" header** Managed Transform](/rules/transform/managed-transforms/configure/).
 
 Alternatively, if you do not wish to receive the `True-Client-IP` header or any HTTP header that may contain the visitor's IP address, [enable the **Remove visitor IP headers** Managed Transform](/rules/transform/managed-transforms/configure/).
@@ -83,6 +98,8 @@ Using the previous example where a request was proxied twice (proxies A and B) b
 
 :::note
 To restore the original visitor IP address at your origin web server, Cloudflare recommends that your logs or applications look at `CF-Connecting-IP` or `True-Client-IP` instead of `X-Forwarded-For`. `CF-Connecting-IP` and `True-Client-IP` both have a consistent format containing only one IP address.
+
+Before relying on these values for security decisions, follow the [visitor IP header trust requirements](#trust-visitor-ip-headers).
 :::
 
 ### X-Forwarded-Proto

src/content/docs/network/true-client-ip-header.mdx

@@ -9,6 +9,8 @@ products:
 
 Enabling the True-Client-IP Header adds the [`True-Client-IP` header](/fundamentals/reference/http-headers/#true-client-ip-enterprise-plan-only) to all requests to your origin server, which includes the end user's IP address.
 
+Do not use `True-Client-IP` to authenticate users or clients. Follow the [visitor IP header trust requirements](/fundamentals/reference/http-headers/#trust-visitor-ip-headers) before using its value for IP-based access restrictions or rate limiting.
+
 ## Availability
 
 |  | Free | Pro | Business | Enterprise |
@@ -20,7 +22,7 @@ Enabling the True-Client-IP Header adds the [`True-Client-IP` header](/fundament
 The recommended procedure to access client IP information is to [enable the **Add "True-Client-IP" header** Managed Transform](/rules/transform/managed-transforms/reference/#add-true-client-ip-header).
 
 :::note
-To use this data, you will need to then retrieve it from the [`True-Client-IP` header](/fundamentals/reference/http-headers/#cf-ipcountry).
+To use this data, you will need to then retrieve it from the [`True-Client-IP` header](/fundamentals/reference/http-headers/#true-client-ip-enterprise-plan-only).
 :::
 
 ## Additional resources

src/content/docs/rules/transform/request-header-modification/index.mdx

@@ -59,7 +59,9 @@ You can create a request header transform rule [in the dashboard](/rules/transfo
 
 - Due to protocol compliance reasons, modifying or removing request headers with [forbidden header names](https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name) (such as `Accept-Encoding`) is generally not allowed in Request Header Transform Rules.
 
-- You cannot modify the value of any header commonly used to identify the website visitor's IP address or initial protocol, such as `x-forwarded-for`, `true-client-ip`, `x-real-ip`, or `x-forwarded-proto`. If your origin needs a custom value in a header like `x-real-ip` on requests reaching your origin server, use [Cloudflare Snippets](/rules/snippets/) or [Cloudflare Workers](/workers/) and set the header on a `fetch()` subrequest. The value must be a syntactically valid IP address. This workaround does not work for cross-zone subrequests, where Cloudflare unconditionally replaces the value with an internal Cloudflare address to prevent IP spoofing.
+- You cannot modify the value of any header commonly used to identify the website visitor's IP address or initial protocol, such as `x-forwarded-for`, `true-client-ip`, `x-real-ip`, or `x-forwarded-proto`.
+
+- For custom visitor IP values in [Worker subrequests](/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests), behavior depends on the destination. In same-zone subrequests, setting `x-real-ip` to a valid IP address changes `CF-Connecting-IP`. Cross-zone subrequests to another Cloudflare zone use a fixed Worker IP address. For destinations not proxied by Cloudflare, a Worker can set `CF-Connecting-IP`, but `x-real-ip` is stripped before delivery.
 
 - Although you can remove the `x-forwarded-for` header in a Request Header Transform Rule, Cloudflare's backend proxy re-adds it (with the visitor's IP address) before the request reaches your origin server, because the proxy runs after all rule phases. The same applies to [Managed Transforms](/rules/transform/managed-transforms/). However, if the request is handled by Cloudflare Workers — which [run before the cache](/workers/reference/how-the-cache-works/) — the `x-forwarded-for` request header will be absent because the proxy has not yet re-added it.
 

src/content/docs/ssl/origin-configuration/authenticated-origin-pull/index.mdx

@@ -19,7 +19,13 @@ Authenticated Origin Pulls (AOP) helps ensure requests to your origin server com
 Authenticated Origin Pulls does not apply when your [SSL/TLS encryption mode](/ssl/origin-configuration/ssl-modes/) is set to **Off** or **Flexible**.
 :::
 
-Without AOP, anyone who discovers your origin server's IP address can send requests directly, bypassing Cloudflare and all its protections. When you combine AOP with the [Cloudflare Web Application Firewall (WAF)](/waf/), your origin only accepts requests that have passed through Cloudflare, which means every request is evaluated by the WAF before reaching your server.
+If your origin accepts unauthenticated public connections, anyone who discovers its IP address can send requests directly, bypassing Cloudflare and its protections. AOP lets your origin require a client certificate from Cloudflare.
+
+:::caution[Use your own certificate to identify your zone]
+For public HTTPS origins that rely on visitor IP headers for IP-based access restrictions or rate limiting, we recommend mutual TLS (mTLS) using zone-level or per-hostname AOP with [your own certificate](#when-to-use-your-own-certificate). Use a certificate dedicated to your zone or hostname, and configure your origin to require and verify client certificates. Reject requests with missing or untrusted certificates.
+
+Global AOP uses a certificate shared across Cloudflare accounts. When your origin validates it, it authenticates Cloudflare's network but does not identify your account or zone. Enabling AOP in Cloudflare alone does not enforce certificate validation at your origin.
+:::
 
 :::note[Not compatible with Cloudflare Tunnel]
 AOP is not compatible with origins connected through [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/). Tunnel uses outbound-only connections from your origin, so there is no inbound listener for Cloudflare to present a client certificate to. If your origin is reachable through Cloudflare Tunnel, origin traffic is already authenticated using the tunnel's connector credentials, and AOP settings have no effect on that hostname.
@@ -48,7 +54,7 @@ AOP has three independent configuration levels. Each uses its own certificate an
 
 ## When to use your own certificate
 
-Global AOP uses a Cloudflare-provided certificate shared across all accounts, so it only proves a request came from the Cloudflare network — not from your account specifically. If you need to guarantee requests come from your account, set up [zone-level](/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/) or [per-hostname](/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/) AOP with your own certificate.
+Global AOP uses a Cloudflare-provided certificate shared across all accounts. Validating this certificate authenticates the Cloudflare network but does not identify your account or zone. To distinguish traffic for your zone or hostname, set up [zone-level](/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/) or [per-hostname](/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/) AOP with a dedicated certificate, and enforce client certificate validation at your origin.
 
 Using your own certificate is also required for [FIPS](https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards) compliance. For broader origin protection guidance, refer to [Protect your origin server](/fundamentals/security/protect-your-origin-server/).