App security: basic to advanced.

Why app security matters

A mobile app is an attractive target. The binary runs on a device you have no control over, communicates over networks you have no control over, and often contains credentials or tokens that give direct access to your backend. A successful exploit can at the same time become a data breach, reputational damage and a compliance incident.

The four layers of the attack surface

• Network — traffic between the app and the server can be intercepted (man-in-the-middle), especially on public Wi-Fi or via a rogue DNS resolver.
• Device — the device itself may be rooted, jailbroken or infected with malware that snoops on your app's memory or file system.
• Server — in practice, the backend API is where most data breaches originate. An insecure endpoint is far more dangerous than a missing certificate pin.
• Supply chain — third-party SDKs, build tools and CI/CD systems form a chain in which every link is an attack vector.

Recent incidents and legislation make the stakes even sharper. The EU has had the DSA and the AI Act in force since 2024, and the Cyber Resilience Act (CRA) will fully apply to apps with digital elements in 2027. This means security is no longer an option but a design requirement, including for relatively small apps in regulated sectors.

Level 1 — Baseline (required for every app)

These are the requirements no production app should go without. We see them missing again and again in MVPs that rushed to the store, and that is almost always a disaster waiting to happen.

HTTPS-only and transport security

All network traffic must use TLS. On iOS, App Transport Security (ATS) handles this by default; exceptions to plain HTTP must be declared explicitly in Info.plist and need a sound justification. On Android, the NetworkSecurityConfig implements the same idea: you declare per domain which traffic is permitted. No stray HTTP calls, no "just for debugging", no cleartextTraffic enabled in production.

Secure data storage

• iOS Keychain for secrets, tokens, refresh tokens and biometric keys. Not UserDefaults — that lives in a readable plist file.
• Android Keystore for keys and credentials. Not SharedPreferences — which is trivially readable on rooted devices.
• EncryptedSharedPreferences (AndroidX Security) if you must store something in preferences despite everything.
• No secrets in the binary — API keys and client secrets in the app bundle can be extracted in a matter of minutes.

Authentication

For login we default to OAuth 2.0 and OpenID Connect (OIDC). Passwords are stored server-side using a modern password hash (bcrypt, scrypt or Argon2 — not SHA-256 or MD5). Never store passwords in the app; for mobile clients, use refresh tokens via the PKCE flow.

Input validation

Never trust input from the client. All validation must also happen server-side: the app validates for UX, the server validates for security. This prevents injection attacks, forced state changes and logic that would otherwise exist only on the device.

Secure update flow and privacy permissions

An app must be able to update itself without requiring the user to reconfigure everything. A good in-app update prompt (Android In-App Updates or your own version check against your backend) ensures old, vulnerable versions disappear quickly. Additionally, only request permissions you actually use; overly broad permissions lead both to store rejections and to privacy risks.

Server-side first

A key insight from OWASP practice: most mobile data breaches come from poorly secured backends, not from the app itself. An unprotected endpoint that returns all user records is far more dangerous than a missing anti-debugging check. If you are commissioning compliance software, our ISO 27001 page is a good starting point to see how we approach that backend layer.

Level 2 — Intermediate

This layer belongs in most B2C apps of any size and in all apps with user accounts. These measures significantly raise the bar for attackers without bringing product development to a halt.

Token management

Access tokens have a short lifespan (think minutes), while refresh tokens last longer but must be implemented with rotation. A refresh token must be replaced every time it is used; reuse signals compromise and should invalidate the entire session. Server-side revocation must always be possible — users who lose their device need to be able to log out remotely.

Biometric authentication

Face ID, Touch ID and Android Biometric make re-authentication convenient without you having to store passwords. Importantly, the biometric check unlocks a Keystore item; the password itself never resides in the app. The fallback (PIN, pattern) should always go through the OS API.

Code obfuscation and anti-debugging

• R8 on Android — Google's standard shrinker and obfuscator. Enable it in proguard-rules.pro. Essential for commercial apps.
• Swift and Objective-C — Apple's compiler performs limited symbol stripping; for stronger protection, tools exist such as swiftshield.
• Anti-debugging — check whether a debugger is attached to the app and refuse sensitive operations when it is. Not infallible, but it increases the time an attacker must spend.

The UX layer of security

• Secure clipboard — password managers may place credentials on the clipboard, but your app should not do so itself. Clear sensitive clipboard contents after a few seconds.
• Screenshot protection — on Android via FLAG_SECURE at Activity level, and on iOS via a blur overlay when the app resigns. Particularly relevant for banking, healthcare and HR apps.
• MFA — offer a second factor via TOTP, WebAuthn or passkeys. An SMS OTP is better than nothing, but far from as secure as a hardware-bound factor.

Session management

Sessions should have server-side state. A logged-out user must also be invalidated server-side, not just client-side. Idle timeouts, absolute timeouts and device binding are standard components of a serious app.

Level 3 — Advanced

For banking, fintech, healthcare, defence and any app where a successful attack would cause direct financial or physical harm. This layer is not cheap, but for the right use case it is indispensable.

Certificate pinning

Standard TLS trusts all Certificate Authorities approved by the OS. With certificate pinning, your app trusts only the CA certificate (or public key) of your own backend. An attacker who has obtained a valid certificate issued by a CA can then still not carry out a man-in-the-middle attack. Be careful with key rotation, however: an expired pin breaks your app for everyone at once. Always use at least two pins (current and next-rotation) and a server-side emergency update channel.

Jailbreak and root detection

Detection of modified devices can be circumvented, but it does raise the bar. An attacker who wants to debug your app on their rooted device first has to work around the detection itself. For financial apps, refusing to launch on rooted devices is a sensible default; for B2B apps on enterprise devices it is often too heavy-handed a measure.

Anti-tamper and runtime integrity

• Frida detection — Frida is the most widely used runtime instrumentation tool for mobile apps. Detect its characteristic ports, libraries and stack traces.
• Checksum verification: on launch, the app compares the checksum of its own binary against an expected value. Tampering breaks the check.
• Anti-hooking: prevents method swizzling or Java hooks from intercepting sensitive methods.

Hardware-backed key storage

• Secure Enclave (iOS): a dedicated coprocessor that never lets keys leak out of it.
• StrongBox (Android): a Trusted Execution Environment or dedicated security chip on modern devices.
• TEE: a generic term for hardware isolation, of which ARM TrustZone is one implementation.

Device attestation

App Attest (iOS) and Play Integrity (Android) allow your backend to verify that a request comes from a genuine, unmodified app on a genuine device. For anti-fraud on payments, gambling, ticketing and account registration, this has become a de facto standard.

End-to-end encryption and zero trust

For messaging apps and sensitive communication, end-to-end encryption is the default, often based on the Signal Protocol with double-ratchet key rotation. Zero trust goes a step further: every request is re-authenticated, not just at login. No implicit trust, no tunnelling magic, no "we're already inside".

Penetration testing, SBOM and supply chain

Serious apps should undergo an annual external penetration test, or more often for major releases. A Software Bill of Materials (SBOM) has been mandatory for some sectors since 2024 and will become more widespread under the CRA. Supply-chain security runs through dependency scanning, signed releases (Sigstore, Cosign) and strict control of build pipelines. We explain what this means in practice for compliance software in healthcare or fintech on our NEN 7510 page and our GDPR compliance page.

Compliance context

Security is not only a technical challenge but also a legal one. The relevant frameworks your app needs to account for:

It is tempting to treat compliance as a tick-box exercise, but in practice it works the other way round: good security decisions make compliance paperwork easier. An audit of a well-secured app is a formal confirmation; an audit of a poorly secured app is an ordeal.

Tooling landscape

The ecosystem for mobile security tooling has matured considerably over the past five years. A rough overview of the categories that matter:

Static Application Security Testing (SAST)

• SonarQube: an open-core code quality and security scanner with good mobile rule sets.
• Snyk Code: SaaS, quick to integrate into CI/CD, with good iOS and Android coverage.
• Veracode: an enterprise choice with deep compliance reporting.

Software Composition Analysis (SCA)

• Snyk Open Source and Mend (formerly WhiteSource): dependency scanning with integrated fix suggestions.
• GitHub Dependabot: free for public and private repositories, automatically opens pull requests for patches.

Dynamic and mobile penetration testing

• OWASP ZAP and Burp Suite: for API proxying and server-side penetration testing.
• MobSF — Mobile Security Framework, an open-source tool that performs both static and dynamic analysis of iOS and Android apps.
• Frida and Objection — runtime instrumentation. Indispensable for red-team work, and just as much a target for anti-tamper measures.
• drozer — an Android-specific penetration testing framework.

Runtime protection and bug bounties

• Promon Shield, Verimatrix and Appdome — commercial runtime application self-protection (RASP) suites for apps in the financial and media sectors.
• HackerOne and Intigriti — bug bounty platforms. For a serious app, a natural next step after the first penetration test.

When is each level needed?

Not every app needs all three levels. A rough decision framework:

• Standard B2C app (lifestyle, content, community) — Level 1 is essential, and parts of Level 2 (token management, MFA, screenshot protection on sensitive views) are strongly recommended.
• Banking and fintech — all three levels, with certificate pinning, device attestation and RASP as hard requirements. Plus PSD2 SCA.
• Healthcare and medical — all three levels, with NEN 7510 or HIPAA as an overlay. For medical devices, MDR requirements also apply, with a dedicated quality management system.
• B2B mid-market — Levels 1 and 2 as a baseline, with selected Level 3 components based on what clients ask in their procurement questionnaires. ISO 27001 is often the driver here.

Common mistakes

• Hardcoded API keys in the binary — extraction takes a few minutes with standard reverse-engineering tools. Server-side proxying or dynamic token issuance is the right route.
• No certificate pinning in high-value apps — for banking, healthcare and e-commerce, a man-in-the-middle attack on public Wi-Fi is a realistic scenario. Implement pinning, and do so with a key rotation strategy.
• No logging of authentication failures — a brute-force attack on your login endpoint must be visible in monitoring. Otherwise you only discover it once the damage is done.
• Excessive permissions — an app that asks for location, contacts and SMS at installation without an apparent reason risks both store rejection and a loss of user trust.
• No update strategy — old versions of your app remain in circulation with vulnerabilities you may not even know exist. Forced-update mechanisms and version deprecation are not a luxury.
• No CVD policy — without a Coordinated Vulnerability Disclosure procedure, security researchers don't know how to reach you when they find an issue. A simple security.txt and a working mailbox are the minimum requirements.

For those looking to start a new app or have an existing app audited on these points, our app development service page explains in more detail how we build security into every phase of a project.

Frequently Asked Questions

What is the first layer of app security we should implement?

HTTPS-only traffic and secure storage of secrets in Keychain or Keystore. These are two measures that belong in every MVP, regardless of the type of app. Next comes the auth layer (OAuth 2.0 / OIDC) and server-side input validation. Getting these four things right covers the absolute basics.

What is the OWASP Mobile Top 10 and should we focus on it?

The OWASP Mobile Top 10 is a list of the most common mobile security risks, compiled by an international community of security professionals. For any serious app, it is the standard baseline checklist. We use the 2024 version and map the MASVS requirements onto it for in-depth verification.

What is certificate pinning and does my app really need it?

With certificate pinning, your app trusts only the certificate of your own server, not all CAs approved by the OS. This protects against man-in-the-middle attacks via compromised CAs. For banking, healthcare and payment apps it is effectively standard; for a simple content app the extra maintenance burden is often not worth it. The choice depends on the value of the data travelling over the connection.

Is jailbreak or root detection worthwhile if it can be bypassed anyway?

Yes, despite the fact that it can be bypassed. Raising the bar is a legitimate goal: a determined attacker will get through, but an opportunistic one will not. For financial apps, refusing to launch on rooted devices is sensible; for other apps, a warning or a reduced feature set is often enough.

How often should we carry out a penetration test?

At a minimum annually for a serious production app, and additionally with every major release or significant architectural change. A pen test is not a one-off event but a recurring check. Bug bounty programmes fill the intervening period with ongoing external eyes on your app.

What is the difference between GDPR and PCI DSS for our app?

GDPR (known in the Netherlands as AVG) concerns personal data of EU citizens and almost always applies. PCI DSS specifically concerns card transaction data and only applies if you yourself process or store card numbers. In practice, almost all apps use tokenisation via a payment provider to remain outside the PCI DSS scope; GDPR compliance, by contrast, is unavoidable.

What determines the cost of a security audit?

The scope (only the mobile binary, or also the backend?), the complexity of the architecture, the level of verification you are aiming for (MASVS L1, L2 or R), and the degree of access you give the auditor (black-box, grey-box or white-box). A grey-box audit of a mid-sized app typically takes several sprints, including a report and a follow-up round to resolve findings.