一键在 Manus 中运行任何 Skill

insecure-local-storage

星标20

分支0

更新时间2026年5月31日 09:09

Detects sensitive data written to unprotected local files, preference stores, or SQLite. Use when writing code that stores sensitive data (credentials, tokens, PII) to local files, platform preference stores (NSUserDefaults, SharedPreferences, UserDefaults), SQLite databases, or localStorage without encryption at rest.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

thejefflarson

thejefflarson/soundcheck

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Insecure Local Data Storage (A02:2025)

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, iOS UserDefaults, or Windows registry
Long-lived auth token placed in browser localStorage or sessionStorage where 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 localStorage or sessionStorage. 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

同仓库更多 Skills

同仓库

supply-chain

thejefflarson/soundcheck

Detects supply-chain risks in dependency manifests, lockfiles, install commands, and CI pipelines — missing lockfiles, absent vulnerability scanners, unverified installs, install hooks that pipe remote content to a shell, and AI-hallucinated package names. Use when writing package install commands, dependency manifests, CI/CD configs, build scripts, or code that loads external packages.

2026-06-1320

contract-review

thejefflarson/soundcheck

Deep review that audits API contracts for mismatches between what callers assume and what implementations enforce. Designed for nightly CI, pre-release scans, or manual deep audits — runs in tens of minutes, not seconds. Surfaces bugs that single-pass OWASP review misses — caller/callee invariant gaps, trust-anchor confusion, predicate misnaming.

2026-06-1020

security-review

thejefflarson/soundcheck

Runs a full OWASP/CWE security audit via isolated subagents. Use when the user types /security-review or explicitly requests a full security audit of the current code.

2026-06-1020

authentication-failures

thejefflarson/soundcheck

Detects weak password storage, flawed JWT validation, sessions surviving logout, and missing MFA in authentication code. Use when writing login flows, session management, password storage, JWT handling, MFA implementation, credential validation, or any code that authenticates users. Also invoke when implementing "remember me" functionality or API key management.

2026-05-3120

broken-access-control

thejefflarson/soundcheck

Detects missing ownership checks, broken role enforcement, and IDOR vulnerabilities that let users access other users' resources. Use when writing code that checks authorization, enforces resource ownership, handles IDOR (object-level authorization), processes server-side requests to external URLs, or implements access control middleware.

2026-05-3120

concurrency-correctness

thejefflarson/soundcheck

Detects multi-threaded code where a lock is held across a blocking operation, lock acquisition order risks deadlock, lock-free atomics use the wrong memory ordering, or double-checked locking is missing the necessary barrier. Use when writing or modifying code that acquires multiple locks, uses atomic operations with explicit memory orders (std::memory_order_*, atomic.LoadAcquire, Ordering::Relaxed), implements lazy initialization with double-checked locking, or calls a blocking operation (I/O, sleep, await, blocking channel send) inside a locked region.

2026-05-3120

name	insecure-local-storage
description	Detects sensitive data written to unprotected local files, preference stores, or SQLite. Use when writing code that stores sensitive data (credentials, tokens, PII) to local files, platform preference stores (NSUserDefaults, SharedPreferences, UserDefaults), SQLite databases, or localStorage without encryption at rest.

Insecure Local Data Storage (A02:2025)

What this checks

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, iOS UserDefaults, or Windows registry
Long-lived auth token placed in browser localStorage or sessionStorage where 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

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 localStorage or sessionStorage. 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