T09 · Insecure Skill Coding Practices
- Location
SKILL.md:600- Finding
Unredacted Personally Identifiable Information in Security Logs
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:600-610
Vulnerability Type: Sensitive data exposure through insecure logging
Risk Level: Mediumjavascript function logSecurityEvent(event, details) { logger.warn({ type: 'security', event, ...details, timestamp: new Date().toISOString() }); } // Usage in auth middleware logSecurityEvent('login_failed', { email: req.body.email, ip: req.ip });Technical Analysis
The recommended security-logging function spreads the arbitrary
detailsobject directly into a log record without an allowlist, redaction, validation, or pseudonymization. Its example invocation explicitly records a user's email address and full IP address, both of which may constitute personally identifiable information.This implementation contradicts the Skill's own guidance to exclude PII from logs. Because the logger may write to local files, centralized observability services, or third-party logging backends, the pattern can propagate sensitive information into systems with broader access and longer retention than the primary application database.
The generic object spread also makes future misuse likely: callers can unintentionally include authorization tokens, passwords, session identifiers, request bodies, or other secrets.
Attack Path
- An attacker submits a failed login attempt containing a targeted or attacker-controlled email address.
- The authentication handler reads the email from
req.body.emailand the source address fromreq.ip. - Both values are passed to
logSecurityEvent. - The function expands the values into the log record without redaction.
- PII is stored locally or forwarded through the application's configured logging transport.
- A user, service, or compromised account with access to the logging system can retrieve the exposed data.
Impact Assessment
The issue does not itself grant execution privileges or application authorization. Its impact is unauth ...[truncated 314 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not log raw email addresses or full IP addresses unless a documented security requirement makes them indispensable.
- Replace the arbitrary
...detailsexpansion with an explicit allowlist of approved fields. - Pseudonymize user identifiers using a keyed cryptographic hash when event correlation is required.
- Truncate or otherwise anonymize IP addresses where full addresses are unnecessary.
- Configure logger-level redaction for passwords, authorization headers, cookies, access and refresh tokens, session identifiers, and common PII fields.
- Validate and normalize all security-event data before recording it.
- Prohibit callers from passing request objects, response objects, request bodies, headers, or arbitrary nested objects.
- Apply least-privilege access controls, encryption, retention limits, and audit trails to all log storage and aggregation systems.
- Add automated tests verifying that sensitive fields cannot appear in serialized log records.
A safer design should accept a narrowly defined event schema rather than arbitrary details, for example:
javascript function logSecurityEvent({ event, subjectIdHash, ipPrefix, path }) { logger.warn({ type: 'security', event, subjectIdHash, ipPrefix, path, timestamp: new Date().toISOString() }); }