Pre-Launch Security Architecture Review for a Mobile Banking App

A mobile banking app is unusual among software products because a meaningful fraction of its users run it on a device the developer does not control, does not trust, and cannot see. Some of those devices are rooted or jailbroken. Some are in the hands of the account owner; some are in the hands of someone who stole the phone; and some are driven by malware sitting between the app and the OS. A pre-launch review has to design for all of those at once, and do it before there is production traffic to learn from — the work is fundamentally about reasoning through threats rather than reacting to incidents.

The governing principle, and the one that most cleanly separates a real review from a checklist exercise, is that the client is untrusted. Everything running on the phone — the app binary, the TLS session, local storage, the biometric prompt — is exposed to an adversary who owns the hardware and can inspect, modify and replay it. This does not make client-side security pointless; it makes its role precise. Client controls raise the cost and slow the attacker down, but they are not where the guarantee lives. The guarantee lives on the server, which must behave correctly even when the client has been completely subverted.

The constraint that shapes the engagement is timing. Doing this before launch is far cheaper than after, because the findings that matter most are architectural — how authentication is structured, where trust boundaries sit, how keys are managed — and those are expensive to change once real customer money and a live user base depend on them. The reference we anchor to is the OWASP Mobile Application Security Verification Standard (MASVS) and its testing guide (MASTG), which give a shared vocabulary for what 'hardened enough for this risk level' means, so that 'the app is secure' becomes a set of verifiable claims rather than a feeling.

The review opens with structured threat modeling rather than a scan, because a scanner finds known-bad patterns while a threat model finds the design decisions that will hurt you. We decompose the system into its trust boundaries — the phone, the network, the API edge, the backend services, the third-party integrations for payments, KYC and push — and walk each with a framework like STRIDE, asking at every crossing what an attacker could spoof, tamper with, repudiate, disclose, deny or elevate.

The boundary that gets the most attention is the one between app and backend, because that is where an attacker with a rooted phone and an intercepting proxy will spend their time. We enumerate the abuse cases specific to banking: can a user manipulate a funds-transfer request to move money from an account they do not own; can an attacker enumerate account identifiers or reset flows to harvest customers; can a stolen but locked phone be coaxed into revealing a session; can the biometric or PIN check be bypassed to reach an already-authenticated session; can a repackaged clone phish credentials while looking pixel-identical to the real app. Each becomes a concrete thing the design must answer for.

The output of this stage is not a vulnerability list — there is no running system to scan yet — but a prioritized map of where the design places trust and where it could be violated. That map is what makes the later hardening and the penetration test efficient: testers are handed the architecture and the specific claims the design makes, so their time goes to breaking what matters rather than rediscovering the shape of the system. A threat model is only as good as the boundaries it is allowed to see, so a review that stops at the app and never looks at the backend authorization logic is inspecting the least important half of the system.

With the client understood as untrusted, its hardening is framed honestly: these are cost-and-friction controls that slow an attacker and shrink the population who can attack cheaply, not guarantees. The MASVS supplies the checklist. Data at rest is the first. Sensitive material — session tokens, cached account data, any cryptographic keys the app legitimately holds — is stored using the platform's hardware-backed facilities: the Android Keystore and iOS Keychain, ideally bound to the Secure Enclave or a StrongBox-backed key so keys are generated and used inside hardware that resists extraction even from a rooted device. Nothing sensitive lands in shared preferences, plist files, logs or screenshots. The honest caveat: on a fully compromised, unlocked device a determined attacker can still reach a lot; the hardware-backed store raises that bar meaningfully but not infinitely, which is exactly why the server cannot rely on the client having kept its secrets.

Data in transit is the second. All traffic is TLS, and the app pins the server's certificate or public key so that an attacker who has installed their own trusted CA on the device — trivial on a device they control — still cannot transparently intercept traffic without also defeating the pin. We implement pinning with a rotation and backup-pin strategy, because a pin that cannot be rotated safely becomes an availability incident waiting to happen.

The third group is integrity: root and jailbreak detection, checks that the app has not been repackaged or run under a debugger, and binary obfuscation. We are explicit that every one of these can be bypassed by a skilled attacker — they are deterrence and telemetry, not enforcement. None of these client controls is trusted to hold on its own; they make attacks costly and noisy while the actual decisions are made server-side.

Because the client is untrusted, the server must enforce every rule as if the app did not exist. Authentication is built on standard, well-analyzed protocols — OAuth 2.0 and OpenID Connect with the authorization-code-plus-PKCE flow appropriate for a public mobile client — rather than a bespoke scheme, because rolling your own auth is how subtle, catastrophic flaws get shipped. Access tokens are short-lived, refresh tokens are rotated and revocable, and tokens are bound where possible to a device or session so a stolen token is not a portable, replayable key to the account.

Authorization is checked on the server for every single request, against the identity in the validated token, never against an account identifier supplied by the client. The most common and most damaging mobile-banking API flaw is broken object-level authorization — the server trusting an object ID in the request and returning data for it without confirming the caller owns it — so the review specifically hunts for endpoints where changing an identifier would leak or move someone else's money. High-value actions like transfers get server-side transaction limits, velocity checks and step-up authentication, so even a fully authenticated but compromised session hits friction before it can drain an account. The API edge adds rate limiting and anti-automation on the enumeration-prone flows — login, registration, password reset, account lookup — because those are what an attacker scripts first.

Secrets and keys are the last pillar. There are no API keys, signing secrets or backend credentials baked into the app binary, because anything shipped in the client is readable by anyone who unpacks it — a rule we verify by actually decompiling the build and looking. Server-side secrets live in a managed secrets store or KMS/HSM, are rotated, and are scoped so one leaked credential does not unlock everything. Any control that only works because 'the app wouldn't send that' is a finding, not a feature.

A pre-launch review should leave the app in a state where a penetration test is efficient and meaningful rather than a scramble, and that readiness is itself a deliverable. Concretely, the threat model is documented and handed to the testers, the design's security claims are written as things to falsify, and the environment is set up so testers can work — a test build permitting the instrumentation they need, seeded accounts, and a scoped backend they may hammer without legal ambiguity. We front-run the test with deterministic work — static analysis, dependency scanning, secret-scanning of the built artifact, and a pass against the MASTG test cases — so human tester time goes to the hard problems: chaining logic flaws, abusing business rules, and probing the authorization model for object-level gaps only a human will find. Crucially, the pen test is scoped to include the backend and the APIs, not just the app on the device — the layer we already assume is compromised.

Security friction and user experience are in genuine tension, and pretending otherwise leads to controls quietly removed under launch pressure. Step-up authentication, short session lifetimes and strict device binding all protect accounts and all annoy legitimate users, so the design tunes them to risk: low-friction for reading a balance, higher friction for moving money to a new payee. We would not oversell client-side hardening — root detection and obfuscation are worth doing, but they are bypassable, and any architecture whose safety depends on them holding is broken. We would not accept a design where the server trusts the client to have enforced a rule, and we would not let a launch deadline convert a high-severity authorization finding into a post-launch backlog item; the whole economic argument for a pre-launch review is that architectural fixes are cheap now and expensive once real money and real customers depend on the flawed design. The consistent posture is to be precise about which controls carry a guarantee and which merely raise cost — and to keep the guarantees on the server, where the attacker cannot reach in and switch them off.