Android Security
I started building for the web in 2002. Backends, frontends, infrastructure. In the last decade, I’ve switched between leading teams and writing code myself.
Before Oversecured, I knew the usual warnings about mobile security. Users don’t update right away. Never trust the client. Anything in the app can be extracted. Secure storage depends on configuration. Deep links and exported components widen the attack surface. None of this is secret; most of it fits on a single conference slide. I’ve probably seen that slide a dozen times.
But there is a comfortable distance between knowing that something can happen and seeing how often it actually does.
Then I joined Oversecured as Head of Engineering. My job is to build the team and the product. The security research is handled by people who have been doing this for years. In my first week, I started looking at patterns that show up in real production apps. The mechanisms were mostly familiar. The frequency, combinations, and consequences were not.
My first week didn’t prove my mental model wrong. It just made it harder to pretend the worst cases were rare.
Here are four concerns that stopped being theoretical.
Underweighted #1: "If we find a security bug, we'll ship a fix"
This is one of the deepest instincts in web engineering. Vulnerability found > patch > deploy > postmortem > coffee. You own the servers, so the fix reaches everyone immediately. On the frontend, it can be even more forgiving: users get the new bundle on the next page load, whether they asked for it or not. I've run that playbook so many times that it stopped feeling like a decision.
I knew mobile was different. Releases go through app stores, reviews take time, and users update whenever they feel like it. What I hadn’t seen up close was just how many old, vulnerable binaries keep running after a fix ships.
A team fixes a bug, submits a new build, waits for review, and then users update or don’t. For a good chunk of them, that means sometime between "eventually" and "never". Builds from years ago can still be installed, still running, and still exploitable. You usually can’t replace or erase every copy out there.
The vulnerable binary doesn’t disappear when the fix ships. It keeps running alongside the fixed one.
There are ways to contain the damage: revoke credentials, disable endpoints, enforce a minimum version, and request expedited review. But these are damage control for clients already out of your hands, not the same as a deploy.
The theory was familiar. The evidence changed its weight. Every vulnerable binary you release can stick around long after a fix is out. Pre-release security starts to feel less like the web’s move-fast, fix-in-production rhythm and more like shipping firmware.
Underweighted #2: "Never trust the client - I know this one"
I did know this one. I've repeated it to teams for years. A client can forge requests. Authorization belongs on the server. Anything sent to the client can be inspected. And I knew that mobile applications could be decompiled, debugged, instrumented, patched, and re-signed.
What really stood out was how much sensitive information still ends up in these apps.
A mobile app is your code running on hardware you don’t control, sometimes in the hands of someone trying to break it open. Attackers have the binary. They can use it as a guide to your API and a blueprint of your system’s assumptions, often more revealing than any internal docs. And unlike a web page, the binary often includes proprietary logic, persistent data, sensitive keys, OS permissions, native code, offline features, and connections to other apps.
Anything the app knows, including every embedded secret, privileged assumption, and client-side check, is effectively published. Obfuscation slows this down but doesn’t change it.
What surprised me wasn’t the technical possibility. It was seeing that, even though most engineers agree on this principle, code with hardcoded credentials, secrets, and open API keys still ships, even at established companies. It’s not that people haven’t heard “never trust the client”; compiled code just gives a false sense of privacy. Knowing the rule isn’t the same as building every system with its real-world consequences in mind.
Underweighted #3: "Secure storage means that the part is handled"
Keychain on iOS. Keystore on Android. Hardware-backed, encrypted, and officially blessed as the place where sensitive tokens are supposed to live. I knew the details mattered: accessibility classes differ, hardware backing varies by device and configuration, and guarantees need to be checked, not assumed from the API name. The documentation, to be fair, sounds very reassuring.
What stopped being theoretical was how often the storage API turns out to be only one link in a much less secure chain.
Choose a migratable Keychain accessibility class when data is intended to remain bound to a single device and may be carried over during backup and restore. Assume that "stored in Android Keystore" automatically means "protected by secure hardware," and you may be relying on a guarantee the device does not actually provide.
But even a perfectly configured storage API can’t protect data that gets copied somewhere else five lines later. The same token can be stored correctly and still leak through a log, an analytics event, a clipboard, or an unencrypted cache file. That’s exactly where sensitive data keeps turning up in real apps: a token in the vault and a copy in the
logs.
The web-stack version of this is saying “we encrypt at rest” and calling it done: the same false comfort. The evidence made one thing hard to ignore: data security is about the whole lifecycle, not just the most reassuring API you used somewhere.
Underweighted #4: "Deep links are navigation plumbing"
I knew what deep links were before this job. They open screens, carry parameters, and interact with OS routing. What I hadn’t done was treat them with the same urgency as APIs or other externally reachable endpoints.
That changed fast.
A deep link is a public entry point. Other apps, webpages, and messages can try to invoke it with any parameters, and the app wakes up and runs whatever handler is wired to it. This bypasses any assumptions about how a user “normally” gets to a screen. A recurring pattern: a link jumps straight into a flow that quietly assumes the user has already passed through two earlier screens and their checks.
On the web, I learned to assume every endpoint can be called directly, no matter which pages the user visited first. A mobile route deserves the same suspicion. A deep-link handler or exported intent receiver might look like navigation plumbing, but to an attacker, it’s just another externally invocable interface, no matter how internal it looks in the code.
Custom URL schemes make things worse. Another app can register the same yourapp:// scheme and receive links meant for your app. If those links carry something sensitive, such as a magic-link token or an OAuth redirect, a malicious app can intercept them. That’s why verified App Links and Universal Links are part of the security model, not just optional polish.
Twenty years of web work taught me to audit URLs as server-owned routes. Mobile made the wider lesson concrete: an entry point is still an endpoint, no matter what the product calls it.
The actual lesson
Most of the facts here weren’t new to me. What changed was how much I believed them.
Before Oversecured, I understood these risks as principles: old clients stick around, binaries are inspectable, secure storage depends on configuration, and mobile apps expose more entry points than you’d expect. After seeing these problems show up again and again in real apps-and seeing ordinary implementation decisions combine into full attack paths-I stopped thinking of them as warnings at the edges. They define the environment.
That distinction matters because knowing a risk exists does not necessarily change a roadmap. Seeing it repeatedly in shipped applications does. The consoling assumption that a known risk is rare, isolated, or somebody else's problem is usually the first thing the evidence takes away.
The practical consequence is that mobile security has to move earlier. Test the artifact that will actually ship, not just the source. Treat every externally reachable component (deep links, exported activities, services, and intent receivers) as a public endpoint. Verify the full lifecycle of sensitive data rather than trusting the storage API's name. Build server-side containment before a vulnerable binary leaves your control.
A note, mostly for myself:
You can’t reliably hotfix every phone. The client isn’t just untrusted; it’s your code running on ground you don’t control. An app has more front doors than its visible interface suggests.
My first week didn’t convince me that the warnings about mobile security were true. I already believed them. It convinced me they were understated.
