T09 · Insecure Skill Coding Practices
- Location
reference/auth.md:65- Finding
Insecure Persistence and Transmission of Cloud189 Access Tokens
- Content
View full analysis
Vulnerability Details
File Location:
reference/auth.md, lines 65–70 and 85–87
Vulnerability Type: Plaintext credential storage and exposure through URL parameters
Risk Level: MediumVulnerable Documentation
Lines 65–70 instruct the agent to persist the access token in memory or a configuration file:
text After successfully obtaining the accessToken, save it in the user's memory or configuration file so that it can be used for subsequent cloud API calls. Recommended storage methods: - Save the accessToken as an environment variable or project configuration.Lines 85–87 also document passing the token as a URL query parameter:
text Or in the request parameters: ?accessToken={accessToken}Technical Analysis
The access token is a bearer credential that authorizes Cloud189 API operations. The Skill recommends storing it in an environment variable or project configuration without requiring a managed secret store, restrictive file permissions, encryption, log redaction, or exclusion from version control.
Project configuration files can be committed to source control, included in backups, copied into build artifacts, or exposed to other users and processes. Environment variables may also be readable through process inspection, diagnostic output, crash reports, or CI/CD logs.
Passing the token in a URL query parameter creates an additional exposure path. URLs may be recorded in browser history, proxy and server access logs, monitoring platforms, debugging output, referrer data, and copied command histories.
Attack Path
- A user completes the documented OAuth2 flow and supplies an authorization code.
- The Skill exchanges that code for a Cloud189 access token.
- Following the documentation, the agent stores the bearer token in a project configuration file or environment variable without dedicated secret protections.
- Alternatively, the token is included in a URL q ...[truncated 1182 chars]
- Remediation
View remediation
Remediation Suggestions
-
Keep access tokens in memory only when persistence is not necessary.
-
If persistence is required, use an operating-system keychain, credential manager, or managed secret-storage service rather than a project configuration file.
-
Never store tokens in source-controlled files. Add any local secret files to
.gitignoreand provide only placeholder-based configuration templates. -
Apply restrictive filesystem permissions so that only the intended user or service account can read persisted credentials.
-
Remove the recommendation to transmit access tokens in URL query parameters. Require the following header instead:
http Authorization: Bearer {accessToken} -
Redact authorization codes, access tokens, signed download URLs, and other bearer credentials from console output, application logs, error messages, telemetry, and audit traces.
-
Avoid exposing complete tokens in user-facing responses. Display only a short masked fingerprint when confirmation is necessary.
-
Document token expiration and revocation procedures, and request the narrowest available authorization scope.
-
Ensure temporary credential material is deleted after use and is not included in backups, crash reports, command histories, or generated artifacts.
-