T09 · Insecure Skill Coding Practices
- Location
SKILL.md:91- Finding
Apify API Token Exposed Through URL Query Parameters
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is purpose-aligned for Apify-based Twitter/X profile scraping, but its documented REST examples handle the Apify token in an unsafe way and its broader graph-collection options deserve review before use.
Review this skill before installing if you will use real Apify credentials or sensitive account lists. Prefer an official Apify client, MCP server, or Authorization header instead of tokenized URLs; use a limited Apify token where possible, avoid sharing logs containing commands, and be clear that submitted handles, URLs, and scraped results are processed by Apify and may include follower/following or retweeter data if those options are enabled.
SKILL.md:91Apify API Token Exposed Through URL Query Parameters
The skill description does not clearly warn that it requires an APIFY_TOKEN and transmits requested Twitter/X account data to the external Apify service. This reduces informed consent and can cause users to submit handles or datasets without understanding third-party processing, credential use, and associated privacy/compliance implications.
The skill advertises account-level profile export, but its documented inputs also permit collection of follower lists, following lists, and retweeters, which materially expands the scope from simple profile metadata to relationship and engagement graph extraction. This mismatch can mislead users, reviewers, or downstream policy controls into approving broader data collection than intended.
This command sends user-supplied Twitter usernames to a third-party API and includes an authentication token in the request URL, creating external data exposure and increasing the chance of token leakage via shell history, logs, proxies, or monitoring tools. While external transmission is expected for this integration, the documentation does not sufficiently minimize credential exposure or warn about the privacy boundary.
REST API fallback:
curl -X POST \
"https://api.apify.com/v2/acts/apidojo~twitter-user-scraper/runs?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"usernames": ["handle1", "handle2"]}'
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
REST API fallback:
curl -X POST \
"https://api.apify.com/v2/acts/apidojo~twitter-user-scraper/runs?token=$APIFY_TOKEN" \
-H "Content-Type: application/json" \
-d '{"usernames": ["handle1", "handle2"]}'
The polling example performs another authenticated request with the token embedded in the query string, which repeats the credential exposure problem and reinforces a pattern of unsafe secret handling in documentation. Although polling run status is normal behavior, putting tokens in URLs can leak them through logs and observability systems.
Save id as RUN_ID. Poll until status = SUCCEEDED:
curl "https://api.apify.com/v2/actor-runs/$RUN_ID?token=$APIFY_TOKEN" | grep '"status"'
Fetch results:
The dataset fetch example transmits collected results through a third-party API using a token in the URL, exposing both the retrieved data and the credential to logging and history risks. Because output may include profile metadata and potentially broader scraped data depending on inputs, this can increase privacy and compliance exposure.
Fetch results:
curl "https://api.apify.com/v2/actor-runs/$RUN_ID/dataset/items?token=$APIFY_TOKEN&format=json"
No suspicious patterns detected.