Mobile app security
Skill Amey-Thakur/AI-SKILLS/skills/security/mobile-app-security
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill mobile-app-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 21 days oldThe repository was created 21 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Protect a mobile app by storing secrets in the platform keystore, pinning certificates only where rotation is controlled, and treating obfuscation as delay rather than defense. Use when building or reviewing an iOS or Android app that holds tokens, keys, or user data on device.
SKILL.md
3.0 KB, 623 tokens by cl100k_base, as published. Nobody here has run it
Mobile app security
A mobile binary runs on hardware the attacker owns. They can decompile it, read its storage, and proxy its traffic on a rooted phone. The recurring mistakes all treat the device as trusted: secrets dropped in plain preferences, a binary that carries its own API keys, and obfuscation mistaken for a control. Build for an environment where the user may be the adversary.
Method
- Store secrets in the hardware-backed store, not flat files. Put tokens
and keys in the iOS Keychain with
kSecAttrAccessibleWhenUnlockedThisDeviceOnly, or the Android Keystore, never inUserDefaults,SharedPreferences, SQLite, or a plist. Those sit in cleartext in the sandbox and in cloud backups. - Ship no long-lived secret in the binary. Anything compiled in falls out
to
strings, Hopper, or jadx. Keep API secrets server-side, hand the app short-lived tokens, and route any third-party call that needs a secret through your own backend. - Pin certificates only where you can rotate fast. Pin to the CA or intermediate public key rather than the leaf, and ship at least one backup pin so a cert renewal does not brick installed apps. Skip pinning when you cannot push an update quickly enough to survive an emergency key change.
- State the ceiling on obfuscation. R8, ProGuard, or a commercial packer buys minutes to hours against a reverse engineer, not permanence. Use it to slow analysis, never as the barrier between an attacker and a value that must stay secret, since Frida reads it at runtime regardless.
- Keep sensitive data off the OS surface. Exclude token files from iCloud
and Android auto-backup, set
FLAG_SECUREor blur on backgrounding so screens stay out of the app switcher and screenshots, and validate deep links and custom URL schemes as untrusted input. - Treat root and jailbreak detection as signal, not a gate. It helps fraud scoring and can trip a casual attacker, but any client check runs on the attacker's device and gets patched out. Enforce every trust decision on the server.
Signals
- Does pulling the app sandbox off a rooted device reveal any token in cleartext?
- Does a server cert renewal keep old installs working through a backup pin?
- Can the app still enforce authorization once root detection is bypassed?
- Do sensitive screens stay blank in the task switcher and screenshots?
Boundaries
This addresses on-device storage, transport trust, and binary hardening. It does not cover the API the app talks to (see api-security) or the flow that issues its tokens (see oauth-flows). Server-side enforcement stays the real control: the client hardens, it does not decide.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.