T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:52
- Finding
- Hard-Coded Static Baserow API Token<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 52-57 **Vulnerability Type**: Hard-coded credential and plaintext secret exposure **Risk Level**: High ### Vulnerable Code ```text The `.env` file **must** use real newlines between vars, NOT `\n` literals: BASEROW_BASE_URL="https://baserow.ericbone.me" BASEROW_TOKEN="<REDACTED_EXPOSED_PERSONAL_API_TOKEN>" ``` The token value is redacted in this report to avoid further disclosure. The reviewed file contains the complete plaintext credential. ### Technical Analysis The Skill embeds a concrete, real-looking personal Baserow API token in its documentation. The preceding authentication guidance describes this token as static and non-expiring. A credential stored in a distributable Skill file can be recovered by anyone with access to the package, source archive, logs, or agent context. Embedding this credential is not required for the declared Baserow CRUD functionality. The Skill metadata already declares `BASEROW_TOKEN` as a required environment variable, so the documentation should contain only a placeholder. Because the same file documents the target service, authentication header, table identifiers, and API routes, the exposed token is immediately actionable. ### Attack Path 1. An attacker obtains or reads the Skill package. 2. The attacker extracts the plaintext token from `SKILL.md`. 3. The attacker sends requests to the documented Baserow API using: ```http Authorization: Token <extracted-token> ``` 4. The attacker enumerates, reads, creates, or modifies rows accessible to that token. 5. Because the token is described as static and without expiry, access may continue until the token is explicitly revoked. ### Impact Assessment An attacker can obtain the same Baserow privileges granted to the exposed personal API token. The exact server-side permission scope is not established by the reviewed file, but it may include unauthorized access to or modification of CRM contact ...[truncated 245 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed token immediately; removing it from the current file is insufficient if copies or repository history exist. 2. Search package archives, version-control history, logs, prompts, and generated artifacts for the exposed value and purge it where feasible. 3. Replace the token in documentation with a non-secret placeholder: ```text BASEROW_TOKEN="<your-baserow-api-token>" ``` 4. Supply credentials exclusively through a protected secret manager or runtime environment injection. 5. Use a dedicated service credential instead of a personal token. 6. Restrict the replacement credential to only the required database and CRUD operations. 7. Prefer an expiring or regularly rotated credential where the service supports it. 8. Add automated secret scanning to prevent credentials from being committed or packaged again. ]]>