T09 · Insecure Skill Coding Practices
- Location
index.js:1- Finding
Hard-Coded Agent Token and Plaintext Transmission of Sensitive Data
- Content
View full analysis
Vulnerability Details
File Location:
index.js, lines 1–15
Vulnerability Type: Hard-coded credential and plaintext transmission of authentication and contact data
Risk Level: MediumVulnerable Code
js const BACKEND_URL = "http://localhost:8001/api/v1/agent"; const AGENT_TOKEN = "sk_agent_openclaw_dev_12345"; export default { name: "telegram_analyzer", tools: { search_contacts: { description: "Search for contacts in SaaS", parameters: { type: "object", properties: { query: { type: "string" } }, required: ["query"] }, execute: async ({ query }) => { const res = await fetch(${BACKEND_URL}/search-contacts, { method: "POST", headers: { "Content-Type": "application/json", "X-Agent-Token": AGENT_TOKEN }, body: JSON.stringify({ query }) });Technical Analysis
The skill embeds an agent authentication token directly in distributable source code. Anyone able to read the package can recover the token without needing to compromise a protected credential store.
The intended request also uses unencrypted HTTP and places the token in the
X-Agent-Tokenheader. The request body may contain sensitive contact identifiers, names, phone numbers, or usernames supplied as search terms. Although the configured destination islocalhost, plaintext transport still permits a malicious or compromised local service listening on port8001to collect both the credential and search data. The risk increases if the local service is forwarded, proxied, containerized with a shared network boundary, or accidentally exposed beyond the host.Authentication is reasonably necessary for the declared contact-search function, and transmitting a search term to the relevant backend is inherent to that operation. However, embedding a reusable credential in source code and transmitting it over plaintext HTTP exceed the minimum safe privileges and pro ...[truncated 2074 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the embedded agent token, including any identical token used in development or deployed environments.
- Remove credentials from source code. Inject the token at runtime through a protected secret manager or narrowly scoped environment variable.
- Assign a unique, short-lived token to each deployment and restrict it to the exact API route and operation required for contact search.
- Replace plaintext HTTP with HTTPS using certificate validation. If the backend is strictly local, prefer authenticated operating-system IPC such as a Unix domain socket with restrictive filesystem permissions.
- Ensure the backend binds only to the required interface and is not exposed through container port publishing, reverse proxies, or development tunnels.
- Authenticate the backend endpoint rather than trusting
localhost. Where appropriate, use mutual TLS, signed requests, or peer-credential validation. - Minimize submitted contact information, validate the
queryinput, and avoid logging tokens or raw contact-search terms. - Correct the invalid
fetchURL syntax only after the credential and transport controls are remediated, for example by constructing the URL through a validated URL API. - Add automated secret scanning and tests that reject hard-coded credentials and non-TLS endpoints before release.