T09 · Insecure Skill Coding Practices
- Location
SKILL.md:52- Finding
Configurable API Destination Can Expose the Praesidia Bearer Token
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:21-40, 52-58and equivalent guidance inREADME.md:70-97, 121-122, 149-208
Vulnerability Type: Credential disclosure through an unrestricted network destination
Risk Level: HighVulnerable Code
json { "skills": { "entries": { "praesidia": { "apiKey": "pk_live_your_key_here", "env": { "PRAESIDIA_API_URL": "https://api.praesidia.ai" } } } } }The documentation explicitly permits non-TLS and custom destinations:
markdown For local development, use `http://localhost:3000` as the URL.The configured destination is then used in an authenticated request:
javascript web_fetch({ url: "${PRAESIDIA_API_URL}/agents/chatbot-v2/agent-card", headers: { "Authorization": "Bearer ${PRAESIDIA_API_KEY}", "Accept": "application/json" } })Technical Analysis
PRAESIDIA_API_URLcontrols the destination receiving theAuthorizationheader. The Skill does not require HTTPS, restrict authenticated requests to an approved hostname, validate redirect destinations, or warn that a custom deployment receives the configured bearer credential.Custom deployments are a declared feature and may be legitimate. However, attaching a sensitive bearer token to an unrestricted endpoint creates a credential-exfiltration boundary. A configuration mistake, compromised configuration, malicious support instruction, or attacker-controlled custom endpoint can receive the token. Permitting HTTP further allows interception or modification of requests when the endpoint is not strictly loopback-only.
This behavior exceeds safe minimum privilege because public agent discovery does not require authentication, while the Skill notes that authorization may nevertheless be included for additional results. Credentials should only be sent when an operation actually requires th ...[truncated 1546 chars]
- Remediation
View remediation
Remediation Suggestions
- Allow authenticated production requests only to an explicit HTTPS hostname allowlist, defaulting to
https://api.praesidia.ai. - Treat custom deployments as a separate, explicit trust decision. Display the destination and obtain confirmation before sending a credential to a new host.
- Require HTTPS for every non-loopback destination. Permit HTTP only when the parsed hostname is exactly a recognized loopback address such as
localhost,127.0.0.1, or::1. - Validate the final parsed scheme and hostname rather than relying on string prefixes.
- Disable cross-origin redirects for authenticated requests, or strip the
Authorizationheader whenever a redirect changes scheme, hostname, or port. - Do not include authorization on public discovery calls unless authenticated results are specifically required.
- Use separately scoped credentials for production and custom development deployments. Never reuse a production key with a local or third-party endpoint.
- Document clearly that a custom endpoint receives the bearer token and may receive private organization data.
- Support short-lived, least-privilege tokens with separate read-only and guardrail-management scopes.
- Revoke and rotate any key suspected of having been sent to an untrusted endpoint.
- Allow authenticated production requests only to an explicit HTTPS hostname allowlist, defaulting to