The editorial argues that push notifications represent a trust-asymmetric surface where users grant OS-level permission once and the channel is thereafter protected by little more than a long-lived API key. The ASOS incident demonstrates that when that key is compromised — whether at the vendor, in CI secrets, or on a developer laptop — attackers inherit a direct, OS-sanctioned pipe to millions of lock screens with no spoofing tells for users to detect.
The editorial emphasizes that this incident is categorically different from phishing because the abusive messages carried the authentic ASOS icon, sender name, and system-level notification treatment. There was no misspelled domain or suspicious URL for users to catch — the payload was indistinguishable from legitimate marketing, which magnifies both user harm and reputational fallout regardless of where the compromise originated.
By submitting the BBC story under the framing that notifications were 'apparently sent by hackers,' the submitter foregrounds external compromise as the operative explanation. This frames the incident as a security breach of ASOS's notification stack or a third-party vendor rather than an internal content moderation failure.
On October 5-6, ASOS app users across the UK woke up to push notifications that read nothing like a fashion retailer's marketing copy. The BBC reports that users received messages containing abusive and offensive content delivered through the official ASOS app — the same channel the retailer uses to announce sales and shipping updates. ASOS has acknowledged the issue and said it is investigating, but has not yet disclosed whether the breach originated inside its own stack, inside a third-party notification vendor, or via a compromised credential sitting in a developer's laptop or a CI secret.
What makes this incident different from a typical phishing wave is that the messages arrived through the trusted channel itself — not spoofed from the outside, but pushed from inside the house. Users saw the ASOS icon, the ASOS sender name, and the system-level notification treatment iOS and Android reserve for apps you've explicitly installed and granted permission to notify you. There was no suspicious domain to inspect, no misspelled sender, no odd punctuation in a URL. The payload simply appeared, carrying whoever's words were loaded into whichever send API got abused.
ASOS has around 26 million active customers globally and a mobile app that sits in the top tier of UK e-commerce installs. Even a short window of unauthorized sends reaches an audience most consumer brands would envy. The reputational cost of being the vehicle for that payload — regardless of fault — is the kind of thing that lands in a board deck by Monday.
Push notification infrastructure is one of the quieter trust-asymmetric surfaces in a modern consumer app. Users grant notification permission once, usually during onboarding, and from that moment the app has a direct, OS-sanctioned channel into their lock screen. The channel is high-trust on the receiving end. On the sending end, it is often protected by nothing more than a long-lived API key sitting in a vendor dashboard that a marketing contractor can log into.
The industry has spent a decade hardening email — SPF, DKIM, DMARC, BIMI — and almost no equivalent effort hardening the push surface, even though push is a strictly more trusted channel from the user's perspective. Firebase Cloud Messaging, OneSignal, Braze, Airship, Iterable, Customer.io — the big push vendors all expose send APIs guarded by server keys or OAuth tokens that, if leaked, let the holder address every device your app has ever registered. There is no equivalent of a DMARC report telling you an unauthorized sender is burning your domain. The first signal is usually a screenshot on social media.
The plausible failure modes for the ASOS incident are depressingly ordinary. A server key committed to a public repo and scraped by a credential harvester. A marketing contractor's SSO session hijacked via an infostealer. A support staffer at the notification vendor itself with over-broad admin rights. A segment-targeting feature abused to send to "all users" by a disgruntled insider. A compromised campaign-scheduling tool with a saved API token. Any one of these is enough. The industry has watched exactly this script play out with SendGrid, Mailchimp, and Twilio in the last three years — the push vendors are next, if they haven't been already.
The deeper problem is that most teams treat the push channel as a marketing tool and secure it accordingly, when the actual threat model is closer to an SMS gateway or a code-signing certificate. A push send is instant, cannot be recalled, is received with full system-level trust, and reaches an audience that cannot opt out short of uninstalling. That is not a marketing-automation threat profile. That is a critical-communications threat profile, and it deserves the controls that go with one.
If you ship a mobile app with push enabled, this is the week to do the audit you've been putting off. Start with the inventory question: who, inside and outside your company, currently holds credentials capable of sending a notification to your production app? Include vendor-side admin accounts, CI service accounts, support staff with impersonation rights, and any contractor who has ever logged into your campaign tool. Most teams discover the list is three to five times longer than they expected.
Then tighten the blast radius. Rotate push API keys on a schedule, scope them to specific campaign types where the vendor supports it, require SSO with hardware-key MFA on every console, and alert on any send to more than a defined threshold of users that didn't originate from your approval workflow. Firebase, Braze, and OneSignal all expose audit logs; most teams never read them. Wire the logs into your SIEM and set a rule for "broadcast send outside business hours by a non-service account." That one rule would have caught the ASOS incident in minutes rather than hours.
For the content side, treat every outbound push as if it will be screenshotted. Add a server-side content filter — even a crude profanity and PII regex — between your campaign tool and the vendor's send API. It is a twenty-line proxy that would have blocked whatever ASOS users saw this weekend. If your vendor doesn't support an approval queue for broadcast sends, build one yourself; the cost is a few days of engineering against the cost of a BBC headline with your logo on it.
The ASOS incident will produce the usual cycle: a statement, a vendor post-mortem if an external platform is implicated, and a short-lived industry conversation about push security that fades by the next news cycle. The structural issue — that mobile push remains a high-trust channel protected by marketing-tool-grade controls — will persist until a regulator or a lawsuit forces the question. Expect the ICO to take an interest given the UK consumer impact, and expect at least one of the big push vendors to quietly ship a "broadcast approval" feature in the next six months. In the meantime, the responsibility sits where it has always sat: with the team that owns the app. Audit the keys, log the sends, filter the payloads, and assume someone, somewhere, is already trying the credentials you forgot to rotate.
I received the push notification via the app this morning as well. Extremely bizarre and not how normally one finds out about a company getting hacked.
I am genuinely impressed at the lack of tech literacy in the live feed about this from the beeb.
> Asos did not immediately respond to the BBC's requests for comment.Amazing how companies think if they say nothing it'll somehow just go away. Couldn't even be bothered to reply to say they're looking into it.
The ransom note was addressed to their DPO, customers just got CC'd via push.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Braze API keys end up in a dozen CI configs and nobody rotates them. Campaign send is one POST.