4 Vulnerabilities Mobile AppSec Testing Finds That Code Review Misses

Most mobile security incidents aren't caused by sophisticated zero-days. They're caused by ordinary mistakes that made it through code review because they don’t look dangerous in context. That might look like a key pasted into a config file during a sprint, a certificate check that only covers half the app's network calls, or an activity left exported because removing the flag might break something else. None of these issues would trip an obvious alarm for a human reviewer. However, all of them are examples of exactly what automated mobile application security testing (MAST) is built to catch.

The gap between what looks fine in a pull request and what’s actually exploitable in a compiled binary is worth revisiting. As mobile apps ship faster and lean more heavily on third-party SDKs and AI-connected backends, the number of places a small oversight can hide has grown right along with them.

1. Hardcoded secrets

It would be convenient to think hardcoded API keys and credentials are a junior-developer problem, fixed once a team matures. The data says otherwise. A 2026 scan of more than 150,000 mobile apps found that nearly 40% contained hardcoded Google API keys capable of reaching billable AI functionality, and separate research identified dozens of hardcoded keys across popular Android apps that granted unauthorized access to generative AI services and their cached data. In both cases, the apps analyzed were current, widely distributed, and built by teams that likely had code review in place.

Code review misses this type of vulnerability for structural reasons, and not for a lack of diligence. A hardcoded key is a single line in a single file, which is easy to overlook in a pull request and easy to justify as temporary at the time. Static analysis doesn’t make that kind of exception. It checks the entire compiled binary, flags every embedded credential no matter which file it's in, and does this on every build, not just the ones a reviewer happens to look at closely.

2. Certificate pinning

Certificate pinning and TLS validation are critical mobile protections, but implementing them securely is a complex, highly error-prone task. This is one of the few mobile protections where being technically present isn't the same as being effective, which is exactly why it’s so hard to catch by reading code. Previous AppSweep analysis has highlighted exactly how often developers get this wrong, revealing common certificate verification issues in over 33% of scanned builds. When teams attempt to customize certificate handling, they frequently introduce structural vulnerabilities that look harmless in a pull request.

Flawed or partial pinning implementations create a dangerous false sense of security. For example, in one penetration test, a tester bypassed pinning on an app's primary networking layer only to find some API calls still failing. The app turned out to have a second, custom networking layer with its own certificate check that the first bypass never touched. Once both layers were addressed, the newly visible traffic exposed further issues, including an unauthenticated admin endpoint that had never been reachable from the UI.

This matters because a single unprotected path is enough for a bad actor to execute a Man-in-the-Middle (MITM) attack and intercept data. Reviewing pinning logic in isolation won't always catch this problem, because it only appears when you look at how separate parts of the app work together. That's not something a reviewer typically checks all at once. That kind of cross-cutting, whole-binary check is exactly what automated testing does well and manual review does not.

3. Exported components

Android's component model is designed for apps to talk to each other, and that same design is what makes an improperly exported activity, service, or broadcast receiver dangerous. Setting a component to exported, or simply adding an intent filter without thinking through the implications, opens it up to any other app installed on the device — not just the ones you intended to integrate with.

A 2025 case shows how big this problem can get. Microsoft researchers found a flaw in a push-notification SDK used by crypto wallet apps and others, together representing more than 50 million installs. One activity in the SDK was left exported, meaning any other app on the device could send it messages directly. When that activity received a message, it forwarded it onward without checking where it came from, so a malicious app could piggyback on that trust and reach data it should never have been able to touch.

The real problem here wasn't a coding mistake in anyone’s app. It was a single setting in a configuration file, buried inside a third-party SDK that thousands of apps had simply plugged in. Every app that used the SDK inherited the same flaw without writing a single line of vulnerable code themselves. That’s exactly why this kind of issue is so easy to miss: nobody's reading through a dependency's configuration files on every release, and there’s no code in your own app that would tip you off.

4. Debug flags

Debug settings exist for good reasons during development. The problem is that these settings are only supposed to last through development, not make it into the release build. A code review typically checks whether the right code was written, not whether leftover settings were removed — so a lingering debug flag rarely comes up in a design discussion or a PR comment. It was never a decision anyone made on purpose; it's just something nobody remembered to undo.

The risk is real once you look for it. OWASP maintains a specific test just for checking whether an app was accidentally shipped with debugging still enabled, because it's common enough to warrant its own standard check. And one real-world case showed what that oversight can cost: testers found a published app still in debug mode, and were able to pull stored user data straight out of its memory. Catching this depends on someone or something checking the final build itself, not the code that produced it. This is a testing problem, not a code-quality problem, and it's why these findings show up so consistently in MAST scans even on teams with strong review practices.

How MAST detects mobile app security vulnerabilities

None of these four issues are exotic. Hardcoded secrets, incomplete pinning, careless exports, and leftover debug configuration are well understood, well documented, and still appear in current, widely used apps. That persistence makes sense once you consider what code review is actually built for. It's designed to check whether the logic in a change makes sense, not to catch problems that span multiple files, depend on a third-party library, or only show up when you look at the fully compiled app. Expecting reviewers to catch those issues means asking a process meant for one job to do a different one.

However, that’s the specific job MAST is built for. Tools like AppSweep scan the full app package on every build, checking it against recognized standards like OWASP MASVS. The results show exactly the class of issue described here — the kind that's structurally invisible to a reviewer, but immediately visible to a tool looking at the whole binary.

Pairing MAST with periodic pentesting still matters for the judgment calls and business-logic flaws that require a human attacker's creativity. But for the categories above, automated testing works best because it doesn't depend on individual code reviewers remembering to look.

Want to learn more about MAST for your app? Reach out to our team.