📄 Cache Poisoning via S3 API: when JavaScript caching becomes an attack vector A common setup: a site stores static assets in S3, proxies requests to it, and caches "200 OK" responses. At first glance, everything looks correct — but one cache configuration detail turns this into a vulnerability. Query parameters are not included in the cache key. As a result, "/app.js" and "/app.js?anything" are treated as the same resource by the cache. However, S3 is not just a file store — it exposes a REST API with object-level operations that also return "200 OK" responses: 🟡 "?tagging" — returns XML with object tags instead of file content 🟡 "?acl" — returns XML with access permissions An attacker requests │ /app.js?tagging The proxy forwards the request to S3 → S3 responds with XML and a "200 OK" → the proxy caches this response as the content for "/app.js" → all users subsequently receive XML instead of JavaScript. The application breaks for the duration of the cache lifetime. Even if "?tagging" and "?acl" are disabled, another vector remains. The S3 "GetObject" API supports the parameter: │ ?response-content-type=text/html S3 returns the correct file but overrides the "Content-Type" header. The cache stores the response with "Content-Type: text/html". The browser receives the script as HTML and does not execute it. The result is the same — application functionality is disrupted. 📎 t.me/Black4Fan/20 #dbugs_attacks