Insecure Local Data Storage (A02:2025)
SkillFiles & storageDetects sensitive data written to unprotected local files, preference stores,
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Insecure Local Data Storage (A02:2025) skill
What this skill tells your AI
The instructions your AI receives, as published by thejefflarson/soundcheck in .claude/skills/insecure-local-storage/SKILL.md and read by ahel’s review.
What this checks
Detects sensitive data written to unprotected local storage. Cleartext storage lets any process with file-system access, or a device backup restore, harvest credentials and tokens without authentication.
Vulnerable patterns
- Credentials or tokens written to a plain file (JSON, INI, dotfile) without encryption
- Sensitive values written to an unencrypted platform preference store such as Android
SharedPreferences, iOSUserDefaults, or Windows registry - Long-lived auth token placed in browser
localStorageorsessionStoragewhere any script on the origin can read it - SQLite or other embedded database storing credentials with no at-rest encryption
- Temp files containing secrets written to a world-readable directory with default permissions and not deleted on completion
Fix immediately
Flag the vulnerable code and explain the risk. Translate the principles below to the audited file's platform and language — use that platform's documented secure-storage API (keychain, EncryptedSharedPreferences, DPAPI, HttpOnly cookie, etc.).
For each finding, establish these properties:
- Sensitive values go to platform-managed secure storage, not a plain file or
pref store. OS keychain, Android
EncryptedSharedPreferences, Windows DPAPI or Credential Manager, Linux secret service. These encrypt at rest and scope access to the owning process. - Web clients do not store long-lived credentials in
localStorageorsessionStorage. These are readable by any script on the origin — one XSS and the token is gone. Use a Secure, HttpOnly, SameSite cookie for session tokens, or a short-lived in-memory token refreshed from the server. - If secure storage is unavailable, data is encrypted with a key that also lives in secure storage — not hardcoded, not in the same file, not derived from device-static values. Symmetric encryption with a keychain-held key is the baseline.
- Temp files for sensitive data are avoided, or created with restrictive user-only permissions, written to a user-only directory, and deleted in a finally/cleanup block — never left in a world-writable directory with default permissions.
Verification
- No credentials, tokens, or PII written to plain files or standard preference stores
- Platform secure storage API used (keyring, Keychain, EncryptedSharedPreferences, DPAPI, or equivalent for the platform)
- Temp files with sensitive data use secure deletion or are avoided entirely
References
Signals
- GitHub stars
- 20
- Last commit
- Jul 2026
Advanced
- Catalog kind
- skill
- Gateway key
insecure-local-storage- Source
- github.com/thejefflarson/soundcheck