Recently, Cloudflare outages have reignited an uncomfortable but necessary conversation among senior engineers: how much trust should we place in the edge?
These incidents were not catastrophic failures of security. Still, they were operationally disruptive enough to expose assumptions many teams make about availability, isolation, and responsibility when outsourcing critical controls to a global edge provider.
The Replay is a weekly newsletter for dev and engineering leaders.
Delivered once a week, it's your curated guide to the most important conversations around frontend dev, emerging AI tools, and the state of modern software.
This section is not about fault-finding because in reality, Cloudflare operates one of the most complex distributed networks in the world, and outages are an inevitable reality of systems at that scale. Instead, the goal is to reframe how senior engineers should think about Cloudflare’s role in their architecture, especially after seeing what happens when the edge is degraded.
When an edge provider experiences downtime, the instinctive reaction is to question reliability. However, a more productive response is to treat the event as a design signal because outages force teams to confront questions that are often ignored during steady-state operation:
(i) What actually breaks when the edge is unavailable?
(ii) Which guarantees were assumed but never explicitly designed for?
(iii) Where does our responsibility end, and where does the provider’s begin?
For senior engineers, these questions are architectural, not emotional. They help clarify whether Cloudflare is being used appropriately as an edge control plane or as a single point of truth for security and availability.
Cloudflare’s model implicitly follows a shared-responsibility pattern, even if it is not always framed that way, because these responsibilities can be categorised into the following:
(i) You remain responsible for the application layer authorisation, data integrity, origin resilience, fallback behavior and failure isolation.
(ii) While Cloudflare is responsible for global routing, DDoS absorption, WAF rule execution, TLS termination at the edge and the correctness of its control plane.
Therefore, it is safe to say that most outages expose gaps where teams have unintentionally delegated too much responsibility upward. A common example is relying solely on Cloudflare Access or WAF rules as the only enforcement layer, without compensating controls at the application or origin level.
Senior engineers should treat the edge as an augmenting layer, not a replacement for core security invariants.
One of the most dangerous misconceptions is equating Cloudflare’s global footprint with immunity from failure. While Cloudflare significantly reduces the blast radius of many attacks, it also introduces a new, distinct failure domain: the edge itself.
Some of the key distinctions to internalise include the following:
(i) Failure domains describe where things can break, like edge routing, control plane propagation, and regional PoPs.
(ii) Security guarantees describe what must never be violated, like the authentication, authorisation, and data access rules.
A mature architecture ensures that security guarantees hold even when a failure domain is compromised. For example:
Outages are stress tests for security architecture. They expose whether controls are truly defence-in-depth or merely defence-by-delegation.
The most important mindset shift for senior engineers is this: Cloudflare is a powerful control plane at the edge, not a silver bullet for security or reliability, and if used correctly, Cloudflare provides:
But if used incorrectly, it becomes a fragile choke point whose failure cascades directly into application downtime or security exposure.
As much as you want to trust the edge, it shouldn’t result in a blind reliance but rather consciously designing for partial failure, explicitly defining responsibilities and ensuring that your core security guarantees remain enforceable even when the edge is degraded.
In the next sections, we will translate this framing into concrete playbooks, like how to layer controls, design fallbacks and use Cloudflare’s features in ways that strengthen your system rather than over-concentrate risk.
Cloudflare operates as a reverse proxy in front of your infrastructure.
Request flow:
User → Cloudflare Edge → Origin (API, App, Load Balancer)
This placement is good because it allows Cloudflare to enforce security controls before requests reach your servers, reducing the attack surface, absorbing malicious traffic early, and offloading enforcement from origin infrastructure.
Crucially, this model is most effective when Cloudflare’s controls augment, not replace, application-level security. Edge enforcement should be treated as the first line of defence, not the only one.
This placement allows Cloudflare to enforce security controls before requests ever reach origin infrastructure, reducing attack surface, absorbing malicious traffic early, and offloading enforcement from backend systems.
Crucially, this model is most effective when Cloudflare’s controls augment rather than replace application-level security. Also, it is paramount to state that the edge enforcement should be treated as the first line of defence, not the only one.
At the network layer, Cloudflare has direct control over traffic before it reaches your infrastructure with the following capabilities:
Why this works well:
Attacks are absorbed by Cloudflare’s global Anycast network, preventing malicious traffic from ever reaching your origin.
At Layer 7, Cloudflare enforces controls based on request inspection, not on application semantics or intent. In this situation, some of Cloudflare’s pros include the following:
While some of Cloudflare’s cons include:
Also, some key limitations are that Cloudflare sees requests, not your application’s state, intent, or authorization model.
Some misconceptions most senior Engineers/architects have are “If it’s behind Cloudflare, it’s secure.” However, a reality check shows that:
Cloudflare is a powerful perimeter and traffic-control layer, not a complete security solution.
Even while Cloudflare helps with reducing surface attacks, blocking most automated, volumetric, and signature-based attacks, it does not replace secure coding, strong auth, or internal trust boundaries. Therefore, you must take extra care to ensure the following:
These measures help you to prevent malicious attackers from succeeding, even when traffic passes through Cloudflare.
The table below summarizes where Cloudflare is typically a strong fit, what it can reliably enforce at the edge, and what you still need to enforce at the origin and application layers:
| Use case | What Cloudflare does well | What you must still own | Common pitfall |
|---|---|---|---|
| DDoS protection (L3/L4) | Absorbs volumetric and protocol-level attacks at the edge using Anycast routing | Origin hardening, capacity planning for legitimate traffic | Assuming the origin does not need rate limits or firewall rules |
| Traffic filtering & rate limiting | Blocks abusive patterns early based on IP, ASN, geography, and request rates | Auth-aware throttling tied to user identity, session, or token | Treating rate limits as a replacement for application-layer abuse controls |
| Web Application Firewall (WAF) | Stops known, automated, and signature-based attacks at scale | Business-logic validation, authorization, and input handling | Confusing WAF coverage with application security guarantees |
| Bot management | Differentiates good vs. malicious bots using behavioral and reputation signals | Protecting sensitive workflows from authenticated or human-assisted abuse | Assuming bots are the only meaningful threat vector |
| Edge authentication (Access, JWT, headers) | Fast, centralized identity checks before traffic hits the origin | Enforcing auth and authorization inside the application | Blindly trusting edge headers without verification |
| API protection | Blocks basic abuse patterns and malformed requests | Schema validation, RBAC, and business invariants | Assuming managed rules fully understand custom APIs or GraphQL |
| Caching & performance | Reduces latency and origin load for static and cacheable content | Correct cache headers and explicit no-cache rules for sensitive data | Accidentally caching authenticated or user-specific responses |
| TLS termination & encryption | Manages certificates and enforces HTTPS globally | End-to-end encryption assumptions and origin trust boundaries | Assuming TLS termination equals full data security |
| Global policy enforcement | Centralized rules, fast propagation, and visibility | Change management, audits, and rollback strategies | Treating the control plane as infallible |
Cloudflare WAF is a Layer 7 control designed to detect and block malicious HTTP traffic before it reaches your origin. Its strength lies in stopping known, repeatable, and automated attack patterns at scale. Below are three (3) core capabilities where it consistently performs well in real-world systems.
Cloudflare uses managed rulesets to match and inspect traffic. These are pre-built, continuously maintained rule collections designed to detect and block common attack classes such as SQL injection (SQLi), cross-site scripting (XSS), remote code execution (RCE), and known CVEs.
Each incoming HTTP request is evaluated against signatures and heuristics across multiple components of the request, including:
Why is this effective?
Practical example
A login request containing a payload such as ' OR 1=1 -- within a request parameter is blocked at the edge, preventing the request from ever reaching the application or database.
Rate limiting is not just a performance tool; it is a foundational security control that limits attack amplification.
Why is this effective?
Practical example
Restricting login attempts to 5 requests per minute stops bots from testing thousands of credentials, protecting accounts even if passwords are weak.
Not all bots are malicious. Cloudflare differentiates good bots from bad bots using multiple signals rather than simple user-agent checks.
Why is this effective?
Practical example
An attacker using headless browsers to scrape pricing or inventory data is automatically challenged or blocked, while normal users remain unaffected.
Cloudflare WAF is a strong Layer 7 control, but its effectiveness is often overstated. Senior engineers get into trouble when WAF capabilities are confused with application-level guarantees. Understanding these limits is essential to avoiding false security assumptions.
The WAF evaluates request structure and patterns, not application intent. Abuse of valid workflows (for example, transferring more funds than allowed via a legitimate API endpoint) will pass through unchanged.
The application or API itself must enforce access control. A WAF cannot replace role-based access control (RBAC), session validation, or entitlement checks.
Modern APIs, especially those using custom endpoints, GraphQL, or gRPC, often expose attack surfaces that managed rulesets do not fully understand or cover.
Attackers using valid credentials can bypass WAF protections by exploiting business logic or authorised endpoints in unintended ways.
To reduce false positives, teams sometimes weaken or disable managed rules, re-exposing well-known attack vectors in the process.
GraphQL introspection, complex query payloads, and gRPC traffic frequently evade default signatures, requiring dedicated controls beyond standard WAF rules.
Cloudflare significantly reduces risk, but it cannot compensate for architectural or configuration mistakes. The following examples show common failure modes, why Cloudflare didn’t save the system and what mature designs do differently.
Sensitive API responses (user profiles, access tokens, or session data) were cached publicly due to misconfigured page rules or default caching behaviour.
WAF and DDoS protections operate on request inspection. Caching logic determines what data is stored and served. Cloudflare correctly served cached content even when that content should never have been cached.
Correct architecture
Cache-Control: private or no-store headers on sensitive endpointsThe origin IP or load balancer was publicly reachable, allowing attackers to bypass Cloudflare entirely and interact directly with backend services.
Cloudflare can only inspect traffic that passes through it. Direct-to-origin traffic is invisible to WAF, rate limiting and bot protections.
Multiple Page Rules, Transform Rules or Workers unintentionally overrode security headers or caching behaviour, reducing protections on critical endpoints.
Rules are applied in a defined order. Misconfigured precedence can silently undo security controls, such as disabling HSTS, altering headers or bypassing WAF rules.
Requests were processed by Cloudflare Workers or backend logic before authentication checks, allowing unauthenticated access to sensitive operations.
WAF and bot management evaluate request patterns, not authentication state. Authorisation must be explicitly enforced, not assumed.
Edge security providers like Cloudflare dramatically reduce risk, but they are not infallible. Mature architectures plan explicitly for partial outages, misconfigurations, and control-plane failures, ensuring core security guarantees survive even when the edge does not.
Specific Cloudflare POPs or services become unavailable, degrading or blocking traffic in certain regions.
Page rules, WAF policies, or caching settings unintentionally expose sensitive endpoints or introduce bypass paths.
Cloudflare dashboards or APIs experience outages, delayed propagation, or inconsistent rule enforcement.
Treat Cloudflare as a strategic layer in a defence-in-depth model, not a substitute for disciplined engineering, secure design, and ownership at the application layer. Happy coding!
Rich Harris (creator of Svelte) joined PodRocket this week to unpack his Performance Now talk, Fine Grained Everything.
AI agents don’t have to live in chat bubbles. This guide shows how A2UI lets agents generate real, interactive UIs, and walks through building a working React demo using Gemini and a2ui-bridge.
Learn how LLM routing works in production, when it’s worth the complexity, and how teams choose the right model for each request.
Compare key features of popular meta-frameworks Remix, Next.js, and SvelteKit, from project setup to styling.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
