Guide

Android app security checklist before you ship

A practical pre-release checklist for Android apps: secrets, cloud backends, network, signing, exported components, dependencies, privacy, and build hygiene.

Last updated 2026-09-07

Short answer: Before every release, verify eight things: no hard-coded secrets, locked-down cloud rules, HTTPS-only traffic, strong v2/v3 signing, no needlessly-exported components, no known-vulnerable dependencies, an accurate Play Data Safety label, and minimal permissions. Most of it is checkable statically — the list below links each item to how to fix it.

Read in context. These instructions need to be adapted to your app and platform version. New scans provide static detections; they do not establish current backend access. Current methodology.

The checklist

1. Secrets & keys

No API keys, tokens, private keys or wallet seeds in the APK. Find them · store them right.

2. Cloud backends

Firebase/Firestore/Supabase rules require auth; storage buckets are not world-readable. Fix open databases.

3. Network

No cleartext HTTP; consider certificate pinning for sensitive APIs. Disable cleartext.

4. Signing

Signed with APK Signature Scheme v2/v3, SHA-256+, RSA ≥ 2048 or EC, a real (non-debug) release key. Signing explained.

5. Components & IPC

No component exported without need; necessary ones gated by a signature-level permission. Fix exported components.

6. Dependencies

No bundled SDK with a known CVE; track components in an SBOM. Check dependencies.

7. Privacy & permissions

Request only the permissions you use; Play Data Safety reflects what the app AND its SDKs collect/share. Data Safety guide · COPPA if kids-directed.

8. Build hygiene

android:debuggable false, allowBackup considered, no debug/logging SDKs (Chucker/Flipper) in release, obfuscation on.

Automate it

apk-scanner.com provides static findings, build details and analysis coverage. Scans check whether a referenced backend answers an unauthenticated request, never using a detected credential and never reading stored data. Review the current methodology and each report’s limitations.

Frequently asked questions

When should I run this?

On every release build, ideally automated in CI so a regression (a newly-leaked key, an SDK bump with a CVE) blocks the merge rather than shipping.

If my app passes, is it secure?

It clears the common, high-impact static issues — but static checks can't cover runtime/logic/auth flaws. Treat a clean scan as necessary, not sufficient; a real pentest covers the rest.

Can I gate CI on it?

Yes — the GitHub Action uploads your build, produces SARIF for the Security tab, and fails on findings at or above a severity you choose.

Scan an app free →