African mobile apps: APIs must never trust their own APK

What the Japanese investigation actually found

On 21 October 2026, Japan’s computer emergency response coordination centre, JPCERT/CC, published findings from an investigation conducted with several organisations following unauthorised access and data leaks in Japan. On servers associated with the activity, analysts found APK files, Android and Flutter reverse-engineering tools including jadx and Blutter, and scripts designed to test application programming interfaces (APIs) for weaknesses such as server-side request forgery. Some analysed applications served users outside Japan.

JPCERT/CC says attackers used artificial intelligence to scan for known vulnerabilities and conduct attacks through APIs. The publication’s strongest contribution is its concrete technical evidence: application extraction, reconstruction of client logic, identification of server endpoints and automated testing. It does not publish a complete victim list or a measurement that attributes every action to AI. The operational change matters, but “AI-assisted” should not become a universal explanation.

The central point is simpler. A public mobile application runs on a device the publisher does not control. Its code can be extracted, observed, modified and executed outside the intended workflow. Obfuscation can slow analysis; it does not create a trust boundary.

An APK is not proof of authorisation

Some applications still assume a request is legitimate because it contains a header, signature or key embedded in the official client. A secret placed inside an APK may eventually be recovered. An attacker can then build a separate client, reproduce the request format and call the API directly without following the screens, limits or checks implemented in the app.

Request signing remains useful when it relies on a user- or device-specific key that is appropriately protected and revocable. It is fragile when every installed copy shares the same secret. The server must authenticate the real identity, verify its right to the requested object and enforce authorisation for every action. Changing a customer identifier in a URL must never expose another person’s record.

The joint advisory issued on 12 November by Singapore’s PDPC and Cyber Security Agency addresses exactly these risks. It describes accidental exposure of internal APIs, default credentials, compromised tokens, excessive permissions and Broken Object Level Authorization, or BOLA. It also stresses that a request made with valid credentials can still be malicious and that systematic extraction may resemble normal traffic.

Why this directly concerns Africa

Africa is mobile-first. Applications provide access to mobile money, banking, lending, insurance, commerce, healthcare, tax and identity services. In many projects, the Android interface is visible while the API concentrates both data and decision-making. One server-side flaw can therefore affect every application version and every user at once.

The GSMA’s 2026 Mobile Money report records 1.2 billion registered accounts and 341 million active 30-day accounts in Sub-Saharan Africa. At this scale, an authorisation error becomes systemic risk. The issue is not limited to major platforms: a rapidly delivered fintech, a contractor-built public portal or a health app linked to a legacy API may retain forgotten routes and shared secrets.

No reviewed source establishes that an African application was targeted in the Japanese activity. The connection rests on shared and verifiable architecture, not an invented victim. African teams can act before appearing in an incident report.

Test the server as if the app were hostile

A useful assessment starts by assuming that the attacker knows every route visible in the APK. Create two controlled accounts and verify that the first can never read, modify or delete the second account’s objects by changing identifiers, parameters, content types or call order. Tests must cover business functions: balance enquiries, phone-number changes, beneficiary creation, loan applications, document downloads and administrative actions.

Test and staging environments must be separated from production. An internet-facing UAT API containing copied data, shared credentials or a route into the real system can become a less monitored entry point. Old endpoints should be inventoried and disabled; removing them from the mobile interface is insufficient.

Logs should connect each request to the user, client, requested object, authorisation decision and returned volume without unnecessarily copying sensitive content. Detection should look for sequential enumeration, access to many accounts, unusual exports, repeated failures and calls from unexpected clients. Rate limiting reduces extraction but cannot repair broken authorisation.

For APIs that retrieve external URLs, server-side request forgery controls need more than a domain string check. Resolve and validate destinations, block private and management networks, re-check redirects and constrain outbound connectivity. JPCERT/CC’s recovered scripts are a reminder that attackers actively test redirect behaviour rather than accepting the intended restriction.

A design priority, not a late audit

Contracts with developers and integrators should require an API inventory, authorisation tests, secret management, usable logging and a revocation procedure. The customer organisation must be able to obtain evidence and repeat testing after a migration or third-party integration.

The lesson from Japan is not that Flutter or Android are inherently unsafe. It is that a mobile client cannot protect an API by itself. African services need a clear architecture rule: treat the application as observable to an adversary, keep durable secrets out of the client and make the server the final authority over every record and action.

— ◆ —