The change meant for one market

What happened

Carousell runs an online marketplace website and app in Singapore and several other markets. In 2022 it notified PDPC of two unrelated incidents.

On 13 July 2022, Carousell changed its chat function. The change was meant only for users in the Philippines replying to property listings. Because of human error, it added the email addresses and names of guest users to messages sent to listing owners in all categories and all markets. On 18 August 2022, a fix for an unrelated problem extended the same effect to registered users. Carousell learned of it from a user report that day, and fixed both on 24 August. The email addresses of 44,477 individuals, and the mobile numbers of users in the Philippines, were disclosed without consent.

The second incident began earlier. On 15 January 2022, during a system migration, Carousell launched a public-facing API but left out a filter. The filter would have limited results to publicly available profile data. Without it, the API returned email addresses, telephone numbers and dates of birth. A threat actor scraped the accounts of 46 users with large numbers of followers, in May and June 2022. Carousell found and patched the flaw on 15 September 2022 but did not detect the exploitation. PDPC alerted it on 13 October 2022 that data of about 2.6 million users was being offered for sale.

What PDPC found

Carousell admitted the facts and the breach under PDPC's expedited procedure. PDPC found that it had negligently breached the Protection Obligation in two ways.

Pre-launch testing was not scoped adequately. For the chat change, no testing checked how it affected users and listings outside the intended category, although the same chat function served all of them. For the migration, code reviews and tests were done selectively, for certain purposes and certain APIs. PDPC said the API's function was to retrieve personal data, so Carousell should have identified it and tested it for data security risks.

Functional and technical specifications were not adequately documented. The engineer who made the chat change was not the original author. The handover document covered the technical side but not how the function was used for different purposes or how a change would affect specific groups of users. The APIs in the migration were built in 2016 without proper documentation, so the people involved may not have known the filter needed to be applied.

PDPC also recognised that Carousell's rate limiting and traffic monitoring were adequate in general, and that the threat actor was sophisticated in avoiding them. It took into account Carousell's cooperation, its prompt remediation and the absence of earlier contraventions. It imposed a financial penalty of S$58,000 and directed Carousell, within 90 days, to review its software testing procedures and its documentation processes, rectify any gaps, and report back.

Where it goes wrong in practice

In a small team, the person who built a feature moves on, and the next person gets a ticket that sounds minor: show this field for this market. They test that the change works. Nobody tests what else shares the component, because nobody wrote down what else uses it.

A migration has the same gap. Old services come across with their behaviour, but not always with the reasons behind a filter or a restriction. The reasons were in someone's head.

Lessons learned

• Test what a change could affect, not only what it was meant to do.
• Treat anything that returns personal data as a named risk in your change process.
• A fix is a change too. In this case the August fix widened the July problem.
• Notes on what a component is used for, and by whom, matter as much as notes on how it works.

How to avoid it

• Keep a list of the systems, features and APIs that handle personal data, with a named owner for each.
• Before release, ask who else uses the component being changed, and what the change does for them.
• Add a data check to testing: does any field show up somewhere it shouldn't?
• Ask a second person to review changes that touch personal data. Carousell introduced extra approval from its test engineers for new features involving personal data after these incidents.
• Before a migration, list what each old service filtered or restricted, and confirm each one carried across.

If you're unsure which of your systems handle personal data and who owns each one, talk to us. It is the kind of structure we help organisations keep in place, so the answer doesn't live in one person's head.