Agree, I once fell for a scam that I think I otherwise wouldn't because of string of circumstances: Being tired and stressed, it being Christmas time and I had actually ordered stuff but also because I had just upgraded iOS to the first version that put the address bar in Safari on the bottom of the screen instead of the top so I forgot to check the domain!
I've since changed the address bar back to the top…
In the end I didn't loose anything but it was a good wakeup call for sure.
I worked in a project over 10 years ago where something very similar happened!
We had built and authentication service that, among other things, was used by a SyncML service that was used back in the day of feature phones to syncs contacts etc. You can imagine that getting someone else's contacts on your phone isn't exactly ideal. This was how we came to know about the problem, from customers getting other customers data!
The error was caused by a CDN switch. Our instructions to the the CDN team responsible for the switch was "Make sure the CDN honors our cache headers, if our HTTP responses say something can be cached do so, if they say that the response should not be cached then don't". We were in at least three meetings where we repeated this mantra.
I believe that the CDN team thought that they had setup the CDN correctly but they had missed an edge case. The CDN was in fact setup to cache even uncacheable responses, and served those, _only_ when it could not reach our servers.
So if there was a traffic spike and the CDN determined that our authentication servers were unreachable it would fall back to serving data that should never have been cached in the first place! Happily returning tokens to random users that had authenticated just before the traffic spike...
I've since changed the address bar back to the top…
In the end I didn't loose anything but it was a good wakeup call for sure.