Android app security assessment
without the source code.

Strata performs static analysis on Android APK files — parsing the manifest, DEX bytecode, signing certificates, and embedded assets to surface real security issues with OWASP mapping, severity scoring, and remediation guidance. Results in under 30 seconds.

Static analysis only
No runtime execution required
No source code needed
Analyse any APK binary
OWASP M1–M10 mapped
Industry-standard coverage

What is APK security scanning?

Static analysis of compiled Android binaries

An APK (Android Package) is a ZIP archive containing compiled Dalvik/ART bytecode (classes.dex), native libraries (.so files), the AndroidManifest.xml, resources, and assets. APK security scanning is the process of examining those artifacts — without running the app — to identify security issues before they reach users.

Static analysis works from the compiled binary: it does not execute the application, does not require a device, and does not require access to the original source code. This makes it practical for third-party assessments, supply chain review, and pre-release validation alike.

Static analysis has clear limits: it cannot observe runtime behavior, intercept live network traffic, or test server-side logic. Strata focuses on what static analysis does reliably well — manifest configuration, embedded string scanning, signing integrity, and structural red flags.

Works on any APK binary — no source code, no device needed
Results in under 30 seconds
Findings mapped to OWASP Mobile Top 10 (M1–M10)
Accurate language: static analysis only, not dynamic
APK file layout
📦bankingapp_v3.apk
📄AndroidManifest.xml← permissions, components, flags
🔢classes.dex← compiled bytecode + strings
📁lib/arm64-v8a/← native .so libraries
📁assets/← bundled files, configs
📁res/← layouts, strings.xml
🔐META-INF/CERT.RSA← signing certificate
🛡res/xml/nsc.xml← network security config

Android security issues Strata detects

These are the most common security problems found in real Android applications — each one detectable through static analysis of the compiled APK.

OWASP M1 · M6

Dangerous permissions with no clear purpose

Permissions like READ_SMS, READ_CALL_LOG, and RECORD_AUDIO are frequently declared in apps that have no legitimate need for them — either left over from copy-pasted code or intentionally abusive. Each is cross-referenced against OWASP M1 (Improper Platform Usage) and M6 (Insecure Authorization).

OWASP M3

Cleartext HTTP traffic

android:usesCleartextTraffic="true" in the manifest, missing or misconfigured Network Security Config, and HTTP URLs found in DEX bytecode are all indicators that data may be transmitted without transport encryption.

OWASP M1

Hardcoded API keys and credentials

API keys, tokens, and secrets embedded directly in compiled DEX bytecode are extractable by anyone who unpacks the APK. Strata scans DEX strings for over a dozen credential patterns — AWS, Google, Stripe, GitHub, Slack, and more.

OWASP M1 · M6

Exported components without access control

Activities, services, receivers, and content providers marked exported="true" without a permission attribute are accessible to any app on the device. Strata identifies all exported components and flags those with no protection.

OWASP M7

V1-only APK signing (Janus vulnerability)

APKs signed only with the v1 (JAR) scheme are vulnerable to CVE-2017-13156, which allows an attacker to prepend malicious DEX bytecode without invalidating the signature. V2 or V3 signing is required to close this.

OWASP M3

Missing or weak certificate pinning

When no certificate pinning is configured in the Network Security Config, the app trusts any CA in the device's trust store — including user-installed CAs — making it straightforward to intercept HTTPS traffic with a proxy.

What Strata checks

Every check listed below is performed automatically on every APK scan. All analysis is static — no emulator, no device, no source code.

📋

Manifest & permissions

All declared permissions, flagged by risk level
Dangerous permissions: READ_SMS, READ_CALL_LOG, SYSTEM_ALERT_WINDOW, REQUEST_INSTALL_PACKAGES, BIND_ACCESSIBILITY_SERVICE, and more
android:debuggable flag detection
android:allowBackup flag detection
android:usesCleartextTraffic detection
Exported activities, services, receivers, and content providers without permission protection
Implicitly exported components with intent-filters on pre-API-31 targets
Target SDK and min SDK version warnings (< 23, < 26, < 28, < 29, < 31)
🔑

Hardcoded secrets

AWS access key IDs (AKIA...)
Google API keys (AIza...)
Stripe secret keys (sk_live_, sk_test_)
GitHub personal access tokens
SendGrid, Twilio, Slack, and Mapbox tokens
JWT-like token strings
PEM private key material
Generic secret assignments (token=, api_key=, password=)
🌐

Network security

Network Security Config (NSC) parsing
Cleartext HTTP traffic permitted globally or per domain
Debug-override configuration that trusts user-installed CA certificates
Missing certificate pinning (no pin-set defined in NSC)
Cleartext HTTP URLs extracted from DEX bytecode
Private IP addresses in embedded strings
✍️

Signing & certificates

APK signing scheme detection (v1, v2)
V1-only signing — vulnerable to Janus attack (CVE-2017-13156)
Android debug key detection
Self-signed certificate detection
Expired certificate detection
Unusually short or long certificate validity
Multiple signing certificates
📦

Package structure & assets

Embedded APKs within the package (dropper detection)
Embedded JARs and secondary DEX files
Native libraries (.so) and supported architectures
Suspicious library names (frida-gadget, xposed, substrate hooks)
Large unrecognised binary blobs
Suspicious asset file names (payload, dropper, config, secret)
🧠

Behavioral indicators

Dynamic code loading strings (DexClassLoader references)
Shell execution indicators (Runtime.exec, shell commands)
Root and instrumentation tool references (Frida, Magisk, su)
Obfuscation heuristics (ProGuard/R8 short class names)
Third-party SDK detection (Firebase, Facebook, Adjust, AppLovin, and 50+ others)
VirusTotal SHA-256 cross-reference against 70+ antivirus engines

From upload to remediation

APK security scanning is only the first step. Strata gives you the workflow to act on what you find.

01

Upload the APK

Upload the APK file directly in the browser — no build system access, source code, or device required. Strata accepts any valid APK up to 500 MB.

02

Static analysis runs

Androguard parses the manifest, DEX bytecode, and assets. String scanning, heuristics, signing analysis, NSC parsing, and VirusTotal lookup run in parallel. Results are typically ready in under 30 seconds.

03

Review severity-ranked findings

Findings are ranked by severity (Critical → High → Medium → Low) with OWASP Mobile category, plain-English explanation, and concrete remediation guidance for each.

04

Triage and track

Move findings through a lifecycle: Open → In Progress → Fixed or Accepted Risk. Add notes, mark false positives, and maintain a clear picture of what still needs remediation.

05

Export a client-ready report

Generate a PDF report with executive summary, CVSS severity breakdown, OWASP coverage, and per-finding evidence — suitable for developer handoff or client delivery.

Why findings lifecycle matters

A scan report is not a remediation plan

Most APK scanners produce a report — a snapshot of what was found at a point in time. Without a way to track findings through remediation, those reports accumulate. Developers do not know what is fixed, what is still open, or what was deliberately accepted as a risk.

Strata gives each finding a lifecycle: Open → In Progress → Fixed or Accepted Risk. Status is tracked across rescan runs, so when you upload a new build, you can see exactly which findings were resolved and which are still present.

This is particularly important for recurring assessments and client reporting — rather than delivering another static PDF, you can show a measurable change in security posture over time.

Per-finding status: Open, In Progress, Fixed, Accepted Risk
Comments and annotations on individual findings
Full history of status changes
Delta view between assessment runs
SLA tracking — flag overdue findings by severity
OPEN
READ_CALL_LOG Permission
14 days open
IN PROGRESS
Cleartext traffic permitted
Fix in review
FIXED
Debug key in release build
Resolved v2.4
ACCEPTED
Self-signed certificate
Risk accepted: internal use

Common Questions

No. The APK scanner works entirely from the compiled binary — the manifest, DEX bytecode, signing certificate, and embedded assets. You never need to provide source code, a build system, or a device.
No. Static analysis cannot observe runtime behavior, intercept live network traffic, or test server-side logic. It reliably catches manifest misconfigurations, hardcoded secrets, signing issues, and structural red flags — but a penetration test that exercises the running app covers a different, complementary set of risks.
The checklist is the full manual assessment methodology — including sections that require human judgment, like storage review and report writing. The APK scanner automates the subset of that checklist which is fully deterministic from a binary: permissions, exported components, secrets, network configuration, and signing.
No. Every finding enters a tracked lifecycle (Open → In Progress → Fixed or Accepted Risk), so you can see what's resolved across rescans, not just a snapshot from one point in time. A PDF export is available whenever you need one, but it isn't the only output.

See Strata in action

Watch a walkthrough of the platform — from upload to full security report.

Demo video coming soon

Get a personalized walkthrough of Strata — we will cover your specific workflow live.

Request a Demo →

Run your first APK scan
in under 30 seconds.

Free to start — upload an APK and get a full security assessment with no credit card required. Upgrade for unlimited scans, findings lifecycle, and client-ready reports.