The mobile app security finding categories that matter most

Run enough Android and iOS scans and the results stop being a surprise. The same finding categories come back at the top almost every time: manifest and configuration mistakes, insecure code and DEX patterns, weak network settings, and unsafe serialization. These are not rare or clever bugs. They are the ordinary result of shipping fast, reusing old code, and trusting framework defaults that were never meant for production.

This article goes through the categories that fill a real scan queue, one group at a time. For each, you get what it means in engineering terms, why it ranks so high, and the change that actually fixes it. It is written for people who build and review apps, not for a binder that sits on a shelf.

How to read a category list

A scanner sorts findings into categories so you can fix related problems together instead of one row at a time. The names look long, but they all sit on top of three surfaces:

• The package and its manifest. The settings that decide what the app exposes to the rest of the phone.
• The code and the DEX. What the app does once it runs, including the secrets and weak crypto baked into it.
• The network and data movement. What leaves the device, where it goes, and whether it is protected on the way.

Almost every category below maps to one of those three. Once you see which surface a finding lives on, the fix and the owner usually become obvious.

Manifest and configuration: the cheapest wins

Manifest findings sit at the top of most scans for a simple reason: one XML file decides a lot, and its defaults lean toward open, not closed. Categories like manifest, manifest_audit, intent_security, task_hijacking, tapjacking_protection and screenshot_protection all come from this surface.

• Exported components. An activity, service, receiver or content provider marked exported, or treated as exported because it declares an intent filter, can be reached by any other app on the phone. If it does sensitive work without checking the caller, that is a free entry point. Set android:exported on purpose and guard it with a permission.
• Debug and backup flags. A build left with debuggable on, or allowBackup open, hands over far more than most teams expect. These are one-line settings that should be off in a release build.
• Intent handling. Implicit intents can leak data to whatever app answers them, and a mutable PendingIntent can be filled in by someone else. Prefer explicit intents for sensitive actions, and mark a PendingIntent immutable unless you have a reason not to.
• Task hijacking. A loose taskAffinity or the wrong launch mode lets a hostile app slot its own screen into your task and sit on top of yours. Lock down task affinity for screens that handle login or payment.
• Tapjacking. An overlay drawn on top of your app can trick a user into tapping something they cannot see. Set touch filtering on sensitive buttons so taps through an overlay are dropped.
• Screenshot and recents. Sensitive screens that allow screenshots, or show up in the app switcher thumbnail, expose data to anyone holding the phone. Apply the secure-window flag on screens that show tokens, balances or personal data.

These rank high because the fixes are small and the defaults are permissive. They are also the cheapest findings to close, which makes them a good first pass.

Code and DEX: where secrets and weak crypto hide

The next group looks inside the compiled app. Categories like code, dex_analysis, crypto_advanced and serialization_security read what the app actually does, not just what its manifest declares.

• Code patterns. Hardcoded keys and passwords, personal data written to logs, SQL built by gluing strings together, and weak sources of randomness. Each one is a small habit that turns into a real problem at scale. Move secrets to the backend, keep sensitive values out of logs, use parameterised queries, and use a secure random source.
• DEX analysis. This reads the bytecode the device runs. It flags reflection used to reach hidden APIs, dynamic class loading that pulls in code at runtime, and calls to risky platform APIs. Dynamic loading is worth a close look, since it can turn a clean review into a moving target.
• Advanced crypto. The classic mistakes still dominate: ECB mode that leaks patterns, MD5 or SHA-1 used where they no longer belong, a fixed initialization vector, a key written into the code, or a password stretched with a weak function. Use an authenticated mode, a modern hash, a random IV per message, and keys from the platform keystore.
• Serialization. Turning untrusted bytes back into objects is a long-standing source of trouble. Java serialization from an outside source can be abused through gadget chains, a Parcel read in the wrong order can be coaxed off track, and JSON mapped straight onto types without checks can set fields you never meant to expose. Prefer a simple, typed data format and validate every field you read.

This group ranks high because the code is reused across releases. A weak pattern written once tends to travel from app to app and from year to year until something forces a rewrite.

Network and data movement

The third surface is everything that leaves the phone. Categories like network_security, background_exfiltration, Cloud Credentials and file_analysis live here.

• Network security. Traffic sent in clear, a network config that allows cleartext, or certificate validation that has been turned off or worked around. Any of these lets traffic be read or changed by someone on the same network. Send everything over TLS, keep validation on, and add pinning where the risk justifies it.
• Cloud credentials. Keys for cloud and backend services bundled inside the app. A reviewer can pull these out of the package in minutes, and they often grant far more access than the app needs. These belong on the server, behind a token the app requests at runtime.
• Background data movement. Work scheduled to run in the background can send data off the device with no screen in front of the user. Worth checking that every background job sends only what it should, to a destination you control.
• File analysis. Files written where other apps can read them, data left on shared storage, and sensitive files shipped inside the package itself. Keep private data in app-private storage and check what you bundle before you build.

This is the group where a single finding can expose the most, because the data is already moving. A hardcoded cloud key or a cleartext endpoint often outranks a dozen smaller issues on its own.

Newer surfaces: integrity, AI, privacy and WebView

A few categories track newer ground. They show up less often than a missing export flag, but when they land they tend to matter. Think play_integrity, shadow_ai, privacy_analysis and webview_advanced.

• Integrity and attestation. Whether the app checks that it is running on a genuine device and has not been tampered with. For apps that handle money or sensitive accounts, weak or missing attestation lets a modified build talk to your backend as if nothing changed.
• Shadow AI. AI features and on-device models often arrive through a bundled SDK that sends data to a third-party endpoint the team never reviewed. The finding is not the AI itself, it is the undeclared data path. Know which SDKs move data, what they send, and whether your privacy notice covers it.
• Privacy analysis. The gap between the permissions and trackers inside the app and what users are told. Closing this is mostly housekeeping: drop permissions you do not use, remove dead SDKs, and make the disclosure match the code.
• WebView. A WebView that bridges JavaScript to native code, allows file access, or loads untrusted URLs can turn a web bug into a device bug. Limit the JavaScript bridge, keep file access off unless you need it, and never load a URL you do not trust.

Category to fix, at a glance

The same information in one place. Use it as a quick reference when you are sorting a result set.

Turning categories into a fix order

A long category list is only useful if it tells you what to do first. Volume is not the same as risk. A scan can show fifty manifest notes and one hardcoded cloud key, and the single key outranks the fifty. A practical order:

• Exposed secrets and cloud credentials first. They give the most access for the least effort, and the fix is clear.
• Network problems next. Cleartext traffic and disabled certificate checks expose live data, and they affect every user at once.
• Reachable components. Exported activities, services and providers that do sensitive work without checking the caller.
• Crypto and serialization. Higher effort to exploit, but they tend to sit deep in code that many features depend on.
• Integrity, privacy and the rest. Important over time, and often a matter of policy as much as code.

Give each finding an owner and a due date, and re-scan the build you actually ship. A category list that nobody owns becomes noise by the next release. The goal is not a clean report once. It is a shorter list every time, on the build that reaches users.

One note on method. All of this assumes you are testing apps you own or are authorised to test. The categories above describe how to find and fix weak spots in your own software before someone else does, which is the only setting where this work belongs.

Common questions