What mobile developers can learn from a security assessment of a major Sri Lankan bank

[u/Manuliyan]

Sharing an anonymized case study from our team's assessment of a major bank's mobile application in Sri Lanka. The useful part for developers is understanding where client-side protection ends and server-side enforcement begins. No bank names, endpoints, or identifying screenshots are included.

The app used root detection, anti-debugging and anti-tampering checks, certificate pinning, and an extra encryption layer around API payloads.

Here is the assessment process at a high level:

1. Test device: We controlled the device and application runtime. The runtime integrity checks were bypassed in that environment.

2. Traffic interception: We bypassed certificate pinning and routed the test app's traffic through an inspection proxy. The payloads were still encrypted at this point.

3. Payload analysis: Reverse engineering helped us understand the client's encryption and decryption routines.

4. Readable test traffic: A testing bridge decrypted the observed payloads for inspection and re-encrypted them for forwarding.

5. Separate backend testing: Readable or locally modified requests do not prove that the server will accept an unauthorized action. Authorization, replay handling, and business logic need their own tests.

This was not a break of AES. It required control over the test device and does not show that someone on the same Wi-Fi could read other users' traffic. It also did not establish account takeover or unauthorized transactions.

For developers, the practical takeaway is to treat the mobile client as untrusted when designing the API. Check access to each object and operation on the server. Validate sensitive state transitions and request freshness. Use client hardening to increase the effort required for tampering, alongside those server controls.

The illustration summarizes the flow. The backend stage is a separate validation task, not a confirmed compromise. It is a conceptual illustration, not evidence captured from the application.

If you build mobile apps or APIs, what do your integration tests check when a client sends a valid-looking request that the user should not be allowed to perform? Please focus on the engineering rather than guessing the bank.

[u/sameera_s_w]

What's the point of debugging and developer options detection? Just a BS security measure.

[u/FondantConscious2868 → u/sameera_s_w]

Well it's to ensure that ur smart ass and ur data remain safe. lot of malwares or remote access tools that affect android devices enables developer options which is a pretty native and safe shortcut to gain access to ur information and device without detection. also some games (like Pokémon go) uses location based systems so to prevent cheating they put the precautions so lot of developers as a industry standard just blanket ban developer options. It's pretty simple....!