T09 · Insecure Skill Coding Practices
- Location
SKILL.md:26- Finding
Permanent Unscoped Bearer Token Lacks Expiry and Self-Service Revocation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:26-28,SKILL.md:153-154, andSKILL.md:302-308
Vulnerability Type: Permanent, unscoped account credential with inadequate lifecycle controls
Risk Level: MediumEvidence
text The returned API key is permanent and grants account access. Store it only in secure credential storage, never in source code, plaintext configuration, logs, or conversation history.text Persist `apiKey` securely and reuse it as the Bearer token. Persist `personId` only as the account identifier. Do not persist `passKey`.text The protocol currently exposes no scoped keys, expiry, password-based protocol login, or self-service revocation. If the API key is unavailable, do not ask `/ask` to authenticate or recreate identity. Re-register only if the user intends to create a distinct new account. If a key may have been exposed, stop using it and contact [hello@blossomai.org](mailto:hello@blossomai.org) to rotate or revoke access.Technical Analysis
The Skill requires a permanent Bearer API key for all authenticated operations through
/ask. The key grants account access but has no documented expiration, restricted scope, automated rotation, or self-service revocation mechanism. Read operations and consequential marketplace mutations therefore rely on the same long-lived credential.Secure credential storage reduces the likelihood of disclosure but does not limit the consequences after disclosure. Because Bearer authentication treats possession as authority, an attacker who obtains the key can submit authenticated requests without an additional authentication factor. The absence of expiry allows continued use until the operator manually rotates or revokes the credential.
The network transmission itself is disclosed, limited to the declared Blossom HTTPS service, and generally necessary for the Skill's functionality. The weakness concerns crede ...[truncated 2008 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace permanent API keys with short-lived access tokens and securely rotated refresh tokens.
- Add self-service credential inventory, immediate revocation, and rotation controls without requiring support intervention.
- Scope tokens by capability, separating read access from role, address, application, and scheduling mutations.
- Use narrowly scoped, time-limited authorization for destructive or privacy-sensitive operations.
- Require recent user reauthorization or step-up authentication for deletion, application submission, address changes, and other consequential actions.
- Detect token reuse from anomalous devices, locations, or request patterns and automatically suspend suspicious credentials.
- Preserve the existing secure-storage requirements while explicitly preventing tokens from entering conversation history, telemetry, backups, crash reports, and diagnostic logs.
- Document a tested incident-response workflow that invalidates exposed tokens immediately and notifies affected users.
- Where compatibility requires long-lived keys, allow users to create multiple named keys with least-privilege scopes, expiration dates, last-used metadata, and independent revocation.
