T09 · Insecure Skill Coding Practices
- Location
SKILL.md:85- Finding
Apify API Token Transmitted in URL Query Parameters
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 85-97
Vulnerability Type: Credential exposure through URL query parameters
Risk Level: MediumVulnerable Code
bash curl -X POST \ "https://api.apify.com/v2/acts/apidojo~twitter-list-scraper/runs?token=$APIFY_TOKEN" \ -H "Content-Type: application/json" \ -d '{"listUrl": "https://twitter.com/i/lists/<LIST_ID>"}'bash curl "https://api.apify.com/v2/actor-runs/$RUN_ID?token=$APIFY_TOKEN" | grep '"status"'bash curl "https://api.apify.com/v2/actor-runs/$RUN_ID/dataset/items?token=$APIFY_TOKEN&format=json"Technical Analysis
The documented REST fallback authenticates to Apify by placing
APIFY_TOKENin URL query parameters. Authentication is necessary for the Skill's declared functionality, but including a reusable secret in a URL is not the minimum-risk authentication mechanism.After environment-variable expansion, the token becomes part of the complete URL supplied to
curl. Credential-bearing URLs can be exposed through process inspection while the command is running, verbose client diagnostics, proxy and gateway logs, monitoring telemetry, error reports, or other systems that record request URLs. The commands use HTTPS, which protects the request in transit from ordinary passive interception, but it does not prevent disclosure at the endpoint or through local and intermediary metadata collection.The network destination is the expected Apify API, and the audit found no evidence that the token is intentionally sent to an unrelated domain. The vulnerability is therefore insecure credential handling rather than unauthorized exfiltration.
Attack Path
- A user configures a valid
APIFY_TOKENand follows the documented REST fallback. - The shell expands
$APIFY_TOKEN, embedding the reusable credential in the URL passed tocurl. - A local process observer, diagnostic system, proxy, gateway, telemetry platform, or URL-logging compone ...[truncated 924 chars]
- A user configures a valid
- Remediation
View remediation
Remediation Suggestions
- Remove
token=$APIFY_TOKENfrom every Apify API URL. - Pass the credential through an authorization header supported by Apify, for example:
bash curl -X POST \ "https://api.apify.com/v2/acts/apidojo~twitter-list-scraper/runs" \ -H "Authorization: Bearer $APIFY_TOKEN" \ -H "Content-Type: application/json" \ -d '{"listUrl": "https://twitter.com/i/lists/<LIST_ID>"}'- Apply the same header-based authentication to polling and dataset retrieval:
bash curl \ -H "Authorization: Bearer $APIFY_TOKEN" \ "https://api.apify.com/v2/actor-runs/$RUN_ID"bash curl \ -H "Authorization: Bearer $APIFY_TOKEN" \ "https://api.apify.com/v2/actor-runs/$RUN_ID/dataset/items?format=json"- Use a narrowly scoped Apify token that grants only the permissions required to execute the specified actor and retrieve its results.
- Avoid logging request headers and redact authorization values from diagnostics, command traces, and error reports.
- Document token rotation and revocation procedures. Rotate any token suspected of having appeared in URL, proxy, telemetry, or diagnostic logs.
- Review the referenced
scripts/run_actor.jsbefore distributing it. That file was absent from the audited project, so its credential handling and output behavior could not be verified.
- Remove
