T09 · Insecure Skill Coding Practices
- Location
SKILL.md:48- Finding
API Authentication Token Permitted in URL Query String
- Content
View full analysis
` or `X-API-Key`, or `?access_token=` ``` ### Technical Analysis The Skill explicitly permits an API credential to be supplied through the `access_token` URL query parameter. Query strings are routinely retained by infrastructure outside the application's direct control, including: - Browser history and bookmarked URLs - Reverse-proxy and web-server access logs - Monitoring, tracing, and analytics systems - Network security appliances - Screenshots, copied links, and support diagnostics - Referrer data in configurations without a sufficiently restrictive referrer policy The service already supports `Authorization: Bearer` and `X-API-Key` headers. Consequently, query-string authentication is unnecessary and creates additional exposure without being required for the declared browser-automation functionality. Because the token identifies the user and authorizes access to remote browser sessions, disclosure may expose more than a single request. Depending on server-side authorization and token scope, it may enable access to live sessions, stored sessions, browser screenshots, extracted page content, and persisted browser state. ### Attack Path 1. A user or agent follows the documented authentication option and constructs a URL containing `?access_token=`. 2. The full URL is recorded in browser history, proxy logs, tracing data, or another telemetry system. 3. An attacker gains read access to one of those records or receives a copied URL. 4. The attacker extracts the token from the query string. 5. The attacker presents the token to the remote browser service. 6. If the token remains valid, the attacker accesses API resources available to the affected user, including potentially sensitive browse ...[truncated 604 chars]- Remediation
View remediation
` authentication method. 2. Require credentials to be sent through `Authorization: Bearer` or a dedicated authentication header. 3. Reject query-string credentials at the server rather than merely discouraging them in documentation. 4. Configure servers, proxies, observability systems, and application logs to redact authentication headers and known credential parameters. 5. Rotate any token that has previously been transmitted in a URL. 6. Use short-lived, narrowly scoped tokens and support immediate revocation. 7. Apply strict referrer controls as defense in depth, while recognizing that this does not make URL credentials safe. ]]>
