T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/patents.sh:3
- Finding
- Hard-Coded SerpApi Credential Exposed and Transmitted in URL Query Strings<![CDATA[ ## Vulnerability Details **File Location**: `scripts/patents.sh:3`, with credential transmission at lines 78, 97, 102, 114, and 134 **Vulnerability Type**: Hard-coded secret and insecure credential transmission in URL query parameters **Risk Level**: High ### Vulnerable Code ```bash API_KEY="${SERPAPI_API_KEY:-640dcea4484043e8b12c389a19c0354bd6ac2e396b42ba46d76ef69006d805f2}" ``` The credential is subsequently inserted into request URLs, including: ```bash params="engine=google_patents&q=$(urlencode "$query")&api_key=$API_KEY" ``` ```bash fetch_with_retry "$BASE?engine=google_patents_details&patent_id=$(urlencode "$(normalize_id "$1")")&api_key=$API_KEY" ``` ```bash detail_json=$(fetch_with_retry "$BASE?engine=google_patents_details&patent_id=$(urlencode "$(normalize_id "$1")")&api_key=$API_KEY") ``` ```bash detail_json=$(fetch_with_retry "$BASE?engine=google_patents_details&patent_id=$(urlencode "$pid")&api_key=$API_KEY") ``` ### Technical Analysis The script embeds a reusable, live-looking SerpApi key as the fallback value when `SERPAPI_API_KEY` is unset. Anyone who can read the Skill package can extract this key without authorization. The credential is not needed as a bundled default: the documented functionality can instead require each operator to supply their own key. The script also places the credential in URL query parameters. Although the destination uses HTTPS, query-string secrets may still be exposed through local process inspection while `curl` runs, command tracing, diagnostic output, monitoring systems, proxies, or server-side URL logs. HTTPS protects the URL in transit from passive network observers but does not prevent disclosure at either endpoint or through local runtime metadata. The patent search query or patent identifier is also sent to the declared SerpApi service. This network transfer is necessary for the advertised third-party patent-search functionality and is not covert data exfiltration. Nevertheless, potenti ...[truncated 2237 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Immediately revoke or rotate the embedded SerpApi key and review its account usage for unauthorized requests. 2. Remove the fallback value and require an explicitly supplied environment variable: ```bash if [ -z "${SERPAPI_API_KEY:-}" ]; then error_json "SERPAPI_API_KEY is required" "AUTH_ERROR" exit 1 fi API_KEY="$SERPAPI_API_KEY" ``` 3. Use an authorization header instead of a query parameter if SerpApi supports one. If the provider requires `api_key` in the URL, document that limitation and reduce local exposure through restricted execution environments and disabled shell tracing. 4. Never print, log, or include the complete credential in error messages. Redact it from diagnostics and telemetry. 5. Add automated secret scanning to the repository and release process to prevent future committed credentials. 6. Use separate, least-privileged credentials for development, testing, and production, with restrictive quotas and billing limits. 7. Document that patent queries and identifiers are transmitted to SerpApi so users can avoid submitting confidential research terms without informed consent. 8. Consider passing request parameters through `curl --get --data-urlencode` for consistent encoding, while recognizing that this alone does not remove query-string credential exposure. ]]>