T09 · Insecure Skill Coding Practices
- Location
README.md:60- Finding
Persistent Plaintext Storage of High-Value API Credentials
- Content
View full analysis
Vulnerability Details
File Location:
README.md:60-62
Related Locations:SKILL.md:43;keys.env.template:2-14
Vulnerability Type: Plaintext sensitive-data storage
Risk Level: MediumVulnerable Code
README.md:60-62:text ## Sicherheit Keys liegen im Klartext (Browser-localStorage bzw. keys.env). Paket privat halten, Keys regelmäßig rotieren. Für Dauerbetrieb ablaufende Tokens (z. B. Tailscale) durch OAuth-Clients ersetzen.keys.env.template:2-14demonstrates the credentials intended for plaintext storage:dotenv # In keys.env umbenennen, Werte eintragen. Privat halten, regelmaessig rotieren. GH_REPO="owner/repo" GH_TOKEN="" VERCEL_TOKEN="" VERCEL_TEAM_ID="" VERCEL_PROJECT_ID="" DOCKER_NAMESPACE="" DOCKER_PAT="" OPENROUTER_API_KEY="" OPENAI_ADMIN_KEY="" CLAUDE_ADMIN_KEY="" TAILSCALE_TOKEN="" TAILSCALE_TAILNET="-" CLAWHUB_SLUGS=""Technical Analysis
The documented design persistently stores API credentials in browser
localStorageor an unencryptedkeys.envfile. These values can include organization-level OpenAI and Anthropic administrator keys, a Docker personal access token, a Tailscale token, and credentials capable of accessing private GitHub or Vercel resources.Browser
localStorageis accessible to any JavaScript executing within the same origin. If the dashboard is hosted alongside a compromised application, affected by script injection, or supplied with an untrusted third-party script, that script could read and transmit every stored token. The advertised dashboard file,tagesstatus-live-public.html, is absent from the audited package, so its origin isolation, content security policy, external script usage, and token-handling implementation could not be verified.A plaintext
keys.envfile can be disclosed through accidental source-control commits, insecure backups, permissive filesystem permissions, artifact packaging, log ...[truncated 2726 chars]- Remediation
View remediation
Remediation Suggestions
- Do not persist browser credentials by default. Keep tokens in memory for the current page session and clear them when the page closes or the report finishes.
- If browser persistence is retained, require explicit opt-in, clearly warn users about same-origin script access, and provide a prominent function to remove all stored credentials.
- Serve the dashboard from a dedicated, isolated origin containing no unrelated applications or user-controlled content.
- Apply a restrictive Content Security Policy and avoid third-party scripts, inline executable content, and dynamically imported remote code.
- Prefer a backend or CI worker that retrieves credentials from a managed secret store and returns only sanitized report data to the browser.
- Store CI credentials using the platform's protected secret mechanism rather than committing
keys.env. - Add
keys.envand equivalent secret-file patterns to.gitignore, and document verification withgit statusbefore commits. - Require restrictive file permissions, such as owner-only read/write access, for any local secret file.
- Use separate, narrowly scoped, read-only credentials for each provider. Avoid organization-admin keys unless the selected endpoint strictly requires them.
- Set short expiration periods where supported, rotate credentials regularly, and revoke them immediately after suspected exposure.
- Supply the missing dashboard HTML for review before recommending browser-based credential entry, so its storage behavior, network destinations, dependency usage, and origin protections can be validated.
