T09 · Insecure Skill Coding Practices
Warning
- Location
- route-handlers.md:99
- Finding
- Authentication Cookie Disclosed in JSON Response Example<![CDATA[ ## Vulnerability Details **File Location**: `route-handlers.md:99-105` **Vulnerability Type**: Authentication credential disclosure **Risk Level**: Medium ### Vulnerable Code ```tsx // Headers const authHeader = request.headers.get('authorization') // Cookies (Next.js helper) const cookieStore = await cookies() const token = cookieStore.get('token') return Response.json({ query, token }) ``` ### Technical Analysis The route-handler example reads a value named `token` from the request's cookie store and returns it in a client-visible JSON response. Authentication and session credentials should remain server-side and should only be used to authenticate or authorize the request. Returning the token can expose it to client-side JavaScript, browser extensions, HTTP response logging, observability platforms, reverse proxies, and any caller able to invoke the endpoint. The example also reads the `Authorization` header but does not validate it or use it to enforce access control. This is documentation rather than an active deployed endpoint. However, the Skill is intended to guide code generation and review, so an Agent could reproduce the insecure pattern in an application. ### Attack Path 1. A developer or Agent copies the request-helper example into a route handler. 2. An authenticated user requests the endpoint and includes the session cookie. 3. The handler retrieves the authentication token from the cookie store. 4. The handler serializes the token into its JSON response. 5. Malicious client-side code, a compromised browser extension, an unauthorized caller, or response-logging infrastructure captures the token. 6. If the token is reusable, the attacker presents it to protected endpoints and impersonates the affected user. ### Impact Assessment Successful exploitation could disclose reusable session credentials and permit account impersonation within the authorization scope of the exposed token. The resulting privileges depend on the victim ...[truncated 289 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Never serialize access tokens, refresh tokens, session identifiers, or authentication-cookie values into an API response. - Use the credential only for server-side authentication and authorization. - Return non-sensitive information such as an authenticated boolean or a minimal public user profile. - Add an explicit warning explaining that request headers and cookies may contain secrets. - Replace the example with a pattern similar to: ```tsx export async function GET(request: Request) { const session = await authenticateRequest(request) if (!session) { return Response.json({ error: 'Unauthorized' }, { status: 401 }) } return Response.json({ authenticated: true, userId: session.user.id, }) } ``` - Mark authentication cookies `HttpOnly`, `Secure`, and with an appropriate `SameSite` policy. - Configure application and infrastructure logging to redact authorization headers, cookies, and token-like response fields. ]]>