There are dozens of contradictions, like first they say:

“this may have resulted in potentially authenticated data being served to unauthenticated users”

and then just a few sentences later say

“potentially unauthenticated data is served to authenticated users”

which is the opposite. Which one is it?

Am I missing something, or is this article poorly reviewed?

I think that's already best practice in most API designs anyway?

I think this is their first major security incident. Good that they are transparent about it.

If possible (@justjake) it would be helpful to understand if there was a QA/test process before the release was pushed. I presume there was, so the question is why this was not caught. Was this just an untested part of the codebase?

"0.05% of domains" is a vanity metric -- what matters is how many requests were mis-served cross-user. "Cache-Control was respected where provided" is technically true but misleading when most apps don't set it because CDN was off. The status page is more honest here too: they confirmed content without cache-control was cached.

They call it a "trust boundary violation" in the last line but the rest of the post reads like a press release. No accounting of what data was actually exposed.

[1] https://status.railway.com/incident/X0Q39H56