We recently had a customer report that they were presented with another customer's personally identifiable information (via /customer/account) when they tried to log onto our M2 site.
We're Commerce Cloud customers, and our account uses Fastly for edge caching. Both the affected customer and the customer whose data leaked live in the Pacific Northwest and were almost certainly hitting the same Fastly POP.
The "Use SID on Frontend" setting is enabled for our account. My suspicion is that the customer somehow managed to follow an improperly cached link that had an embedded session ID for the other customer's session. I haven't been able to confirm that as readily as I'd hoped, but neither am I sure when her session started; I just know approximately when she discovered the problem.
For at least 20 years, we've been told again and again to -never- embed a static session token in a URL. I understand someone out there may really -need- customers to be able to port sessions between sites, but there are much better ways to accomplish that in this day and age. Why is Magento still doing it in such a ham-handed, dangerous manner? What am I missing, here?
At the very least, I think sessions init'd this way should be untrusted, and any (standard) view that embeds PII should be blocked until the user re-authenticates. A Magento tech suggested we enable the optional session validations (IP, forwarded-for, etc.), but each of those options has a penalty, and *none* of them should be necessary in my opinion.
