[Cache] ELI5 on cache security pages#30604
Open
Oxyjun wants to merge 1 commit intoproductionfrom
Open
Conversation
Contributor
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
Contributor
Oxyjun
commented
May 5, 2026
| A Web Cache Deception attack tricks a user into visiting a URL that looks like a static asset but actually serves dynamic, personalized content. | ||
|
|
||
| For example, an attacker could send a user a link to `http://www.example.com/newsfeed/foo.jpg` so that the user could be taken to their newsfeed. When the request passes through Cloudflare, the request would be cached because the path ends in `.jpg`. The attacker can then visit the same URL themselves, and their request will be served from Cloudflare's cache, exposing your user's sensitive content. | ||
| This works when an origin treats requests to non-existent paths as equivalent to a parent path. For example, if your origin serves the same dynamic response for both `/newsfeed` and `/newsfeed/foo.jpg`, an attacker could send a user a link to `http://www.example.com/newsfeed/foo.jpg`. Because the path ends in `.jpg`, Cloudflare caches the response by default. The attacker then visits the same URL and receives the cached copy of the user's personalized content. |
Contributor
Author
There was a problem hiding this comment.
Need to check if the rewording is better than the previous one. I think the best might be a mix of both.
Contributor
There was a problem hiding this comment.
Yes, this part seems relevant for setting the context:
http://www.example.com/newsfeedis the location of a dynamic script that returns different content for different users.
Oxyjun
commented
May 5, 2026
| * Passing `Access-Control-Allow-Origin` headers from the origin server to the browser. | ||
|
|
||
| The `Access-Control-Allow-Origin` header allows servers to specify rules for sharing their resources with external domains. When a server receives a request to access a resource, it responds with a value for the `Access-Control-Allow-Origin` header. `Access-Control-Allow-Origin` headers are often applied to [cacheable content](/cache/concepts/default-cache-behavior/). A web server may respond with different `Access-Control` headers depending on the `Origin` header sent in the request. | ||
| The `Access-Control-Allow-Origin` header lets a server specify which external origins are allowed to access its resources. A server may respond with different `Access-Control-Allow-Origin` values depending on the `Origin` header in the request. These headers are often present on [cacheable content](/cache/concepts/default-cache-behavior/). |
Contributor
Author
There was a problem hiding this comment.
The phrase "rules for sharing" has been dropped. The new wording frames it as binary (allowed or disallowed). Needs a nuance check.
Contributor
There was a problem hiding this comment.
I believe we still kept the correct meaning, even though we're not mentioning "sharing".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ELI5 pass on the 4 files in
/cache/cache-security/.index.mdxis a navigation page with no prose — skipped. Three concept files were improved.Key changes:
avoid-web-poisoning.mdx: Replaced vague "client-side vulnerabilities are often exploited through HTTP headers" with a concrete explanation of how cache poisoning via reflected headers works. Fixed misleading "Never return HTTP headers to users in cached content" (headers are always returned) → "Do not include untrusted header values in your response body."cache-deception-armor.mdx: Removed unnecessary preamble ("Before learning about...you should first understand..."). Consolidated three paragraphs explaining the attack into two focused paragraphs. Replaced vague "flexible about what kinds of paths it can handle" with concrete "treats requests to non-existent paths as equivalent to a parent path." Added "by default" qualifier to the caching-by-extension claim. Removed first-person "we think."cors.mdx: Fixed inaccurate CORS description — the original said "CORS instructs the browser to determine" when CORS is actually a server-side header mechanism enforced by browsers. Fixed "block requests" → "block access to responses" (browsers block response access, not the request itself). Removed unsourced claim about Cloudflare's cache varying by Origin header.All changes verified through adversarial fact-check review.
Documentation checklist