Review brief

Intermediate30 min

An application is rotating its HMAC session-cookie key without signing users out. During one deployment window, servers receive a required current key and an optional previous key; all newly issued cookies must advance the migration.

Behavioral contract

A cookie is v1.<base64url JSON payload>.<base64url HMAC-SHA256>. Verify the signature over the exact encoded payload bytes.
Verify with the current key first and then the optional previous key. A previous-key match is valid and returns refresh=true; a current-key match returns refresh=false.
Every newly issued cookie is signed with the current key. The previous key is verification-only during migration.
Use the injected constant-time equality operation for same-length decoded MAC bytes. Malformed structure, encoding, JSON, or signatures return null and never throw to the request handler.

Review instructions

1Trace current-key, previous-key, invalid-signature, and malformed-cookie paths.
2Anchor each finding to the narrowest useful changed line and explain the migration or security impact.
3Recommend a direction rather than writing replacement code.
4Prioritize no more than four findings.

Learning objectives

• Implement dual-key verification with single-key issuance
• Compare authentication tags safely
• Treat malformed untrusted cookies as ordinary rejection

src/signed-cookie-types.tsTypeScript

@@ -0,0 +1,20 @@

1+export interface CookieKeys {

2+ current: string;

3+ previous?: string;

4+}

6+export interface CookieCodec {

7+ encodeJson(value: Readonly<Record<string, unknown>>): string;

8+ decodeJson(encoded: string): Readonly<Record<string, unknown>>;

9+ decodeMac(encoded: string): Uint8Array;

10+}

11+

12+export interface CookieMac {

13+ sign(encodedPayload: string, key: string): string;

14+ timingSafeEqual(left: Uint8Array, right: Uint8Array): boolean;

15+}

16+

17+export interface VerifiedCookie {

18+ payload: Readonly<Record<string, unknown>>;

19+ refresh: boolean;

20+}

Reference solution

The findings below are ordered by priority.

Findings

1. Cookies signed by the previous key are rejected

Location: src/signed-cookie.ts:17-21

Verification computes only a current-key MAC. Every session issued before rotation fails immediately, defeating the zero-sign-out migration and potentially creating a fleet-wide login incident.

Try the current key first and, only when needed, the optional previous key. Return refresh=true for a previous-key match so the response can advance that session.

2. Newly issued cookies keep using the previous key

Location: src/signed-cookie.ts:33-36

When a previous key exists, issueCookie prefers it. New sessions and refreshed sessions never migrate to the current key, so removing the old key later signs out all of them.

Always sign new cookies with keys.current; the previous key must be verification-only.

3. Signature comparison is not constant-time and bypasses the injected primitive

Location: src/signed-cookie.ts:17-20

The code compares base64url strings with !== and never decodes either MAC or calls timingSafeEqual. Ordinary string comparison can reveal prefix timing information about an authentication tag.

Decode the supplied and expected MACs, reject unequal lengths, and use the injected constant-time comparison for equal-length bytes.

4. Untrusted malformed cookies can throw through request handling

Location: src/signed-cookie.ts:13-15 and src/signed-cookie.ts:22-25

Malformed structure throws deliberately, while invalid base64url or JSON can throw from decodeJson. A client-controlled Cookie header can therefore turn a normal unauthenticated request into a server error.

Contain parsing and decoding failures inside verification and return null for every malformed or unauthenticated value.

Reasonable non-findings

Signing the exact encoded payload avoids differences introduced by JSON reserialization.
A current-key match correctly needs no refresh.
Trying the current key before the previous key is the intended migration order.
Omitting a key identifier is acceptable because the contract explicitly defines a two-key verification window.