[new_here]

The blog post doesn't say much more than the headline. I'm curious about the specifics of what could of actually happened here.

In my limited experience working with CDNs wouldn't you just cache the responses of unique URLs and have some sort of cookie check at the edge before serving it.

So my own app would request something like /api/account?id=123 with my own id in there.

How would you end up getting other people's data in your app if your app only calls that unique URL?

[samhw]

It's pretty easy to imagine an API having an endpoint like GET /api/account/mine, which is implicitly parameterised by the user ID associated with that session. Or even a 'list' rather than a 'lookup' endpoint, like GET /api/messages, which fetched all private messages associated with the authenticated user – or whatever the equivalent private information would be, in Klarna's 'domain'.

Edit: If the other commenter is correct, then it's less bad than I imagined. Or rather it would at least only be triggered, seemingly, if someone deliberately and maliciously requested something that didn't 'belong' to them.

[new_here]

I see, so the it's likely that a generic URL pattern (like your example) was accidentally included in their caching rules.

I guess I didn't think of that originally because I thought if you wanted to cache some kind of response data like this, why on earth would you use a generic URL? But perhaps they probably didn't intend to cache this endpoint.

[q3k]

> How would you end up getting other people's data in your app if your app only calls that unique URL?

From what I understand what happened with this outage, the CDN would still cache /api/account?id=123, and someone with account ID 234 could access it by altering the URL to retrieve the cached version, if account 123 has used the app recently.

That's because a CDN has (usually) no concept of authorization/authentication and can't make decisions that /api/account?id=123 shouldn't be served to someone other than the owner of account 123.

It would be less catastrophic (at least from a PR point of view) because people wouldn't get immediately served others' accounts, but you'd be vulnerable to attack.

[Ndymium]

In fact users did get other users' data just by using the app normally, so it likely didn't happen the way you describe it.

[q3k]

Right, what probably happened is that an `/accounts/me` endpoint got cached.

But what GP seems to be asking about is: “Would having your app always encode a user ID into the endpoint have helped?”.

[new_here]

Yeah, I've just realised they've probably accidentally included a generic URL in the cache rules that they actually didn't intend to cache.

I originally thought they were trying to cache account data responses and so wondered why they wouldn't just use unique query parameters in that case. Definitely risky business though.

Out of interest, it looks like Cloudflare offers some sort of token authentication to authenticate at the edge: https://blog.cloudflare.com/token-authentication-for-cached-...

[cuspycode]

What I'm wondering is: why would you ever want a CDN configuration to override no-cache instructions from the backend? I assume there's a use case for this, but I can't figure out what it is. Can anyone explain?