Anatomy of a Breach

Anatomy of a Breach: Moonpig — The API That Let Anyone Access Any Customer's Account

> series: anatomy_of_a_breach —— part: 073 —— target: moonpig —— vulnerability: zero_api_authentication —— disclosure_ignored: 17_months<span class="cursor-blink">_</span>_

Hedgehog Security 31 January 2015 12 min read
data-breach moonpig api-security uk-breach no-authentication responsible-disclosure idor series
Breach #073

No authentication. No authorisation. Change the customer ID and you are someone else.

In January 2015, security researcher Paul Price publicly disclosed a vulnerability in Moonpig's mobile application API that was staggering in its simplicity: the API required no authentication. When the Moonpig app communicated with the company's servers to retrieve customer data, the API calls included a customer ID number but no authentication token, session cookie, or credentials. By changing the customer ID to any other number, anyone could retrieve the account details — name, address, date of birth, phone number, email, and the last four digits of payment cards — of any Moonpig customer.

Price had responsibly disclosed the vulnerability to Moonpig in August 2013 — 17 months before going public. Moonpig acknowledged the report but took no action to fix the vulnerability. After 17 months of waiting, Price published his findings. The disclosure generated intense media coverage, Moonpig's mobile API was taken offline within hours, and the ICO launched an investigation. The case was a textbook example of both the dangers of unauthenticated APIs and the consequences of ignoring responsible disclosure — paralleling Snapchat's dismissal of researcher warnings just one year earlier.

The Vulnerability
Recommended

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

An API with literally no security.

The Moonpig API was remarkable not for the sophistication of the vulnerability but for its absence of any security whatsoever. There was no authentication (the API did not verify who was making the request), no authorisation (the API did not check whether the requester was permitted to access the requested data), no rate limiting (the API could be queried at machine speed), and no input validation on the customer ID parameter. This was not a subtle flaw — it was a complete absence of access control on a customer-facing API.

Zero Authentication
The API required no credentials, no tokens, no session management. Anyone with the API endpoint URL could retrieve any customer's data. Our <a href="/penetration-testing/api">API penetration testing</a> tests authentication on every endpoint — because the Moonpig case proved that some organisations deploy APIs with no authentication at all.
IDOR — Insecure Direct Object Reference
The customer ID parameter was a sequential integer that directly referenced customer records. Changing it returned a different customer's data. This is the textbook definition of IDOR — the same vulnerability class that exposed <a href="/blog/anatomy-of-a-breach-att-ipad-email">114,000 AT&T iPad email addresses</a> in 2010 and <a href="/blog/anatomy-of-a-breach-snapchat">4.6 million Snapchat records</a> in 2014. Our <a href="/penetration-testing/api">API testing</a> checks every parameter for IDOR.
17 Months of Ignored Disclosure
Price waited 17 months between responsible disclosure and public disclosure. Moonpig acknowledged the report and did nothing. This pattern — acknowledge, ignore, get embarrassed — has appeared with <a href="/blog/anatomy-of-a-breach-snapchat">Snapchat</a> and Moonpig in consecutive years. As a <a href="/penetration-testing">CREST-accredited provider</a>, our testing identifies and remediates these vulnerabilities before public disclosure becomes necessary.
Payment Card Data Exposed
The API returned the last four digits of payment cards — enough for social engineering attacks and partial card identification. Combined with names, addresses, and dates of birth, this data enabled comprehensive identity fraud. <a href="/cyber-essentials">Cyber Essentials</a> mandates access controls on systems handling payment data.
UK Impact

A UK household name with zero API security.

Moonpig is one of the UK's best-known online brands — millions of British customers use it for birthday cards, Valentine's cards, and personalised gifts. The revelation that every customer's personal data was accessible through an unauthenticated API was a significant privacy event for UK consumers. The ICO investigated and Moonpig remediated the vulnerability — but the 17-month gap between disclosure and fix meant that any attacker who discovered the vulnerability independently could have harvested the entire customer database without detection.

For UK e-commerce businesses, the Moonpig case is a direct warning: your mobile app's API is an attack surface that must be tested with the same rigour as your website. Our API penetration testing and mobile application testing assess authentication, authorisation, rate limiting, and data exposure. Cyber Essentials establishes baseline access controls. SOC in a Box monitors for API abuse patterns. And UK Cyber Defence provides incident response when API vulnerabilities are discovered or exploited.

API Security

Moonpig's API had no authentication. At all. Have your APIs been tested?

Our <a href="/penetration-testing/api">API penetration testing</a> checks every endpoint for authentication, authorisation, IDOR, and rate limiting. Because if Moonpig — a UK household name — deployed an API with zero security, the question is what your API might be missing.

Commission an API Test Next: Anthem
Next Step

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call
Keep Reading

Related Articles

Anatomy of a Breach 31 January 2014

Anatomy of a Breach: Snapchat — 4.6 Million Usernames Scraped After Warnings Were Ignored

Breach #061. On 1 January 2014, hackers published the usernames and phone numbers of 4.6 million Snapchat users after exploiting an API vulnerability that security researchers had warned the company about months earlier. Snapchat had dismissed the warnings, calling the vulnerability 'theoretical.' The breach demonstrated that ignoring responsible disclosure carries real consequences — and that API security vulnerabilities identified by researchers will eventually be exploited by attackers.

data-breach snapchat
11 min read
Anatomy of a Breach 31 July 2010

Anatomy of a Breach: The AT&T iPad Leak — 114,000 Email Addresses and the Line Between Research and Crime

Breach #019. In June 2010, security researchers from Goatse Security discovered that AT&T's website exposed the email addresses of approximately 114,000 early iPad 3G adopters — including White House staff, military officials, and media executives — through an insecure API that could be enumerated using publicly visible ICC-ID numbers. The incident ignited a fierce debate about the boundary between security research and criminal hacking.

data-breach att
11 min read
Anatomy of a Breach 30 June 2020

Anatomy of a Breach: Blackbaud — The Charity Software Vendor That Exposed UK Universities, NHS Trusts, and Charities

Breach #138. In July 2020, Blackbaud — a cloud computing provider serving nonprofits, charities, and educational institutions — disclosed that ransomware attackers had accessed and exfiltrated customer data before the company detected and stopped the attack. Blackbaud controversially paid the ransom and stated it had received 'confirmation' the data had been destroyed. The breach affected hundreds of organisations worldwide — including UK institutions such as the National Trust, the University of Birmingham, De Montfort University, Young Minds charity, and multiple NHS trusts. Blackbaud later admitted that the breach was more extensive than initially disclosed.

data-breach blackbaud
13 min read
All Posts Get in Touch