CDN
A CDN, or content delivery network, fronts an origin server, caches assets close to users and absorbs traffic spikes. In security terms it is a proxy layer, and the protection it provides is conditional: it holds only while the origin cannot be reached directly, which on most estates is not the case.
The protective functions are real. Absorbing a volumetric DDoS attack at the edge, terminating TLS, and inspecting requests through a web application firewall before they reach the application are all worth having. All three share one assumption: that traffic has to pass through the edge to arrive.
On an external engagement, testing that assumption is routine work rather than advanced research. The origin address leaks from certificate transparency records for the same hostname, from historical DNS, from mail headers sent by the same infrastructure, from a subdomain that was never put behind the edge, and from services on the same address that the edge does not proxy. When it is found, the request goes straight to the origin and every edge control is simply absent.
What we record in a report is the origin address, the method that revealed it, and a demonstration that a request the edge would have blocked succeeds directly. The fix is not a setting in the edge product: it is a firewall rule at the origin that accepts connections only from the provider’s published ranges, or mutual authentication between edge and origin, verified afterwards rather than assumed. That verification belongs to the external testing where finding the origin is a routine step.