T09 · Insecure Skill Coding Practices
- Location
SKILL.md:29- Finding
Webhook Authentication Token Exposed in URL Path
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 29 and 51
Vulnerability Type: Credential exposure through URL and command-line arguments
Risk Level: MediumThe skill instructs users to embed the personal
NANO_DIARY_HOOK_TOKENdirectly in the webhook URL:text POST https://image.yezishop.vip/api/diary-hook/${NANO_DIARY_HOOK_TOKEN}The same insecure pattern appears in the executable example:
bash curl -X POST "https://image.yezishop.vip/api/diary-hook/${NANO_DIARY_HOOK_TOKEN}" \ -H "Content-Type: application/json" \ -d '{"date": "2026-03-06", "content": "Today I learned how to publish OpenClaw skills to ClawHub."}'Technical Analysis
Placing an authentication token in a URL path increases its exposure even when HTTPS is used. TLS protects the request while it is in transit, but does not prevent the complete URL from being recorded at either endpoint or on the originating system.
Potential exposure locations include:
- Shell history containing the expanded command.
- Process inspection and command-line telemetry while
curlis running. - Web-server and reverse-proxy access logs.
- API gateway, load balancer, monitoring, tracing, and error-reporting systems.
- Diagnostic output or support records that capture request URLs.
A URL-path token may therefore become accessible to users or services that are permitted to inspect operational logs but are not authorized to modify the diary. Authentication credentials should instead be transmitted in a dedicated authorization header and redacted by default from telemetry.
Attack Path
- A user or agent runs the documented
curlcommand withNANO_DIARY_HOOK_TOKENexpanded in the URL. - The complete command or request URL is retained in shell history, process telemetry, access logs, proxy logs, or observability data.
- An attacker or insufficiently privileged operator obtains read access to one of those records. ...[truncated 1189 chars]
- Remediation
View remediation
Remediation Suggestions
-
Redesign the API to accept the token in an authorization header, for example:
bash curl -X POST "https://image.yezishop.vip/api/diary-hook" \ -H "Authorization: Bearer ${NANO_DIARY_HOOK_TOKEN}" \ -H "Content-Type: application/json" \ --data '{"date":"2026-03-06","content":"Today I learned how to publish OpenClaw skills to ClawHub."}' -
Configure servers, reverse proxies, API gateways, and observability systems to redact authorization data and any legacy token-bearing URL paths.
-
Disable the URL-token form after a documented migration period rather than supporting both forms indefinitely.
-
Rotate tokens that may already have appeared in shell history or infrastructure logs, and provide users with clear revocation and regeneration procedures.
-
Apply least privilege to webhook tokens and rate-limit requests. Where practical, restrict each token to diary-submission operations only.
-
Avoid logging complete request URLs and command lines. Review retention and access controls for existing logs, traces, and shell histories.
-
Update
SKILL.mdso that all endpoint descriptions and examples use the safer header-based authentication mechanism.
-
