T09 · Insecure Skill Coding Practices
- Location
SKILL.md:20- Finding
API credentials and sensitive accounting data transmitted over unencrypted HTTP
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:20-40; corroborated byreferences/test-notes.md:3-19
Vulnerability Type: Cleartext transmission of authentication credentials and business data
Risk Level: HighVulnerable Code Snippet
markdown 1. Confirm the base URL, API name, and API key. 2. Use the headers: - `X-API-NAME: 9999` - `X-API-KEY: 9999` - `Content-Type: application/json` 3. Prefer `SaveAsDraft: true` unless the user explicitly wants final posting. 4. For transfer chains, the source document must be final (`SaveAsDraft: false`). Draft purchase documents cannot be used as transfer sources. 5. Prefer AutoCount defaults (`<<<Default>>>`) over guessed business values. 6. Do not hardcode tax codes. Use defaults or system-derived values only. 7. After each create call, fetch the created record and report the actual document number. ## Known API pattern Base URL example: - `http://your-autocount-host:9999` Headers example: ```http X-API-NAME: <your-api-name> X-API-KEY: <your-api-key> Content-Type: application/jsontext The reference notes explicitly confirm the insecure transport: ```markdown ## Environment observed - Base URL shape: `http://your-autocount-host:9999` - Protocol in the tested environment: HTTP on 9999, not HTTPS - Root path returned `404 Not Found` - Server header observed in testing: `Microsoft-HTTPAPI/2.0` ## Auth behavior - Basic auth failed - `APIKey`, `ApiKey` headers did not work - `X-API-KEY` triggered the next auth layer - Missing companion header error showed `X-API-Name is required` - Working auth shape: - `X-API-NAME: <your-api-name>` - `X-API-KEY: <your-api-key>`Technical Analysis
The Skill instructs the Agent to authenticate to an AutoCount Web API using
X-API-NAMEandX-API-KEYheaders while documenting an `http: ...[truncated 3508 chars]- Remediation
View remediation
Remediation Suggestions
- Require
https://API endpoints and reject plain HTTP by default, especially for non-loopback hosts. - If AutoCount does not support TLS directly, place it behind a properly configured TLS reverse proxy, VPN, or mutually authenticated secure tunnel.
- Validate TLS certificates and hostnames. Do not recommend disabling certificate verification.
- Replace the literal
X-API-NAME: 9999andX-API-KEY: 9999examples with unambiguous placeholders. - Obtain credentials from protected runtime secret storage or environment configuration rather than embedding them in Skill content, payload examples, logs, or generated commands.
- Redact authentication headers and sensitive accounting fields from logs, traces, error reports, and conversational output.
- Use dedicated, least-privilege API identities. Separate read-only inspection credentials from document-creation and destructive-operation credentials where the server supports it.
- Require explicit user confirmation immediately before update, cancellation, deletion, or final posting operations.
- Restrict server exposure with firewall allowlists and avoid exposing port
9999directly to untrusted networks. - Rotate any API credentials that have previously been transmitted over HTTP and review API or accounting logs for unauthorized access.
- Update
references/test-notes.mdto label the observed HTTP deployment as unsafe rather than presenting it as an acceptable operating configuration. - Add a preflight check that refuses insecure transport and reports clear instructions for enabling TLS.
- Require
