T09 · Insecure Skill Coding Practices
- Location
SKILL.md:16- Finding
Potential Clicky API Credential Embedded in Documentation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly does what it claims, but it publishes realistic Clicky API credentials in its documentation and handles site keys in URL query strings.
Review this before installing. Replace the documented Clicky site IDs and site keys with placeholders, rotate them if they were ever real, and only store your own Clicky credentials in protected environment variables. Use the skill only for Clicky analytics requests and be aware that each invocation sends the configured site key and requested analytics parameters to Clicky's API.
SKILL.md:16Potential Clicky API Credential Embedded in Documentation
scripts/clicky.sh:54Clicky API Secret Exposed Through a Command-Line URL
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Store site credentials as environment variables. Use the naming convention CLICKY_<NAME>_SITE_ID and CLICKY_<NAME>_SITEKEY:
# In ~/.openclaw/.env or your shell profile
CLICKY_ENVELOPEBUDGET_SITE_ID=101427673
CLICKY_ENVELOPEBUDGET_SITEKEY=c287a01cc00f70cb
CLICKY_ZAPYETI_SITE_ID=99999999
The skill advertises shell-based usage (scripts/clicky.sh ...) but does not declare an explicit tool scope such as allowed shell commands or permissions. That creates ambiguity about what command execution the agent may perform when the skill is invoked, increasing the risk of unintended or overly broad shell access.
The description includes broad activation cues like website traffic, visitors, pageviews, top pages, traffic sources, and scheduled reports, which could cause the skill to trigger for generic analytics requests not clearly intended for Clicky. Over-broad triggering is dangerous because it may steer user requests into a shell/API-capable skill unnecessarily, expanding exposure to credentials and external actions.
The setup section shows full-looking site IDs and site keys in plaintext without marking them as placeholders or warning against committing real secrets. Even if illustrative, publishing realistic credentials normalizes unsafe secret handling and increases the chance users will copy, paste, store, or expose actual API keys in docs, chat, or repositories.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Or for default: CLICKY_SITE_ID + CLICKY_SITEKEY
set -euo pipefail
API_URL="https://api.clicky.com/api/stats/4"
SITE_NAME="${1:?Usage: clicky.sh <site_name> <type> [--date DATE] [--limit N] [--daily]}"
shift
The script constructs a URL containing the Clicky site ID and sitekey, then sends it via curl. Although comments mention that credentials come from environment variables, there is no user-facing prompt, logging, or warning that sensitive credentials and query parameters will be transmitted to an external API.