How Can Knowing an API URL Expose Personal Information?
Contents
Recent reports have drawn attention to attacks that begin with examining Android apps to find their backend APIs. AI can make this kind of exploration faster. But something about the discussion bothers me: if discovering an API address is enough to expose personal information, isn't the bigger question why the service allows it?
Imagine an office building with expensive locks and badge readers at its main entrance, but an unlocked staff door around the back. The staff door used to be hard to find. AI can help someone search more persistently, trying one possible entrance after another. Once they find it, they simply walk in. Why was that door left unlocked?
Apps can reveal their APIs
NICT discussed App-to-Backend (A2B) attacks on October 13, 2026, and JPCERT/CC discussed identifying APIs by examining Android application packages on October 15. Android apps are distributed to users, and details of how they communicate with servers can be studied. Knowing an endpoint, however, is not permission to use it.
An API can be called directly, even when the app only displays the corresponding feature after login. A login screen alone does not secure the backend. The server must authenticate the caller. If it returns personal information to an unauthenticated request, that is the unlocked staff door.
A badge should not open someone else's room
Even a properly functioning login is not enough. Suppose a customer views an order through an API. If changing the order ID reveals another customer's order, the server checked that the caller was logged in but failed to check whether they were allowed to see that order.
OWASP lists Broken Object Level Authorization (BOLA) as the first risk in its API Security Top 10 2023. The problem of changing an ID to obtain another person's data is also known as Insecure Direct Object Reference (IDOR). It's like having a valid building badge that also opens other people's rooms. Making IDs harder to guess does not replace authorization checks.
These flaws predate AI. Perhaps the checks were overlooked in the design or omitted in implementation. Finding the API did not create the underlying problem.
Where to look for the fix
IPA's October 9 advisory called for reviewing exposed applications, API integrations, and privileges. JPCERT/CC also addressed API access controls.
What happens when a caller is not logged in? When an ordinary user requests another customer's record? When they call an administrator-only function? All of these checks must be implemented and verified across every API, without omission. A feature hidden from the interface may still have a callable API. Successful tests of normal user actions cannot establish that unauthorized requests are blocked.
AI may make obscure entrances easier to find. That does not excuse leaving them unlocked. Before focusing on how sophisticated the attack was, we should examine the application's security design and implementation.
Expensive security at the front entrance means little if the back door is left open.
References
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to remediation — all powered by the CTEM framework.
Get Started