T09 · Insecure Skill Coding Practices
- Location
scripts/post.mjs:20- Finding
Hard-Coded Shared API Credential
- Content
View full analysis
Vulnerability Details
File Location:
scripts/post.mjs, lines 20–27
Vulnerability Type: Hard-coded reusable API secret
Risk Level: HighVulnerable Code
js const API_KEY = 'quack_5c6786fb7ac8f08c638d5db176d60b12b906b78ac63d21cf'; const url = 'https://vibepost-jpaulgrayson.replit.app/api/quack/post'; const res = await fetch(url, { method: 'POST', headers: { 'x-quack-api-key': API_KEY, 'Content-Type': 'application/json', },Technical Analysis
A live-looking, reusable API key is embedded directly in distributable source code and sent in the
x-quack-api-keyheader to a third-party Replit-hosted endpoint. Anyone who can access the Skill package can extract this credential without executing the script.Sending user-supplied post text to the documented VibePost endpoint is necessary for the Skill's declared social-posting function. Embedding and distributing a shared credential is not necessary, however, and violates least-privilege and secure secret-management principles. The shared key also prevents reliable attribution and isolation between users.
Attack Path
- Obtain or inspect the distributed Skill package.
- Open
scripts/post.mjsand extract the API key from line 20. - Construct an independent HTTP request to the documented endpoint.
- Place the extracted key in the
x-quack-api-keyheader. - Submit attacker-controlled text and platform values.
- If the server accepts the shared credential, perform posting operations or consume service resources outside the intended Skill workflow.
Impact Assessment
Successful exploitation may permit unauthorized posting, impersonation, quota consumption, service abuse, and loss of accountability between Skill users. The accessible scope is limited to the permissions granted to the exposed API key and the operations accepted by the remote endpoint; the audited source does not establish any broader system pr ...[truncated 285 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed API key immediately.
- Remove the credential from source code and repository history.
- Obtain a user-specific credential from a protected environment variable or secret manager at runtime.
- Fail safely with a clear error when no credential is configured; do not provide a shared fallback key.
- Issue narrowly scoped, short-lived credentials where supported.
- Enforce per-user authorization, posting limits, rate limits, auditing, and credential revocation on the backend.
- Prevent recurrence with secret-scanning checks in version control and CI.
- Avoid logging credentials or including them in error messages.
