How to find hardcoded secrets in an Android app

Hardcoded secrets are one of the most common and most damaging findings in mobile apps. A key left inside the app file can be pulled out in minutes, and if it is a server-grade credential it can affect every user at once. This guide shows where they hide in an Android app and how to find them, working from the build you ship.

Everything here works from the compiled APK or AAB, which is the same file an attacker downloads. You do not need the source code. Only test apps you are authorised to test.

Why secrets end up in apps

Secrets land in apps for ordinary reasons. A developer hardcodes a key to get something working and forgets to remove it. A third-party SDK needs configuration that includes a token. A test endpoint and its credentials ship by accident. None of it is malicious, and all of it is readable, because the app is a file anyone can open.

The danger depends on the secret. A public client identifier is usually fine. A server-grade key, a cloud access key or a signing secret is not, because it grants privileges that belong on a backend, not on millions of devices.

Where to look

Most exposed secrets sit in a handful of places inside the package:

A practical process

A simple, repeatable pass finds most of what matters:

• Open the package. An APK is a zip file, so you can unpack it directly.
• Decompile to readable code. Open-source tools like apktool and jadx turn the bytecode and resources back into something you can read.
• Search for known patterns. Grep the unpacked files for high-signal markers: AIza for Google API keys, AKIA for AWS access keys, BEGIN RSA PRIVATE KEY, and words like secret, password, token and apikey.
• Scan native libraries. Run a strings pass over the .so files, since keys often hide there too.

Confirm whether it is live

A string that looks like a key is not always a risk. The question is what it can do. A public client token is expected; a privileged server key is a real exposure. Confirm the type and scope before you treat it as critical, and never test a credential against a live system without explicit authorisation.

This is where deterministic checks help. Confirming a key by its structure and the service it belongs to turns a guess into a fact, which is what keeps secret findings out of the noise.

How to fix and prevent it

The fix is the same shape every time. Move anything privileged to a backend and ship only the minimum the app needs. Rotate any key that was exposed, because the old build stays exploitable until every user updates. Then stop it happening again by adding a secret scan to your build pipeline, so a server credential can never reach a public artifact.

For the underlying concept, see hardcoded secrets. For the wider picture, read what is mobile application security.

Common questions