T09 · Insecure Skill Coding Practices
Error
- Location
- rules/server-after-nonblocking.md:46
- Finding
- Raw Session Cookie Disclosed to an Unspecified Logging or Analytics Sink<![CDATA[ ## Vulnerability Details **File Location**: `rules/server-after-nonblocking.md:46-48` **Duplicate Location**: `AGENTS.md:1048-1050` **Vulnerability Type**: Sensitive authentication data exposure **Risk Level**: High ### Vulnerable Code ```tsx const sessionCookie = (await cookies()).get('session-id')?.value || 'anonymous' logUserAction({ sessionCookie, userAgent }) ``` ### Technical Analysis The Skill presents this code as a correct implementation and instructs agents to pass the raw value of the `session-id` cookie to `logUserAction`. Session cookies are authentication credentials and should not be included in analytics events, general application logs, or other sinks not specifically designed to store secrets. The implementation of `logUserAction` is not included, so direct network exfiltration cannot be confirmed. Nevertheless, the example creates a sensitive-data flow into an unspecified logging boundary. Logging systems commonly forward events to external monitoring providers, centralized collectors, backups, dashboards, and support tools. Passing the raw cookie therefore expands access to a reusable credential beyond the authentication subsystem. The session cookie is not necessary to demonstrate Next.js `after()` behavior. This data collection exceeds the minimum privileges and data access required for the Skill's declared performance-optimization functionality. ### Attack Path 1. An agent applies the Skill's recommended non-blocking logging pattern to a Next.js application. 2. The route handler reads the raw `session-id` cookie from an authenticated request. 3. The cookie value is passed to `logUserAction`. 4. The logging implementation forwards or persists the event in application logs, an analytics platform, or centralized monitoring infrastructure. 5. A compromised logging provider, unauthorized dashboard user, support operator, or attacker with log access obtains the session identifier. 6. If the session remains valid and lacks ...[truncated 677 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Never pass raw cookies, session IDs, access tokens, authorization headers, or other reusable credentials to logging or analytics functions. - Replace the session cookie with a non-secret internal user identifier when user-level audit correlation is legitimately required. - For pseudonymous analytics, derive a non-reversible identifier using a server-side keyed HMAC and rotate the key under a documented policy. - Define a strict allowlist for fields accepted by `logUserAction`; reject sensitive field names such as `cookie`, `session`, `token`, and `authorization`. - Add centralized redaction before events leave the application process. - Apply restricted access, short retention periods, encryption, and audit controls to log storage. - Add automated tests that submit sentinel credentials and verify that they never appear in emitted events. - Replace the example with a safe pattern such as: ```tsx after(async () => { const userAgent = (await headers()).get('user-agent') || 'unknown' await logUserAction({ event: 'resource-updated', userAgent, }) }) ``` - Remove the vulnerable duplicate from both `rules/server-after-nonblocking.md` and the generated `AGENTS.md`. ]]>