T09 · Insecure Skill Coding Practices
- Location
SKILL.md:114- Finding
State-Changing API Request Used as an Authentication Connectivity Check
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 114–121
Vulnerability Type: Unsafe authenticated API operation
Risk Level: Mediumbash curl -X POST https://api.remix.gg/v1/agents/games \ -H "Authorization: Bearer $REMIX_API_KEY" \ -H "Content-Type: application/json"The subsequent instruction identifies this
POST /v1/agents/gamesoperation as a low-cost authentication connectivity check and treats a 2xx response as proof that authentication works.Technical Analysis
The Skill instructs the Agent to transmit
REMIX_API_KEYto the declared Remix API service and execute an authenticated POST request. Sending the bearer credential to the intended API host over HTTPS is necessary for authenticated access and is not, by itself, evidence of credential exfiltration.The security issue is the selection of a potentially state-changing POST operation for a connectivity test. POST requests commonly create resources or trigger server-side actions. The Skill does not establish that this endpoint is read-only or idempotent and does not provide a request body, dry-run option, idempotency key, test-resource isolation, user confirmation, expected side effects, or cleanup procedure.
A connectivity check should use a documented read-only identity, status, permissions, or health endpoint whenever one is available. Using a mutation-capable endpoint exceeds the minimum behavior necessary to determine whether a key is valid.
Attack Path
- A user configures a valid
REMIX_API_KEYin the Agent environment. - The user or Agent invokes the Skill's documented connectivity self-check.
- The Agent reads the key and includes it in the Authorization header.
- The Agent sends an authenticated POST request to
https://api.remix.gg/v1/agents/games. - If the endpoint performs a mutation, the request may create or modify an account resource instead of merely checking authentication.
- Repeated trouble ...[truncated 695 chars]
- A user configures a valid
- Remediation
View remediation
Remediation Suggestions
- Replace the POST request with a documented read-only endpoint, such as an identity, permissions, account-status, or authentication-introspection endpoint.
- Verify and document the endpoint's exact semantics rather than assuming that a successful POST is side-effect free.
- If no read-only endpoint exists, require explicit user confirmation before executing the POST and clearly describe every possible server-side effect.
- Use a dedicated test key with only the minimum permissions required for the validation operation.
- Isolate checks to a designated test project or resource and provide a reliable cleanup procedure.
- Add an idempotency key or dry-run parameter if the API supports one.
- Validate that
REMIX_API_KEYis present before sending the request, while ensuring that the key and full Authorization header are never printed in logs or error messages. - Document the expected request body, response codes, quota cost, retry policy, and whether retries can duplicate mutations.
- Pin the instructions to a documented API version and revalidate the behavior when the remote API documentation changes.