Hard2bit
Mobile security

Mobile application security audit

Your app rides in the attacker's pocket.

We audit your iOS and Android apps the way someone would with the binary in hand: data storage, communications, embedded secrets, reverse engineering and the security of the backend that feeds them.

What a store never checks for you

Publishing on the App Store or Google Play validates policies, not the real security of the code or of the data the app handles.

The app is in the attacker's hands

Unlike a server, the binary is installed on a device the attacker controls. They can decompile it, inspect its storage and extract secrets at their leisure.

The backend is as attackable as the app

The application reveals its own endpoints. Once the traffic is intercepted, the attacker stops touching the interface and works straight against the API: IDOR, broken authorisation and exposed data.

No obfuscation, no secrets

API keys, tokens and business logic embedded without protection surface in minutes through reverse engineering. With no root/jailbreak detection or pinning, the control is purely cosmetic.

What we test

We cover the seven verification categories of OWASP MASVS and run the technical checks from the MASTG across iOS and Android. This is not an automated scan: it is a standard-led review, category by category, all the way through to the API the app consumes.

Data storage

Where and how the app keeps sensitive information: Keychain on iOS and Keystore on Android, files and preferences, SQLite databases, network and image caches, system logs and backups. We look for credentials, tokens and personal data that survive outside the secure store and end up within reach of another app or whoever holds the device.

Cryptography

Sound use of cryptography: current algorithms and modes, key generation and randomness, management and rotation of key material, and the absence of home-grown schemes or keys embedded in the binary. Misapplied encryption gives a false sense of security that is more dangerous than none at all.

Authentication and session management

Login flows, tokens (OAuth2/JWT), session expiry and revocation, biometrics and secure credential storage. We check that real authentication is enforced by the backend and that the app does not rely on controls that live only on the client and fall to a single hook.

Network communications

TLS on all traffic, certificate validation and the state of certificate pinning, plus resilience against a man-in-the-middle attack. We intercept the traffic in a controlled environment to see what actually travels over the wire and how well it is protected.

Platform interaction

Requested permissions versus those genuinely needed, inter-component communication (IPC, intents, URL schemes), deep links and how WebViews are handled: JavaScript enabled, exposed native bridges and loading of untrusted content. This is where one app leaks data to another on the same device.

Code quality and resilience

Protection against reverse engineering and tampering: obfuscation, anti-tampering, integrity checks and root/jailbreak detection. We assess how hard it is to decompile, modify and repackage the app, and whether those controls hold up against hooking tools such as Frida or are purely cosmetic.

Backend and API security

The app is only the client: the business logic and the data live on the backend. Once the traffic is intercepted, an attacker works straight against the API and probes object-level authorisation (IDOR/BOLA), input validation, rate limiting and data exposure. That is why we close the scope with our API security audit; and if you also run a web management panel, it dovetails with the web application audit.

How we audit your mobile application

Reconnaissance and static analysis

Unpacking the bundle (IPA/APK), inventorying permissions, exposed components and third-party libraries, and hunting for hardcoded secrets, endpoints and API keys embedded in the binary.

Dynamic runtime analysis

Instrumenting the app on a controlled device: inspecting local storage, databases, cache and logs, intercepting TLS traffic and validating certificate pinning and session handling.

Reverse engineering

Disassembling the binary to assess tamper resistance: obfuscation, root/jailbreak detection, code integrity and resilience to hooking and repackaging with tooling such as Frida.

Backend and API testing

Auditing the API the app consumes: authentication, object-level authorisation (IDOR/BOLA), input validation, rate limiting and data exposure, replicating what an attacker would do once they intercept the traffic.

Report and retesting

Risk-prioritised findings with evidence and proof of concept, concrete per-platform recommendations and a follow-up retest to confirm closure.

When you need it

A mobile application security audit is not an annual box-ticking exercise: there are specific moments when the risk climbs or when someone will ask you for one in writing.

Launch or major update

Before you ship to the stores or release a version that rewrites authentication, payments or local storage. Fixing it before the binary reaches thousands of users is far cheaper.

Payments or personal data

If the app processes payments or handles health data, credentials or any personal information, it is a target with a clear payoff for an attacker and a direct responsibility towards your users.

Enterprise client requirement

More and more B2B procurement processes demand an independent audit report before they approve your app. A deliverable aligned with OWASP MASVS unblocks that step, a common ask in the SaaS and technology sector.

Regulatory compliance

GDPR for personal data, PCI DSS where cards are involved, and DORA for financial entities and their supplier chain. A documented audit supplies the technical evidence these frameworks expect.

After a third-party integration

A new analytics SDK, a payment provider or an advertising library widens your attack surface and can introduce permissions, traffic and data leaks you do not control. It is worth a review once you have integrated.

As part of your red team

The mobile app is one more vector in a full offensive exercise. It fits within our pentesting and red team work when you want an end-to-end view of your exposure.

What the report includes

The deliverable is written for two readers: the person who decides and the person who fixes. Every finding arrives with a severity, reproducible evidence and a remediation your team can apply without guessing.

Executive summary

A jargon-free read of the overall risk level, the critical findings and their business impact, so leadership and clients grasp the situation in a single page.

Findings with severity and evidence

Each vulnerability with its severity, reproducible evidence and detail kept separate per platform (iOS and Android), because the same issue surfaces and is fixed differently on each.

Proof of concept

The exact steps to reproduce every relevant finding: what was pulled from the binary, which request was tampered with or which control was bypassed. No theory; the demonstration that the risk is real.

Prioritised remediation and retest

Concrete recommendations ordered by priority, so you know what to fix first. Once your team has resolved it, we retest to confirm in writing that the critical issues are closed.

What you get at the end

A technical and executive report with each finding, its real business impact and concrete per-platform remediation, plus a retest to confirm the critical issues are closed.

  • A sensitive-data map: where and how the app stores it (Keychain/Keystore, files, cache, logs).
  • Inventory of embedded secrets, API keys and endpoints exposed in the binary.
  • Assessment of communications, certificate pinning, authentication and session handling.
  • Backend/API findings and a prioritised remediation plan with a closure retest.

"The first API key we find is almost always embedded in the binary itself. The attacker doesn't steal it — the app hands it over."

— Offensive Security Team, Hard2bit

Frequently asked questions about mobile app security

Do you audit both iOS and Android?
Yes, both platforms. They share many vectors (insecure storage, communications, embedded secrets), yet they differ in their permission models, in how credentials are stored (Keychain on iOS, Keystore on Android) and in their reverse-engineering protections. We test each one with its own set of checks, following OWASP MASVS and the MASTG, and the report keeps the findings split per platform.
Do you need the application source code?
It is not essential. We usually work grey-box or black-box, starting from the installable package (IPA/APK) and running static analysis, dynamic analysis and reverse engineering. Having the source code speeds the work up and widens coverage, but most real vectors (embedded secrets, insecure storage, traffic) are assessed against the binary exactly as an attacker would receive it.
What is OWASP MASVS and why do you build on it?
MASVS (Mobile Application Security Verification Standard) is the OWASP standard that sets out the security requirements a mobile app must meet, grouped into categories: storage, cryptography, authentication, communications, platform interaction, code quality and resilience. We pair it with the MASTG as the technical testing guide. Working to this framework guarantees consistent coverage of every relevant vector and a report aligned with a standard your team and your clients recognise.
How long does a mobile app audit take?
It depends on the size of the app, the number of platforms and whether the backend is in scope. A mid-complexity app on a single platform usually takes one to two weeks of effective work; covering iOS and Android plus their API extends the timeline. We scope it with you before we start so we can give you a firm estimate.
Does being live on the App Store or Google Play mean the app is secure?
No. The stores review content policies, declared privacy and certain abusive behaviours, but they do not perform a real security audit of the code or of how the app protects its data. An app can be live and working and still store credentials in the clear, embed an API key or lack certificate pinning.
Do you also test the backend the app consumes?
Yes, and we treat it as an essential part of the scope. The backend is as attackable as the app: the application itself reveals its endpoints and, once the traffic is intercepted, an attacker works straight against the API. For an in-depth look at the backend, we combine it with our API security audit.
Where does this fit within the Hard2bit portfolio?
It is part of the Pentesting & Red Team area, alongside technical pentesting, API security audits and web application audits. The mobile audit covers the vector users carry with them all day long — the app in their pocket.

What does your app reveal when decompiled?

Request a mobile application security audit and we'll tell you, with evidence, what an attacker would extract from the binary and from your backend.