T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:223
- Finding
- Unsafe Guidance Encourages Logging Unsanitized Sensitive Data## Vulnerability Details **File Location**: `SKILL.md`, lines 223–226 **Vulnerability Type**: Sensitive information exposure through insecure logging guidance **Risk Level**: Medium ### Vulnerable Code ```markdown - Include ALL context: user ID, request ID, timestamp, trace ID - Include exception type and stack trace - Structured (JSON) preferred - No sanitization — ops team needs raw details ``` ### Technical Analysis The Skill explicitly directs generated operational logs to include “ALL context” and states that no sanitization should be applied. Although operational logs need diagnostic context, exception messages, stack traces, and request-related data can contain credentials, authorization headers, session identifiers, personal data, request payloads, database values, internal paths, or infrastructure details. Secure logging should use an explicit allowlist of fields and redact sensitive values before they cross the logging boundary. The current blanket instruction can cause the agent to recommend unsafe logging implementations when rewriting application errors. The project contains documentation rather than executable code, so the disclosure is contingent on a user adopting the generated logging guidance. The Skill itself does not directly read or transmit secrets. ### Attack Path 1. An application processes a request containing sensitive information, such as an access token, session cookie, personal record, or payment-related value. 2. An exception incorporates that information into its message, stack trace, request context, or attached metadata. 3. A developer uses this Skill to generate operational logging code and follows its “Include ALL context” and “No sanitization” guidance. 4. The resulting application writes the sensitive information to local logs or forwards it to centralized logging and monitoring services. 5. An attacker, compromised monitoring integration, or overprivileged operator with log a ...[truncated 943 chars]
- Remediation
- ## Remediation Suggestions Replace the blanket logging instructions with secure, allowlist-based guidance: - Log only fields explicitly required for diagnosis. - Redact or omit passwords, API keys, access tokens, refresh tokens, cookies, authorization headers, cryptographic material, payment data, health data, and other regulated or personal information. - Prefer pseudonymous internal identifiers over email addresses, names, or other direct identifiers. - Do not log complete request or response bodies by default. - Sanitize exception messages and stack traces before forwarding them to shared or third-party logging systems. - Keep detailed stack traces in access-controlled diagnostic systems and disable them in user-facing responses. - Apply least-privilege access controls, encryption, retention limits, deletion policies, and audit trails to log storage. - Add automated tests or log-scanning controls that detect known secret formats and prohibited fields. A safer replacement would be: ```markdown - Include only allowlisted diagnostic fields, such as a timestamp, request ID, trace ID, operation name, and non-sensitive error code. - Redact credentials, tokens, cookies, personal data, payment data, request bodies, and sensitive exception values. - Include sanitized exception types and stack traces only in access-controlled diagnostic logs. - Use structured logging and enforce least-privilege access and retention limits. ```