Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What kind of security risk arises if Trusted Proxy is misconfigured (IP Spoofing)?
Short answer
The main risk is IP Spoofing. If Trusted Networks is entered too broadly in the Trusted Proxy profile (e.g. 0.0.0.0/0) or X-Forwarded-For (first) is selected in the Real IP from field, the client writes any IP it wants into the header and TR7 accepts this address as the client address: Conditions, WAF, Bot & DDoS Protection (protections based on the source IP, such as IP Reputation Protection, Country Control and Source IP Request Protection) and logs follow the fake address; the attacker can evade blocks or get another IP blocked. A header coming from an untrusted source, on the other hand, is not deleted; it goes to the Backend Service as it is (Operational best practices).
How Does It Work?
If the address the connection comes from is within Trusted Networks, TR7 makes the address in the header the client address; otherwise, it ignores the header. For this reason, anyone who can write a header from inside the trusted network can determine the client address.
| Configuration | Result |
|---|---|
Trusted Networks too broad (e.g. 0.0.0.0/0, /1) | Any client can write a fake IP into the header; the form gives a warning but does not prevent saving |
| X-Forwarded-For (first) | The client writes the first value of the chain; it can be spoofed even if it comes from the trusted network |
| TR7 is also open directly to the internet | The header of a client that bypasses the CDN is not used, because it comes from outside the trusted network; however, this traffic has not passed through the CDN's protections |
| The untrusted header going to the Backend Service | If the application reads the first value of X-Forwarded-For, it can be deceived |
| Wrong order in multiple sources | The first matching source wins; a broad source can shadow a narrow one |
Precautions
- Only the ranges published by the CDN are entered in Trusted Networks, and they are updated regularly.
- X-Forwarded-For (last / most trusted) or the CDN's own header (Custom Header) is used.
- Access to TR7 only from the CDN is ensured with a firewall.
- For fake headers going to the Backend Service, the Delete HTTP Header action is considered; on the application side as well, the client IP is read only from the trusted header.
Verification
A request with a fake header is sent directly to TR7 from a machine outside the trusted network (e.g. curl -H "X-Forwarded-For: 198.51.100.66" https://www.example.com/); on the vService's HTTP Logs screen, the real address of the machine must appear, not 198.51.100.66.
Common Misconceptions
- "Broad ranges are ignored by TR7." The form only gives a warning; the range is applied.
- "Keeping the range narrow is a security risk." A narrow or outdated list is only a functionality problem: the real IP is not resolved, and the CDN address continues to appear.
- "A header coming from an untrusted source is deleted." It is only not taken into account; it is not deleted.
How it is done in the documentation
Related questions
- What is the difference between the "Real IP from" options in the Trusted Proxy profile (X-Forwarded-For (last / most trusted), X-Forwarded-For (first), Custom Header)?
- Which components use the IP resolved by Trusted Proxy (log, condition, WAF, Bot & DDoS Protection)?
- There is a CDN such as Cloudflare / Akamai in front of TR7; how do I get the Real client IP (trusted proxy)?
