Mobile security
Skill ahtishamshahzad/agent_dev_flow/.ai/skills/security/mobile-security
Use to review mobile app security — secure storage of tokens/secrets, no secrets in the bundle, secure transport/pinning where warranted, deep-link and IPC validation, platform permissions, and the rule that the server enforces all authorization. The security lens on the mobile pack.From its SKILL.md
npx -y skills add ahtishamshahzad/agent_dev_flow --skill mobile-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
- 25 days oldThe repository was created 25 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.
- 0 stars0 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.
SKILL.md
5.8 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
Mobile Security
Purpose
Assess a mobile app's security given its reality: the device is untrusted, the bundle is extractable, and client checks are UX. Verify sensitive data is stored/transmitted safely, entry points (deep links, IPC) are validated, and the server — not the app — enforces access. The build side lives in the mobile pack.
When to Use
- Reviewing a React Native/Expo app's security, in
../../security-review. - Not for building mobile features (
../../mobile/pack) or backend/API security (api-security).
Inputs
- The mobile app's auth/storage/transport/deep-link implementations (
../../mobile/mobile-authentication,mobile-secure-storage,mobile-deep-linking). - Threat model's client threats (
threat-modeling).
Discovery Questions
- Where are tokens/sensitive data stored — Keychain/Keystore (secure) or AsyncStorage/plaintext (not)?
- Are any secrets/API keys in the app bundle (extractable) that grant real privilege?
- Is transport TLS-only, and is certificate pinning warranted for the threat model?
- Are deep links, universal links, and IPC inputs validated and authorized before acting?
Responsibilities
- Secure storage: tokens, credentials, and sensitive data in Keychain (iOS) / Keystore (Android) via secure storage (
../../mobile/mobile-secure-storage) — not AsyncStorage/plaintext; nothing sensitive in logs. - No privileged secrets in the bundle: the app bundle is extractable — any embedded secret is public. Backend/provider secrets stay server-side; only public config ships (
../../mobile/mobile-environment-config). Flag embedded privileged keys. - Transport: TLS everywhere; assess certificate pinning against the threat model (valuable for high-risk apps, with a rotation plan; not free — record the decision).
- Entry-point validation: deep/universal links and any IPC are untrusted input — validate and authorize before acting (
../../mobile/mobile-deep-linking); a link must not perform privileged actions without server-side authZ. - Server enforces authorization: client-side gating/hiding is UX only; verify the server checks every protected action — a jailbroken/modified client bypasses all client checks (
../../mobile/mobile-authorization,authorization-security). - Platform hygiene: least-privilege permissions, no sensitive data in screenshots/backups where avoidable, no debug/logging leaks in release builds.
- Route findings to fixes + regression tests (
security-regression-testing).
Required Workflow
- Review sensitive-data storage (secure enclave vs plaintext).
- Scan the bundle for embedded privileged secrets.
- Assess transport + pinning against the threat model.
- Validate deep-link/IPC entry points + their authorization.
- Confirm server-side enforcement of all client-gated actions.
- Check permissions/logging/backup hygiene; record findings + tests.
Decision Rules
- Anything in the bundle is public — embedded privileged secrets are confirmed findings.
- Client checks are UX; the server is the boundary — an unenforced-server-side action is the real finding, not the missing client gate.
- Secure enclave (Keychain/Keystore) for anything sensitive; AsyncStorage for tokens is a finding.
- Certificate pinning is a threat-model decision with a rotation cost — recommend where warranted, don't mandate blindly.
Rules
- Never print discovered secrets/tokens — location + severity only (
secrets-audit). - Findings separated Confirmed vs Potential; never declare the app "secure" (
../../security-review). - Server-side enforcement verified for every client-gated action.
Anti-Patterns
- Tokens/secrets in AsyncStorage or logs.
- Backend/provider keys embedded in the bundle.
- Trusting client-side authorization because "the app hides it."
- Deep links triggering privileged actions without server authorization.
- Debug logging/verbose errors shipped in release builds.
Validation Checklist
- Sensitive data in Keychain/Keystore, not plaintext.
- No privileged secrets in the bundle.
- TLS enforced; pinning decision recorded.
- Deep-link/IPC inputs validated + authorized.
- Server enforces all client-gated actions.
- Permissions/logging/backup hygiene; findings → tests.
Definition of Done
A recorded mobile security assessment — secure storage, bundle secret exposure, transport/pinning, entry-point validation, server-side enforcement, and platform hygiene — with Confirmed/Potential findings routed to fixes and regression tests, and no "secure" claim.
Related Skills
../../mobile/mobile-secure-storage, ../../mobile/mobile-authentication, ../../mobile/mobile-authorization, ../../mobile/mobile-deep-linking, ../../mobile/mobile-environment-config, authorization-security, secrets-audit, security-regression-testing, ../../security-review, threat-modeling.
Related Knowledge
../../../knowledge/ (client threats, data sensitivity).
Related References
../../../references/security/ (mobile review checklists, when populated).
Context Loading Guidance
- Requires: the app's storage/auth/transport/deep-link impl, client threats.
- Does not require: backend internals beyond the enforcement contract.
- May load:
../../mobile/mobile-secure-storage,authorization-security. - Stop when: findings + routed fixes/tests are recorded.
Token Efficiency Guidance
The finding table (area → issue → severity → fix) is the artifact; the server-enforcement check is the highest-value item.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most security skills give in ~1.2k tokens
Counted across 648 of the 828 authors here whose files we hold, read 2026-08-07
- Parameterize all database queriesin 68 of 648, across 51 files
- Hash passwords using bcrypt, scrypt, or argon2in 49 of 648, across 36 files
- Apply rate limiting to authentication endpointsin 48 of 648, across 24 files
- Configure security headersin 35 of 648, across 19 files
- Validate all inputsin 32 of 648, across 24 files
- Validate all external input at the system boundaryin 29 of 648, across 19 files
- Run containers as a non-root userin 28 of 648, across 15 files
- Use httponly secure samesite cookies for sessionsin 26 of 648, across 15 files
- Run dependency audits before every releasein 21 of 648, across 10 files
- Encode output to prevent cross-site scriptingin 21 of 648, across 11 files
- Copy dependencies before source codein 20 of 648, across 9 files
- Store secrets in environment variablesin 20 of 648, across 18 files
Said here and by no other author read
- verify sensitive data uses secure storage
- scan bundle for embedded privileged secrets
- assess transport and certificate pinning
- confirm server enforces client-gated actions
- check platform permissions and logging hygiene
- record findings separated by confirmation status
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.