We were doing fairly ordinary work: a preference center for an enterprise client, the kind of page where a customer manages whether they want to keep receiving email and SMS. It runs on Salesforce Marketing Cloud, it is shared across the client's whole subscriber base, and there was nothing in the brief about security testing. We were there to make the page work.
While reading through how the page identified who was visiting, a few lines stopped us. We checked what they did, and then we checked again because the implication was hard to believe. The page had a quiet door in it, and behind that door was the personal data of more than a million people.
What the page was supposed to do
A preference center has to know whose preferences it is showing. Done properly, the customer's identity travels inside the link as an encrypted, signed token. The page decrypts it and trusts it precisely because no outsider can forge it without the secret key. You can only open your own record, because only your link carries a valid token.
That part was built correctly. The problem was what sat next to it.
The door nobody meant to leave open
Alongside the secure path, the page had a fallback. If the encrypted token was missing, the code would fall back to reading an identifier straight off the end of the web address, in plain text, with no decryption and no check that the visitor had any right to that record.
That is the whole vulnerability. Anyone could take the link, swap the identifier on it for someone else's, and the page would load that person's profile. No login. No authentication. The industry name for this is an IDOR (Insecure Direct Object Reference): the system trusts a reference to a record without checking whether the person asking is allowed to see it.
It got worse the longer we looked. The customer identifiers were sequential numbers, the kind you can guess one after another. So this was not a flaw that exposed one record at a time to someone who already had a link. With a little patience, the same page would walk through most of the customer database in order: names, emails, phone numbers, consent status, record after record. And because the page also let you change consent settings, an attacker could not only read those records but flip people's email and SMS opt-ins, at scale.
This is the kind of incident that ends up in the news. Personal data at the scale of a million-plus records falls squarely under data-protection law in the markets the client operates in, the sort of exposure that triggers investigations, fines, and the slow erosion of customer trust that no apology fully repairs.
The part that was not our job
Here is the honest bit. Finding and fixing this was outside our scope of work. We were not engaged to audit the client's security. Nobody would have faulted us for finishing the task we were given and moving on, and nobody had asked us to go looking.
But once you have seen a door like that, you cannot unsee it. The choice is simple even if it costs you time you were not paid for: you report it, and you close it. We flagged it the day we found it, and with the client's sign-off the fix went live across all five business units within days. We removed the insecure fallback so the page accepts only the properly encrypted identity from a valid link, which means a person can once again open only their own record and no one else's. While we were in there we also hardened two smaller issues we noticed, including leftover debug code that rendered a subscriber's key, name, and email into the page's underlying source where it did not belong.
We have deliberately kept the technical detail here at the level of the idea, not the recipe. The point of writing this is not to publish a how-to.
Why we are telling this story
A flaw like this never shows up in a demo. The page looked perfect. It loaded, it saved, customers used it. The danger was sitting in the code, invisible to anyone who was not reading it carefully and asking the uncomfortable question: what happens if someone changes this value to one that is not theirs?
That habit, reading the thing in front of you properly and acting on what you find even when it is not strictly your job, is most of what separates a vendor who ships tickets from a partner who protects your business. We would rather be the second kind, and we would rather catch this quietly in a code review than help a client through it after it makes the headlines.
If you are running customer-facing pages on Marketing Cloud or anywhere else and you are not certain who can see what, that is exactly the kind of thing we are glad to look at. The contact page is the place to start, and our platform services cover the wider stack.
