T09 · Insecure Skill Coding Practices
- Location
SKILL.md:48- 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
The skill matches its stated scraping purpose, but it uses broad triggers and insecure Apify token examples that deserve review before installation.
Install only if you intend to use Apify for Google Maps scraping. Use a narrowly scoped Apify token if available, avoid copying the token-in-URL examples, prefer authorization headers, and treat email scraping as an explicit opt-in because it causes automated visits to business websites and sends your target queries or URLs to a third-party actor.
SKILL.md:48Apify API Token Exposed Through URL Query Parameters
The trigger phrases are broad enough to match ordinary recommendation-style requests such as 'find restaurants near me' or 'get local business info', which could cause the skill to activate when the user likely wanted conversational assistance rather than automated scraping. In this context, misrouting is risky because the skill sends queries to a third-party service and can perform website/email scraping without an explicit user intent check.
The skill advertises extraction of emails from business websites but does not clearly warn that user-supplied queries and target URLs will be transmitted to Apify and that the actor may visit third-party business websites. That lack of disclosure increases the chance of unintended data sharing and user surprise, especially for ambiguous prompts that do not explicitly ask for scraping.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
import requests, os, time
TOKEN = os.environ["APIFY_API_TOKEN"]
BASE = "https://api.apify.com/v2"
# Step 1: Start the run
response = requests.post(
This code sends user-provided search queries and configuration to an external third-party API, which is an external data transmission channel. In this skill, that behavior is expected, but it is still security-relevant because ambiguous requests could cause unintended disclosure of user interests, locations, or target lists to Apify.
BASE = "https://api.apify.com/v2"
# Step 1: Start the run
response = requests.post(
f"{BASE}/acts/futurizerush~google-maps-scraper/runs?token={TOKEN}",
json={
"searchQueries": ["coffee shop taipei"],
This example transmits direct Google Maps URLs to Apify, potentially including user-selected places or searches, to a third-party actor. While functionally necessary for the skill, it becomes dangerous when users are not clearly informed that their supplied URLs and associated targets are being processed outside the local environment.
requests.post(
f"{BASE}/acts/futurizerush~google-maps-scraper/runs?token={TOKEN}",
json={
"startUrls": [
This example batches multiple search queries into a single third-party request, increasing the amount of user-specified targeting data disclosed externally. The risk is amplified because the skill is designed for lead-generation-style collection, including possible downstream website scraping for emails.
requests.post(
f"{BASE}/acts/futurizerush~google-maps-scraper/runs?token={TOKEN}",
json={
"searchQueries": ["dentist new york", "lawyer new york", "accountant new york"],
The bash example performs the same third-party transmission using curl and includes the API token in the URL query string, which can be exposed in shell history, logs, process listings, or proxy logs. Even though this is sample code, normalizing token-in-URL usage increases credential leakage risk.
# Step 1: Start the run
RUN_RESPONSE=$(curl -s -X POST \
"https://api.apify.com/v2/acts/futurizerush~google-maps-scraper/runs?token=$APIFY_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"searchQueries": ["coffee shop taipei"], "maxResults": 50, "language": "en", "scrapeEmails": true}')
This bash invocation sends requests to Apify with the API token embedded directly in the request URL, creating a concrete credential exposure risk through logs, browser history equivalents, telemetry, and copied command output. In addition to external transmission, this is a poor secret-handling pattern in a skill intended for reuse.
# Step 1: Start the run
RUN_RESPONSE=$(curl -s -X POST \
"https://api.apify.com/v2/acts/futurizerush~google-maps-scraper/runs?token=$APIFY_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"searchQueries": ["coffee shop taipei"], "maxResults": 50, "language": "en", "scrapeEmails": true}')
The polling request again places the API token in the URL, repeating the credential leakage pattern and increasing exposure frequency across repeated status checks. Repeated authenticated polling also broadens the operational footprint in logs and monitoring systems.
# Step 2: Poll until done
while true; do
STATUS=$(curl -s "https://api.apify.com/v2/actor-runs/$RUN_ID?token=$APIFY_API_TOKEN" \
| jq -r '.data.status')
[ "$STATUS" = "SUCCEEDED" ] && break
[ "$STATUS" = "FAILED" ] || [ "$STATUS" = "ABORTED" ] && echo "Failed: $STATUS" && exit 1
Fetching dataset results with the token in the URL continues the same credential exposure issue and may additionally expose access to scraped result sets if URLs are logged or shared. Because result retrieval is likely to be copied into automation, this insecure example can propagate widely.
done
curl -s "https://api.apify.com/v2/datasets/$DATASET_ID/items?token=$APIFY_API_TOKEN" | jq '.'
## Output Format
No suspicious patterns detected.