The problem is not the edge—it is the path around it
Content delivery networks and application security edges absorb abusive traffic, enforce rate limits, and challenge automated clients. Those protections lose much of their value when an attacker discovers a public origin address and sends traffic directly to it.
Services marketed as “CDN bypass” or “Cloudflare bypass” commonly look for operational exposure rather than a flaw in the CDN itself: historical DNS records, DNS-only hostnames, mail infrastructure sharing the web origin, leaked application responses, or an origin firewall that still accepts traffic from the public Internet.
The correct response is layered origin isolation. No application-only rule can substitute for network controls, and no single signal should be treated as proof that an address is malicious.
Redeyed's mitigation architecture
1. Make the origin private where possible
The strongest design removes unsolicited inbound Internet access to the application origin. An outbound-only tunnel can connect the origin to the edge without publishing the origin address. Where a tunnel is not practical, the origin firewall should accept web traffic only from the CDN's current published address ranges.
Cloudflare documents both approaches in its guidance for protecting origin servers and publishes the address ranges that must be kept current in Cloudflare IP addresses.
2. Authenticate edge-to-origin traffic
Network allowlisting proves that a request came through the provider's network, not that it belongs to the correct customer zone. Authenticated Origin Pulls adds mutual TLS so the origin can require a valid client certificate. A zone- or hostname-specific certificate provides stronger account isolation than a shared provider certificate.
See Cloudflare's Authenticated Origin Pulls documentation and its protocol explanation.
Redeyed also supports a rotated edge-to-origin secret as an application-layer check. It is defense in depth, not a replacement for mTLS.
3. Reject direct-origin requests in Laravel
Redeyed's Laravel origin guard evaluates the actual TCP peer address before trusting forwarded headers. It compares that peer against explicitly configured edge ranges and can require the edge secret. The guard supports two rollout modes:
- Monitor: record suspected direct-origin requests while allowing the response.
- Enforce: reject untrusted origin traffic with a generic response before application routes execute.
Only requests received from a trusted edge may influence the application’s visitor address. This prevents a client from manufacturing X-Forwarded-For or similar headers to appear trusted. Cloudflare similarly recommends restoring visitor addresses only behind a trusted proxy; its references explain original visitor IP restoration and Cloudflare HTTP headers.
4. Correlate signals in Shield
Shield classifies a direct-origin attempt as an origin_bypass vector. It correlates that observation with request rate, route targeting, authentication failures, user-agent behavior, and prior infrastructure history. Operators see recent mitigations with an Origin bypass or Suspicious badge and a privacy-masked address.
This distinction matters: a single connection can be a deployment mistake, health check, or stale integration. Repeated or multi-signal behavior is more meaningful.
5. Score and respond in Sentinel
Sentinel adds the origin-bypass signal to the IP reputation score and immediately recalculates the recommended action. Depending on accumulated evidence, the response can progress from observation to throttling, challenge, temporary block, and operator review.
Scores decay so that an address is not permanently stigmatized by old evidence. High-impact enforcement remains reviewable, and badges describe observed risk rather than asserting identity or intent.
Vector-to-control map
| Attack method or vector | Primary mitigation | Supporting detection |
|---|---|---|
| Direct HTTP(S) flood against a known origin | Private tunnel or firewall allowlist; authenticated origin pulls | Laravel origin guard; Shield origin_bypass event |
| Forged forwarding headers | Trust headers only when the TCP peer is an approved edge | Sentinel source and header consistency signals |
| Rotating botnet at the CDN edge | Managed rules, rate limits, challenges, endpoint-specific budgets | Shield behavioral correlation and Sentinel reputation |
| Application-layer resource exhaustion | Bounded request bodies, queue limits, caching, timeouts, per-route throttles | Latency, error-rate, route concentration, and concurrency telemetry |
| Volumetric network attack | Upstream CDN/DDoS provider and network capacity controls | Provider telemetry and origin saturation alarms |
| Origin discovery through DNS or shared services | Separate infrastructure, remove DNS-only exposure, rotate the origin after containment | Continuous asset inventory and historical DNS review |
A monitor-first rollout
- Inventory every hostname and service that can reveal or reach the origin.
- Move mail, control panels, and non-web services away from the application origin.
- Enable the Laravel guard in monitor mode and confirm legitimate edge, health-check, and deployment traffic.
- Restrict the network firewall and enable authenticated origin pulls or a private tunnel.
- Rotate the formerly exposed origin address when feasible.
- Turn on enforcement, alert on rejected traffic, and review allowlists whenever provider ranges change.
- Exercise failure recovery so an expired certificate or stale allowlist does not become an avoidable outage.
What this does—and does not—claim
This architecture does not claim that any provider is “bypass-proof.” It reduces the attack surface by ensuring that the origin is not a second, weaker public entrance. Laravel, Shield, and Sentinel provide application visibility and response, while the decisive controls remain at the network and TLS layers.
Redeyed records only the security evidence needed for mitigation, masks addresses in routine administrative views, uses time-bounded retention, and keeps suspicious labels tied to observable signals. The goal is a defensible decision trail with room for false-positive review—not an irreversible judgment about a person behind an address.