Shielding changes what the internet can see
A public application usually has two surfaces: the user-facing hostname and the origin infrastructure behind it. Without shielding, scanners and attackers may be able to reach both. With a properly configured CDN and WAF layer, the public internet reaches the edge provider first, while the origin only accepts traffic from trusted edge networks.
Providers such as Cloudflare, Akamai, Fastly, and AWS CloudFront are commonly used for this pattern. The important control is not the brand name. The important control is whether the origin is protected from direct access.
Exposed origin versus shielded origin
- Exposed: the application domain points to a CDN, but the origin IP still accepts direct HTTP or HTTPS traffic from anywhere.
- Shielded: the origin firewall only allows traffic from the CDN or reverse proxy layer.
- Exposed: attackers can bypass edge rate limits and WAF rules by sending requests straight to the origin IP.
- Shielded: direct-to-origin traffic is dropped before it reaches the application.
What a WAF can reduce
A web application firewall can inspect HTTP requests before they reach the application. It can block known exploit payloads, suspicious request patterns, protocol abuse, high-volume probing, and automated attacks against common paths.
Typical examples include:
- blocking requests for known vulnerable paths in old CMS plugins;
- challenging credential stuffing and automated login attempts;
- filtering obvious SQL injection and command injection payloads;
- rate limiting abusive clients before they consume origin resources;
- applying emergency rules during active exploitation of a new vulnerability.
What a CDN adds
A CDN can absorb traffic closer to the client, cache static assets, terminate TLS, and reduce the amount of traffic that reaches the origin. During attack traffic or aggressive scanning, this can preserve application availability and reduce noise in backend systems.
For security teams, the CDN also becomes a useful control point. Logs, firewall events, bot scores, country rules, rate limits, and managed rules can all be reviewed without changing application code.
Common misconfiguration
The most common mistake is deploying a CDN in front of an application while leaving the origin publicly reachable. In that state, the organization gets some benefits, but attackers can still scan for the origin IP through DNS history, certificate transparency logs, old records, misconfigured subdomains, or response fingerprinting.
Once the origin is found, requests can bypass the WAF entirely unless the origin firewall enforces allowlists or authenticated origin pulls.
Practical hardening checklist
- Allow inbound origin traffic only from trusted CDN or proxy IP ranges.
- Use authenticated origin pulls, mTLS, or signed origin requests where supported.
- Remove old DNS records that point directly to origin infrastructure.
- Check certificate transparency logs for hostnames that expose backend services.
- Block direct access to administrative paths unless they are behind stronger access controls.
- Review WAF events regularly instead of treating the WAF as a set-and-forget control.
What good shielding looks like externally
From the outside, a shielded application should reveal the CDN or edge layer, not the backend server. Direct requests to suspected origin IPs should fail, return a generic block, or require a trusted edge identity. The application should still function normally through the public hostname.
This does not eliminate the need to patch the application. It reduces the number of paths attackers can use to reach it and gives defenders a central place to filter, observe, and respond.