Your app ships to the attacker. Know what it hands them.
Upload an APK or IPA and get a security assessment of the build itself — manifest, signing, transport policy, binary protections and anything you compiled in by accident — scored against OWASP MASVS and the Mobile Top 10.
The problem
A mobile build is the one artifact you hand your attacker
Everything else you run is behind a network boundary. The app is not: it is downloaded, unpacked and read at leisure, and whatever it enforces locally is only a suggestion.
The client is not a control
Certificate pinning, root detection and input validation all live in code the attacker holds. They raise cost; they do not enforce anything. Only the server does.
Secrets get compiled in
An API key added “temporarily” during development ships in every install. There is no way to revoke it from the build, and no way to tell it was ever there without looking.
Release settings drift
A debuggable flag, a backup-enabled manifest, a development provisioning profile — each is one build setting, and each is invisible in the store listing.
What gets checked
Every check reads the bundle, not a questionnaire
The compiled manifest is decoded, the signing block is parsed, the Mach-O header is read. Findings carry the bytes they came from, so you can verify each one rather than take it on trust.
Manifest & entitlements
The compiled AndroidManifest is decoded, not guessed at: debuggable builds, backup-enabled data, cleartext transport policy, exported components reachable by any app on the device, and custom permissions declared below signature level. On iOS, the Info.plist and provisioning profile — including get-task-allow, which makes a build debuggable on any device it reaches.
Code signing
Which APK signature schemes the build actually carries, whether it is v1-only, and the certificate behind it — debug identity, digest algorithm and key size. A build signed with the Android debug key can be impersonated by anyone with the SDK.
Transport security
Android network security config and iOS App Transport Security are read as policy, not as a checkbox: cleartext permissions per scope, user-installed CA trust, per-domain ATS exceptions that lower the minimum TLS version, and whether any certificate pinning is configured at all.
Binary protections
The Mach-O header is parsed for PIE, stack canaries and ARC. Every one of these is a compile-time setting whose absence makes a memory-corruption bug materially easier to exploit — and none of them is visible from the outside.
Embedded credentials
Cloud keys, tokens, private keys and database URIs matched against self-identifying formats across every member of the bundle. Anything inside the package is readable by anyone who downloads the app; unpacking one takes seconds.
Third-party SDKs & privacy
Which analytics and advertising SDKs ship inside the build, so you can reconcile them against your privacy notice and store data-safety declaration. Not vulnerabilities — data-processing relationships you have to be able to account for.
How it works
Upload a build, get an assessment
Upload the build
An Android .apk or iOS .ipa, straight from CI or by hand. The binary is stored only for as long as its analysis exists — deleting the run deletes the artifact.
We take it apart
The bundle is unpacked and the manifest, signing material, entitlements, native binary and compiled code are read directly. No emulator, no agent, nothing installed.
Score and map
Findings are mapped to OWASP MASVS controls and the Mobile Top 10, scored by severity, and reported alongside the checks that passed — so the report shows coverage, not just failures.
Follow it to the backend
The hosts the app talks to are recovered from the build and offered as candidate scan targets, so the server-side test starts from the client's own inventory.
Scoring
A score you can recompute from the findings table
Every build gets a score out of 100. It starts at 100 and deducts by severity — 25 for a critical, 12 for a high, 5 for a medium, 2 for a low. Informational observations deduct nothing. That is the whole formula, and it is printed in the report, because a score a reader cannot reproduce from the table underneath it is decoration.
- Passing checks are listed, so the report shows what was assessed and not only what failed.
- Observations that cannot be confirmed statically are reported and scored at zero, rather than inflating a finding count.
- Gaps in coverage get their own section. A check that could not be evaluated is never presented as one that passed.
- Every report is anchored to the SHA-256 of the exact build it describes.
Beyond the binary
The app is the most honest inventory of its own backend
Most mobile risk is server-side. The hosts and paths an app calls are compiled into it, which makes the build a starting point for the test that actually matters.
Candidate hosts, reviewed by you
Endpoints recovered from the build are presented as candidates, not conclusions — a bundled library carries its own documentation links and namespace URIs, and they look identical in the bytes. You tick the ones you own before anything becomes a target.
Third parties stay out of scope
Hosts belonging to known vendors are listed for your privacy review and never offered as scan scope. An app calling a payment processor is not authorisation to test that processor.
Release over release
Each analysis is compared with the previous build of the same package, so you can answer the question a release assessment is actually asked: is this one better than the last?
Scope
What this does not do
This is static analysis of the shipped bundle. The application is not installed and not executed, so runtime behaviour is outside its scope — what actually gets written to disk, which calls are made in practice, and whether certificate pinning is enforced at runtime all need instrumentation this does not perform.
- Findings derived from compiled code prove the app references a construct; they do not prove the code path runs.
- Server-side authorization, business logic and API vulnerabilities need their own test — that is continuous pentesting, pointed at the backend.
- Detection is pattern- and signature-based. A custom or obfuscated implementation may not be matched, so the absence of a finding is not proof of absence.
Every report states these limits in its own scope section. We would rather the document name its boundary than let a reader treat it as a full penetration test.
Reporting
A report you can hand to someone
The same assessment in the format the reader needs, all generated from one set of stored checks so the formats cannot disagree.
HTML & PDF
A branded document with a cover, remediation order and full findings — your colours and company name, not ours.
JSON
A versioned, machine-readable contract for pipelines and dashboards.
CSV
Every check as a row, for spreadsheets and GRC evidence packs.
Tamper-evident
Each report carries a digest recomputed from its stored checks, so an altered copy is detectable.
Related solutions
The binary is one half of the assessment
A client-side finding tells you a secret is embedded. Only a backend test tells you what that secret reaches.
Continuous Pentesting
Test the APIs the app depends on with authenticated, authorization-aware scanning — the half of mobile risk the binary cannot show you.
Learn more →Attack Surface Management
Map everything your organisation exposes to the internet, and keep the mobile backend in the same inventory as the rest of it.
Learn more →Compliance Evidence
Mobile findings carry CWE and OWASP mappings, so they export into the same SOC 2, ISO 27001 and PCI DSS evidence as everything else.
Learn more →By industry
Mobile testing by industry
Which frameworks your mobile findings need to map to depends on the data the app handles and the obligations that come with it.
FAQ
Frequently asked questions
How RedStrike tests mobile applications.
What do you need to test a mobile app?
An Android .apk or an iOS .ipa, up to 300 MB. Nothing else — no source code, no device, no agent in the build. The analysis reads the bundle you upload.
Is this static or dynamic analysis?
Static. The app is not installed and not executed, so runtime behaviour — what is written to disk, which calls are made, whether pinning is enforced in practice — is out of scope, and every report says so in its own scope section. On-device dynamic testing is a separate capability and is not part of this.
Which standards are findings mapped to?
Every finding carries OWASP MASVS control ids and OWASP Mobile Top 10 (2024) categories, plus a CWE where one applies. The report includes a Top 10 table showing which categories were assessed, which are clear, and which cannot be decided from a bundle at all — the last of those is marked as unassessed rather than passed.
Do you need MobSF?
No. The analysis is native and runs with no extra infrastructure. If you already run MobSF, it can be configured as an additional source and its findings are merged in and attributed — but it is enrichment, never the only path, so a MobSF outage degrades the report rather than producing a false clean result.
Can it test the app's backend too?
The hosts the app calls are recovered from the build and offered as candidate scan targets. They are candidates rather than conclusions — a bundled library's documentation links look the same in the bytes as your own API — so you select the hosts you own, and the target then goes through the normal scope validation and Rules of Engagement before anything is scanned.
Can I compare one release against the last?
Yes. Each analysis is compared with the previous completed analysis of the same package, showing the change in score, failing checks and critical count, so a release can be assessed as better or worse rather than in isolation.
What happens to the build after the analysis?
It is stored only for as long as the run exists. Deleting the analysis deletes the binary, because an uploaded build routinely contains the very credentials the report is about.
Find out what your app is handing out
Upload a build and get a MASVS-scored assessment of what ships inside it — plus the backend surface it points at.