AI Coding Agents
Security
Session cookie tests for coding agent changes
September 29, 2026 - 2 minute read
Suppose a coding agent changes host routing and replaces a host-only session cookie with one scoped to the parent domain. Sign-in can still pass while the browser starts sending the credential to sibling services. Session cookie testing must check where session state travels as well as whether authentication succeeds.
Inspect the server's cookie attributes and follow the session through sign-in, privilege changes, and logout. Those checks expose a scope or lifecycle regression that a successful sign-in assertion can miss.
Define the intended session cookie boundary
Record the cookie name, host or domain scope, path, lifetime, and required attributes. Include every application host that participates in authentication. A domain-wide cookie may reach sibling services that do not need it, while an overly narrow path can create duplicate cookies with the same name.
RFC 6265 defines the Cookie and Set-Cookie fields and domain, path, expiration, Secure, and HttpOnly behavior. Omitting Domain makes the cookie host-only. For the routing example, test requests to both the intended application host and a sibling host.
Separate session cookies from preferences and anonymous identifiers. Only the credentials that authorize requests need the strict session lifecycle. Tests become clearer when they assert each cookie’s purpose instead of scanning for one expected header.
Use an isolated test account and capture the state before sign-in, after sign-in, after privilege changes, and after logout.
For a synthetic test, the expected assertions can be recorded without cookie values:
text
Before sign-in: protected endpoint denies the synthetic session.
After sign-in: session identifier changes and the protected endpoint allows access.
Sibling host: request does not include the host-only session cookie.
After privilege change: session rotates according to the application's contract.
After logout: cookie is expired and the old session is rejected by the server.Test creation, rotation, and expiration
Confirm that an authenticated response sets the expected Secure and HttpOnly attributes. Secure limits transport to protected connections. HttpOnly keeps the cookie out of script-readable APIs, but the browser still sends it with requests.
Exercise session fixation defenses by supplying a pre-authentication session, signing in, and confirming that the authenticated session identifier changes. Repeat the check after a privilege elevation or other event that the application treats as security-sensitive.
Test both idle and absolute expiration if the application promises them. Use a controllable clock where possible. A test that waits in real time is slow and can hide differences between server-side expiration and the browser cookie’s lifetime.
Logout should invalidate the server-side session and expire the browser cookie. Replay the old value against a protected endpoint and confirm denial. Repeat from another browser context when the product supports multiple active sessions.
Give a coding agent a safe authentication task
Provide the intended cookie contract, affected hosts, protected route, and focused test commands. Require evidence from actual response headers and a browser context. Unit tests around a cookie utility cannot show how middleware, proxies, and host routing combine.
Factory’s Automated Code Review can apply repository guidance to authentication changes. A review rule can flag modified cookie attributes, session rotation, or logout handling when corresponding tests are absent.
Never place a real session token in a task, fixture, screenshot, or build log. Generate short-lived synthetic values inside the isolated test.
Review session cookie test evidence
Record attribute names and lifecycle outcomes without recording cookie values. Verify behavior on redirects, error pages, and alternate hosts because those paths can set or clear cookies differently.
Pair cookie tests with server-side authorization tests. A correctly scoped cookie still represents a session that the application must validate for every protected action.
Run the same checks after framework, proxy, or identity-provider upgrades because defaults can change outside authentication code.
