[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-...