Rate-limit the APIs that return customer data. Italy fined Wind Tre 1.7 million euros partly for not doing so.

In February 2025, someone phoned staff at a Wind Tre shop in Italy, said they were from technical support, and got remote access to the shop's computer. The shop's login for Wind Tre's customer system was saved on that computer. Wind Tre's main customer search blocked mass lookups, but the APIs the system called after a search, to fetch one customer's details, had no limit on how many requests a login could make. Through those APIs the attackers sent about 2 million requests, stepping through customer IDs, and copied the records of 365,048 customers 1.

Most products are built the same way: a search box, and behind it a second API that fills the detail page one record at a time. Italy's data protection regulator, the Garante, fined Wind Tre 1,715,600 euros for the breach 2. Its decision says all sensitive APIs, here the ones returning customer records, needed a request limit and belonged in Wind Tre's security tests, and it counts the gap as a breach of GDPR's duty to keep personal data secure. That duty binds any company handling personal data, a small software company as much as a telecoms operator.

How did one shop's login reach 365,048 customers?

There were two attacks, at two shops, a few days apart 1. In both, the caller posed as technical support and asked for remote access. Wind Tre's login needed three authentication factors, including a digital certificate installed on the shop computer, and the decision says the attackers obtained all three through the same trick. Wind Tre told the regulator the other login details were probably saved in plain text on the desktop or in the browser. With everything on one computer, a remote session on it had all it needed.

The first attack reached about 23 customers with 66 lookups. Wind Tre says an early attempt was blocked by its security, after which the attackers studied the application and found the APIs it called after its main search. Those had none of the main search's protections. In the second attack the attackers sent about 2 million requests to them and copied names and contact details for 365,048 people. For 41,359 of them the data also included payment details: IBANs, postal payment slips, and partially masked card numbers with expiry dates 1.

Nobody expected the secondary APIs to be called in bulk, so they had not been examined for that risk in advance, and only the main APIs were protected. That is Wind Tre's own explanation, given at a hearing in December 2025 (my translation) 1.

Why did the Garante fine Wind Tre when a shop worker was the one tricked?

Wind Tre argued that its security matched the state of the art, and that the attacks succeeded only because of human error that could not have been avoided. The Garante disagreed. Its decision says security measures have to keep data safe "even in the presence of social engineering attempts" (my translation), and that choosing those measures is the company's job 1. It found that the certificates should have been kept in protected storage that stops them being copied off the computer, and the passwords in a password manager.

Wind Tre also said it could not impose a password manager on shops it does not own or on people it does not employ. The Garante rejected that too: a company can and should give security instructions to the partners who handle its data, and they have to follow them.

What did the Garante say sensitive APIs need?

Rate limiting, combined with a CAPTCHA, so the system checks both how many requests arrive and whether a person or a script is sending them 1. Wind Tre says it already had a CAPTCHA against mass lookups and reviewed each shop's lookups once a week, but the secondary APIs were not protected, and a weekly review can only see a mass download after it has happened.

In my reading the two measures belong in different places. A CAPTCHA works on a screen a person uses, such as the search box. An API called by your own front end or by a customer's integration cannot show one, so on those endpoints the per-login limit has to do the work.

The Garante calls the OWASP API Security Top 10 the main reference framework for the industry. The entry that matches the missing limit, in my reading, is API4, unrestricted resource consumption, whose advice includes a limit on how often one client can call the API in a set time. A login that can reach records it has no reason to see is a separate entry, broken object level authorization.

The Garante also found fault with the testing. Wind Tre said it ran regular vulnerability scans and penetration tests. The decision says those tests either left out the exposed APIs or did not look at them closely enough, and that tests aimed at the APIs would reasonably have found the weakness 1. GDPR itself lists "a process for regularly testing, assessing and evaluating the effectiveness" of security measures among the things Article 32, GDPR's security article, can require 3.

If people look up customer records through your API, what should you check?

This is for anyone running a product where staff, partners, resellers or customers' own admins can look up personal data through an API, including the API behind your own front end. If one login can read your whole customer base, one tricked person is enough for a breach you have to report, and the regulator will judge the limits you had in place, as the Garante did with Wind Tre.

If you sell software to businesses and it is your customer's admin who gets tricked, the limits are still partly your duty. Under GDPR you are usually your customer's processor, and Article 32 binds the processor as well as the customer 3. Sweden's regulator fined the HR software vendor Miljödata under that article, as I wrote in the post on that fine.

Of Wind Tre's two failures, I would fix the API limits first. Safe password storage depends on every partner following your instructions every day, while a limit in your own code still holds on the day someone is tricked.

1. List every endpoint that returns personal data. Include the ones your front end calls after a search, on a detail page, or for an export. Anyone holding a valid session can call them directly, without your front end.
2. Put a per-login limit on each one. Find the most records any legitimate user opens in a day, such as your busiest support agent, and set the limit above that. As a worked example: at 1,000 records per login per day, the 2 million requests in Wind Tre's second attack would have taken more than five years. Alert when one login walks through IDs in order.
3. Make lookups hard to walk through. Check that each login can reach only the records it has a reason to see, and prefer random IDs to sequential numbers. Random IDs slow down an attacker who guesses, but they do not replace the limit.
4. Name the APIs in your penetration test scope. Ask the tester to call each endpoint directly with a valid low-level login.
5. Keep logins off shared computers. No passwords saved in browsers on shared or partner computers, a password manager for staff and partners, and a one-time code from a separate device. The Garante said one-time codes would "certainly" have limited Wind Tre's attackers 1. If partners you do not employ handle your data, put these rules in your instructions to them.
6. If it happens, report it yourself. In Wind Tre's favour, the Garante counted that the company reported both breaches itself, told the affected customers, fixed things quickly and cooperated. The fine was 1% of the maximum it could have imposed. The decision is dated 14 May 2026 and was announced in Italian in July 4.