[Cache] ELI5 on cache security pages

Author: Oxyjun

src/content/docs/cache/cache-security/avoid-web-poisoning.mdx

@@ -31,10 +31,10 @@ Review the caching configuration for your origin web server and ensure you are c
 
 ## Do not trust data in HTTP headers
 
-Client-side vulnerabilities are often exploited through HTTP headers, including cross-site scripting (XSS). In general, you should not trust the data in HTTP headers and as such:
+Attackers can exploit HTTP headers to inject malicious content into cached responses. For example, if your application reflects an untrusted header value in the response body, an attacker could use this to perform cross-site scripting (XSS) through the cache. To reduce this risk:
 
 * Do not rely on values in HTTP headers if they are not part of your [cache key](/cache/how-to/cache-keys/).
-* Never return HTTP headers to users in cached content.
+* Do not include untrusted header values in your response body.
 
 ## Do not trust GET request bodies
 

src/content/docs/cache/cache-security/cache-deception-armor.mdx

@@ -10,15 +10,11 @@ tags:
 
 import { DashButton } from "~/components";
 
-Before learning about Cache Deception Armor, you should first understand how Web Cache Deception attacks work.
-
 ## Web Cache Deception attacks
 
-Web Cache Deceptions attacks occur when an attacker tricks a user into opening a link in the format of `http://www.example.com/newsfeed/foo.jpg`, when `http://www.example.com/newsfeed` is the location of a dynamic script that returns different content for different users.
-
-This scenario becomes problematic when your website is configured to be flexible about what kinds of paths it can handle. To be more specific, when requests to a path that do not exist, such as `/x/y/z` are treated as equivalent to requests to a parent path that does exist `/x`.
+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.
 
 ## Cache Deception Armor protects against attacks
 
@@ -29,7 +25,7 @@ In the newsfeed example above, if `http://www.example.com/newsfeed` is a script
 ### Exceptions
 
 * If the returned `Content-Type` is `application/octet-stream`, the extension does not matter because that is typically a signal to instruct the browser to save the asset instead of to display it.
-* Cloudflare allows `.jpg` to be served as `image/webp` or `.gif` as `video/webm` and other cases that we think are unlikely to be attacks.
+* Cloudflare allows `.jpg` to be served as `image/webp` or `.gif` as `video/webm` and other cases that are unlikely to be attacks.
 * Keep in mind that Cache Deception Armor depends upon [Origin Cache Control](/cache/concepts/cache-control/). A `Cache-Control` header from the origin, or an [Edge Cache TTL Cache Rule](/cache/how-to/cache-rules/settings/#edge-ttl) may override the protection.
 
 ## Enable Cache Deception Armor

src/content/docs/cache/cache-security/cors.mdx

@@ -8,14 +8,14 @@ tags:
   - CORS
 ---
 
-A cross-origin request is a request for website resources external to the origin. For example, `a.example.com` attempts to serve resources from `b.secondexample.com`. CORS instructs the browser to determine if a cross-origin request, such as an image or JavaScript from `b.secondexample.com`, is allowed by `a.example.com`. The browser does not load resources that are disallowed by CORS.
+A cross-origin request occurs when a webpage on one origin (for example, `a.example.com`) requests a resource from a different origin (for example, `b.secondexample.com`). Cross-Origin Resource Sharing (CORS) is a mechanism that uses HTTP headers to let the server at `b.secondexample.com` indicate whether `a.example.com` is allowed to access its resources. Browsers enforce these headers and block access to responses that are not permitted.
 
 Cloudflare supports CORS by:
 
 * Identifying cached assets based on the `Host` Header, `Origin` Header, URL path, and query. This allows different resources to use the same `Host` header but different `Origin` headers.
 * 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/).
 
 ## Add or change CORS headers at the origin server