T09 · Insecure Skill Coding Practices
Warning
- Location
references/auth-setup.md:7- Finding
API Key May Be Persisted in Insecure Plaintext Configuration
- Content
View full analysis
Vulnerability Details
File Location:
references/auth-setup.md, lines 7–10 and 27–31
Vulnerability Type: Plaintext sensitive credential storage
Risk Level: MediumVulnerable Code
markdown ## Step 0 — how to store an env var on this system Figure out the correct way to persist an environment variable on this machine so it is available in every future session (a shell profile, or a config/env file managed by your agent runtime). The variable name is `STAYINGAPI_KEY`.markdown ## Step 2 — store it ```bash export STAYINGAPI_KEY="stay_live_…" # or stay_test_… for the sandboxtext ### Technical Analysis The setup guide instructs the agent to persist `STAYINGAPI_KEY` in a shell profile or agent-managed configuration file. It does not require an encrypted secret store, owner-only file permissions, exclusion from version control, protection from command tracing, or log redaction. Shell profiles and general-purpose environment files commonly store values as plaintext and may be copied into backups, synchronized between systems, included in diagnostic archives, or accidentally committed to a repository. Environment variables can also be exposed to child processes and process-inspection facilities depending on the operating system and runtime configuration. The example `export` command only sets the variable for the current shell and its descendants. Persistence would require placing it in a startup or runtime configuration file, but the guide leaves the choice and security properties of that file unspecified. This ambiguity increases the likelihood of insecure credential handling. ### Attack Path 1. A user obtains a live StayingAPI key and follows the setup instructions. 2. The user or agent writes the key into a plaintext shell profile, shared runtime configuration, or version-controlled environment file. 3. A local user, compromised process, backup reader, repository collaborator, o ...[truncated 963 chars]- Remediation
View remediation
Remediation Suggestions
- Prefer the agent runtime's encrypted secret manager, operating-system keychain, or a dedicated secrets-management service instead of shell profiles.
- If file-based storage is unavoidable, use a dedicated file outside the project directory and set owner-only permissions, such as mode
0600on Unix-like systems. - Explicitly prohibit storing the key in source-controlled files, shared shell profiles, command history, transcripts, logs, or diagnostic output.
- Add the relevant secret and environment files to
.gitignore, while noting that ignore rules do not protect files already committed. - Disable shell tracing before handling the credential and ensure verification commands do not print or log the key.
- Limit credential exposure to only the processes that require it rather than exporting it globally to every future session.
- Document key rotation and immediate revocation procedures for suspected exposure.
- Clarify that the displayed
exportcommand is session-scoped unless loaded from a protected configuration mechanism. - Recommend using sandbox keys for development and evaluation, reserving live keys for environments with appropriate secret controls.