15 — Security and Performance at the Edge

"Cloudflare makes things fast and safe, somehow" was my security-and-performance model, and it couldn't explain any of the levers. The separation that fixed it: security comes from the isolate architecture, the headers I set, and the TLS terminated at the edge; performance comes from the cache and from rewriting responses in flight. [1][2] Two different concerns, both applied at the edge because that's where the request lands.

The framing that landed is the layering. Cloudflare sits in front of my origin (or _is_ the origin, in a pure Workers app), which means every request passes through its security and performance machinery before reaching anything I wrote. The default settings already do a lot — DDoS mitigation, TLS termination, a CDN cache — and the work is in understanding what each layer does so I can configure it correctly rather than fighting it.

The Workers security model

The foundation is the runtime architecture itself. Workers run in V8 isolates — the same sandboxing technology Chrome uses to keep one website from interfering with another [3][4]. The consequences for security:

• Strong isolation between tenants. One Worker cannot read another's memory, even though they share the same physical machine. V8 was designed for exactly this kind of adversarial co-tenancy.
• No ambient access to the outside world. A Worker can only reach external resources it's been given a binding to. There's no filesystem to wander, no child_process to spawn, no implicit network access to internal services.
• Bounded execution. CPU-time limits prevent a runaway Worker (or a malicious one) from consuming unbounded resources.

This is the "secure by construction" part. Where a traditional server has to be secured against the things it might do, a Worker is secured by the things it _can't_ do [3].

Web security headers

On top of the runtime, Cloudflare makes it straightforward to set the HTTP response headers that harden the browser side [5]. The ones worth knowing:

• Content-Security-Policy (CSP). The big one — declares which sources the browser is allowed to load scripts, styles, images, and other resources from. A tight CSP stops most cross-site scripting (XSS) attacks dead, because injected scripts from disallowed origins are refused.
• Strict-Transport-Security (HSTS). Tells the browser "only ever connect to this site over HTTPS." Prevents SSL-stripping attacks where a man-in-the-middle downgrades the connection.
• X-Frame-Options. Prevents the page from being embedded in an iframe on another domain — a clickjacking defense.
• Referrer-Policy. Controls how much referrer information is sent with outgoing requests.

A Worker can set these on every response, or Cloudflare's dashboard can apply them globally. The mental note I keep: CSP is the highest-leverage one. A correct CSP is the difference between an XSS bug being a nuisance and being a catastrophe.

Edge SSL/TLS

TLS termination is the point where the encrypted connection from the user's browser is decrypted — and doing it at the edge, rather than at the origin, has both security and performance implications [6]:

• Closer to the user. The TLS handshake (which adds a round trip) happens at the nearby edge, not at a distant origin. The connection establishes faster.
• DDoS absorption. The edge is built to absorb volumetric attacks; a TLS flood hits Cloudflare's network, not my origin.
• Origin protection. With TLS terminated at the edge, my origin can sit behind Cloudflare and accept only encrypted, proxied traffic — never direct exposure.

The certificate options Cloudflare offers — Universal SSL (free, basic), Dedicated SSL (custom cert), Origin CA (for the Cloudflare-to-origin leg) — are all variations on "where does the cert come from and what does it cover" [6]. Universal SSL covers the vast majority of cases; the others are for specific needs (wildcard certs, extended validation, legacy client support).

Bot management

Not all traffic is human, and not all non-human traffic is benign. Bot management identifies automated traffic and lets me respond to it [7]:

• Detection. Machine learning and behavioral analysis classify requests as likely-human or likely-bot, based on signals like request patterns, headers, and TLS fingerprinting.
• Response. Per the classification, Cloudflare can allow, challenge (a CAPTCHA or JS check that bots fail), or block.

The threat model bot management addresses is the automated one: credential stuffing (attackers trying stolen password lists), content scraping, form spam, and the application-layer DDoS where bots flood specific endpoints. The detection is probabilistic — it's about raising the cost to the attacker and filtering the noise, not a binary "bot or not."

(I omitted the marker definition for psarrow in that SVG — it uses the same sparrow arrow.)

The Cache API

On the performance side, the Cache API gives a Worker programmatic control over what gets cached and how [8]. Unlike the standard CDN cache (which is governed by HTTP headers), the Cache API lets me:

• Cache a Response object directly, with a cache key I choose.
• Read from the cache programmatically and decide whether to use a cached value.
• Vary cache keys on anything — the request URL, a header value, a derived key — not just the URL path.

The leverage is in the keys. A cache keyed on the URL serves the same response to everyone; a cache keyed on URL + country can serve personalized-but-cached responses per region; a cache keyed on URL + auth-context can cache per-user data safely. The Cache API is what turns the cache from "a thing that happens to my responses" into "a tool I program."

HTML rewriting

The other performance and flexibility lever is HTMLRewriter — a streaming HTML parser that lets a Worker modify HTML as it flows through, without buffering the whole document [9]. The use cases:

• A/B testing. Inject a different variant of an element for a subset of users.
• Personalization. Tailor part of a cached page based on a cookie or a header, without busting the whole-page cache.
• Lazy augmentation. Add analytics scripts, ad tags, or third-party widgets to a page on the way out, so the origin doesn't have to know about them.
• Sanitization. Strip something unwanted (a script, a meta tag) from a response on the fly.

The reason this is a performance feature as much as a flexibility one is the streaming. The Worker doesn't wait for the full HTML, doesn't parse it into a DOM, doesn't re-serialize it. It processes elements as they stream past, which means the latency cost is tiny — often small enough to be invisible compared to buffering and rewriting the whole document.

How I use this

The shape I keep: I treat Cloudflare's default security stack as the baseline (it's on, it works, I mostly don't touch it), I add a tight CSP on top because it's the highest-leverage header, I terminate TLS at the edge and let my origin sit behind it, and on the performance side I program the cache explicitly for the hot paths rather than relying on default header-based caching. HTMLRewriting I reach for when I need to modify a response without regenerating it — A/B tests, lazy script injection, sanitization — and I avoid it when a simpler header or cache-key change would do. The discipline is to reach for the lightest tool that solves the problem, because every layer of rewriting adds complexity that someone will have to debug later.

References

[1] Cloudflare, "Application security & performance solutions," Cloudflare Solutions, 2024. [Online]. Available: https://www.cloudflare.com/application-services/solutions/

[2] Cloudflare, "Cloudflare security architecture," Cloudflare Reference Architecture, 2024. [Online]. Available: https://developers.cloudflare.com/reference-architecture/architectures/security/

[3] Cloudflare, "Security model · Cloudflare Workers," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/workers/reference/security-model/

[4] Cloudflare, "Reference architectures · Cloudflare," Cloudflare Reference Architecture. [Online]. Available: https://developers.cloudflare.com/reference-architecture/

[5] web.dev, "Quick reference to security headers," web.dev. [Online]. Available: https://web.dev/articles/security-headers

[6] Cloudflare, "Get started with SSL/TLS — Cloudflare Docs," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/ssl/get-started/

[7] Cloudflare, "Cloudflare Bot Management & Protection," Cloudflare Application Services, 2024. [Online]. Available: https://www.cloudflare.com/application-services/products/bot-management/

[8] Cloudflare, "How the cache works · Cloudflare Workers," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/workers/reference/how-the-cache-works/

[9] Cloudflare, "HTMLRewriter · Cloudflare Workers," Cloudflare Workers Runtime APIs, 2024. [Online]. Available: https://developers.cloudflare.com/workers/runtime-apis/html-rewriter/