# Bunny.net CDN caching flaw exposed authenticated users' private HTTP responses

DevFeed: [Bunny.net CDN caching flaw exposed authenticated users' private HTTP responses](<https://devfeed.tech/articles/leaking-secrets-through-caching-with-bunny-cdn-19044.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/bunny-cdn-caching-vulnerability/>)

Author: HTTP Toolkit; Tim Perry

Published: 2023-06-20T11:30:00Z

Content type: article

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [Caching](<https://devfeed.tech/topics/caching.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Cross-origin resource sharing (CORS)](<https://devfeed.tech/topics/cors.md>), [Authentication](<https://devfeed.tech/topics/authentication.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>)

Tags: [authentication](<https://devfeed.tech/tags/authentication.md>), [caching](<https://devfeed.tech/tags/caching.md>), [cdn](<https://devfeed.tech/tags/cdn.md>), [http](<https://devfeed.tech/tags/http.md>), [performance](<https://devfeed.tech/tags/performance.md>), [protection](<https://devfeed.tech/tags/protection.md>), [responses](<https://devfeed.tech/tags/responses.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

The article examines a Bunny.net CDN caching flaw that caused private HTTP responses intended for one authenticated user to be served to other users. It explains how CDN caching can diverge from HTTP standards and expose private data or authentication credentials, and notes that the issue has been fixed.

## Source excerpt

Caching is hard. Unfortunately though, caching is quite important. Hosted caching & CDNs offer incredible powers that can provide amazing performance boosts, cost savings & downtime protection, essential for most modern sites with any serious volume of users. Unfortunately, while there are strict standards for how caching is supposed to work with HTTP on the web, many cache providers do not quite follow these, instead giving their customers free reign over all kinds of invalid caching behaviour, and providing their own default configurations that often don't closely follow these standards to start with either. There are many good reasons for this, but the main one is that CDNs are now doing dual service: providing performance improvements, and actively protecting upstream sites from DoS attacks and traffic spikes (similar problems - the key difference between a DoS attack and hitting #1 on Hacker News etc is intent, not impact). This conflicts with many of the standards, which prioritize correctness and predictability over this use case and, for example, expect clients to be able to unilaterally request that the cache be ignored. Bunny.net provides one of these CDNs, and like most they aggressively cache content beyond the limits of the standards, both to help protect upstream servers and to support advanced user use cases. This has upsides, but in some edge cases can result in awkward bugs and break developer expectations. In some more dramatic cases though, it can expose private user data, break applications & even leak auth credentials, and that's where this story gets serious. A few months ago, I ran into exactly that issue while testing out deployment options with Bunny.net, where I discovered that private HTTP responses intended for one authenticated user could be served to other users instead. Spoiler: this is now fixed! That said, it's worth exploring where this went wrong, the many ways this can work right, and how CDNs solve issues like this in practice. C