APIs: Your Systems Talk to Each Other All Day. Who's Listening In?
Your website, your mobile app and your business software exchange data day and night, with no human involved. Those conversations happen through APIs — and attackers have figured out that nobody is listening. Here's why these invisible channels became their favourite way in, and how to check yours before they do.
In September 2022, one of Australia's largest telecom providers watched the data of nearly 10 million customers — a third of the country's population — get siphoned off in a matter of days. Names, birth dates, home addresses, passport and driver's licence numbers.
The culprit? Not an elite hacking crew. A programming interface — an API — left reachable on the internet with no authentication whatsoever. Worse: customer records were numbered sequentially. 5567, 5568, 5569. The attacker wrote a simple script that added 1 to the number, over and over. Every request returned the complete file of a different customer.
No break-in. No malware. Just an automated service counter politely answering every request, without ever checking who was asking.
What exactly is an API?
Think of an invisible clerk. When your website displays your inventory, when your mobile app shows a customer their balance, when your CRM pushes an invoice into your accounting software — an API is doing the work. It's a digital service counter that receives requests and returns answers, around the clock, with no human involved.
Your business probably relies on dozens of them without knowing it. The ones behind your cloud tools. The ones powering your e-commerce site. The ones connecting your software together. Most were set up by your vendors or your web developer, and nobody in-house has ever laid eyes on them. That's precisely the problem: you can't watch what you can't see.
Why attackers love them
Attackers have massively shifted their attention to APIs in recent years, and the incidents keep piling up: 37 million accounts at T-Mobile in January 2023, 15 million Trello users in 2024 — same road in every time. Three things explain the appeal.
First, APIs are invisible. No login screen, no web page to look at. They fly under the radar of IT teams and of traditional security tools, which were built to watch what humans do.
Second, they're built for speed. An API answers fast, in bulk, and asks no questions. For an attacker trying to extract an entire database, that's a conveyor belt. At Dell in 2024, someone hammered a partner-portal API at roughly 5,000 requests per minute, for nearly three weeks, and walked away with 49 million customer records. No alarm ever went off.
Third, nobody keeps an inventory. An API version that got replaced but never unplugged, a test endpoint forgotten after a project wraps up: these "zombie" APIs stay online for years with no monitoring and no updates. In the Australian case above, the offending API was in fact believed to be dormant.
OWASP, the global reference in application security, maintains a top-10 list of API-specific risks. Number one, unchanged since 2019: the service counter that verifies you're a customer... but never checks that the file you're asking for is yours. Change one number in the request and you get your neighbour's invoice. That's exactly the flaw exploited in Australia — and it accounts for roughly 40% of all API attacks on its own.
Where Law 25 comes in
In Quebec, an API leaking personal information is a confidentiality incident under Law 25 — every bit as much as a stolen laptop or an email sent to the wrong person. The obligations apply in full: recording the incident in your register, assessing the risk of serious injury and, where that risk exists, notifying the Commission d'accès à l'information and the individuals affected.
The fact that the leak went through a "technical" channel nobody knew about doesn't reduce your responsibility. Quite the opposite: the law requires reasonable security measures proportional to the sensitivity of the data. An API sitting on the internet with no authentication is a hard thing to defend as reasonable.
API penetration testing: make your counters talk before attackers do
An automated vulnerability scan catches the obvious configuration problems — expired certificates, outdated versions. But the number one flaw, asking for someone else's file, slips past it almost every time. Why? Because the request is technically flawless. The server replies "all good." Nothing looks wrong... except the data that came back should never have left.
That's where an API penetration test comes in. A specialist takes the attacker's seat: they inventory what's actually exposed (including the forgotten versions), create two accounts and try to reach one's data from the other, tamper with parameters, push the rate limits, and look for what the API reveals that it shouldn't. In short, they test the logic, not just the plumbing.
When should you run one? Before launching a client portal or a mobile app. After a major overhaul of your e-commerce site or the addition of significant integrations. And on a recurring basis if your APIs touch sensitive data — financial, medical, personal.
Where to start
Three questions to put to your IT team or your vendors this week:
- Which APIs does our business expose to the internet — counting old versions and test environments?
- Who tested them, when, and against what scenarios? "The developer checked that it works" is not a security answer.
- If one of them leaked tonight, would we know? Logging, rate limits, alerts on abnormal volumes: at Dell, three weeks at 5,000 requests per minute went completely unnoticed.
If the answers are fuzzy, you're not alone — that's the reality for most SMBs. But fuzzy is exactly what attackers count on.
You don't need to be a multinational to be a target. A client portal, an app, an online store: the moment your systems talk to the internet, the conversation deserves a chaperone. MMO Techno helps Quebec SMBs inventory what's exposed, assess the risks and coordinate penetration tests scaled to their reality. Talk to an expert.