# Do not let an unkeyed request input alter Cloudflare-cacheable output

> A response can be reused for clean requests when the input that changed it is absent from the key.

- Canonical URL: https://update.dsesecurity.com/updates/do-not-let-an-unkeyed-request-input-alter-cloudflare-cacheable-output/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:16:38+00:00
- Modified: 2026-10-20T18:34:36+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

A response can be reused for clean requests when the input that changed it is absent from the key.

## Potentially affected

This is application and cache-design guidance, not a claim that Cloudflare automatically sanitizes all origin output or that a particular website has been compromised.

## DSE recommendation

DSE recommends reviewing every input that changes a public cacheable response, including forwarded headers and unusual request bodies.

## Article

A response can be reused for clean requests when the input that changed it is absent from the key.

## Source facts

Cloudflare describes cache poisoning as inducing a harmful response that shares a cache key with a clean request. Its guidance warns against reflecting untrusted header values into cached output when those values are not keyed. GET request bodies are not included in the cache key and should not change a cacheable response; bypassing cache or using POST may be appropriate when body-driven behavior is required.

Source: [Cloudflare — Avoid Web Cache Poisoning](https://developers.cloudflare.com/cache/cache-security/avoid-web-poisoning/).

## Applicability

This is application and cache-design guidance, not a claim that Cloudflare automatically sanitizes all origin output or that a particular website has been compromised.

## DSE recommendation

DSE recommends reviewing every input that changes a public cacheable response, including forwarded headers and unusual request bodies. Remove unnecessary reflection and keep user-specific output outside shared caching. If a meaningful response dimension must remain, use a supported key or bypass design and document why it is safe. Coordinate application and CDN changes rather than expecting one layer to compensate for undocumented behavior in the other. Have the application reviewer nominate inputs that should be irrelevant to public output, then use nonharmful markers to challenge that assumption in isolation. If an input changes content unexpectedly, return the finding to the application owner before approving any cache-key consolidation or wider public eligibility.

## Verification

In an isolated security test, compare clean requests with controlled alternate headers or GET bodies using nonharmful markers. Confirm the altered input cannot contaminate a later clean response. Record the application response and cache key together, and avoid executing poisoning experiments against shared production content without explicit test authorization.

## Official reference

[Cloudflare — Avoid Web Cache Poisoning](https://developers.cloudflare.com/cache/cache-security/avoid-web-poisoning/). Reviewed October 20, 2026.

## Primary reference

- Name: Cloudflare — Avoid Web Cache Poisoning
- Authority: developers.cloudflare.com
- URL: https://developers.cloudflare.com/cache/cache-security/avoid-web-poisoning/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not let an unkeyed request input alter Cloudflare-cacheable output,” DSE Security, https://update.dsesecurity.com/updates/do-not-let-an-unkeyed-request-input-alter-cloudflare-cacheable-output/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.