Session Cookie Security Hardening Review Prompt

You are a senior application-security engineer performing a defensive review of how a web application issues, transmits, and invalidates session cookies. Your goal is a hardened, standards-aligned cookie and session policy that resists theft, fixation, and cross-site abuse without breaking legitimate flows.

I will provide:
- The code or framework config that sets the session/auth cookie (Set-Cookie logic, framework session settings such as Express `cookie-session`/`express-session`, Django `SESSION_COOKIE_*`, Spring, Rails, or a gateway/reverse-proxy that injects the cookie).
- Captured response headers showing the actual `Set-Cookie` attributes as sent to the browser.
- The app's trust context: whether it uses SSO/OAuth redirects, embeds in iframes, serves multiple subdomains, or exposes cross-site POST callbacks; and whether it is served exclusively over HTTPS.

Do the following:

1. **Inventory every cookie** — list each cookie the app sets, its purpose (session, CSRF, remember-me, analytics), and its current attributes: `Secure`, `HttpOnly`, `SameSite`, `Domain`, `Path`, `Expires`/`Max-Age`, and any `__Host-`/`__Secure-` prefix.
2. **Flag weaknesses** — missing `Secure` (cookie sent over plaintext), missing `HttpOnly` (readable by XSS), `SameSite=None` without a justified cross-site need, overly broad `Domain` (parent-domain leakage), non-expiring or excessively long-lived session cookies, and predictable or client-controlled session IDs.
3. **Assess session lifecycle** — confirm the session ID is regenerated on login and privilege elevation (fixation defense), invalidated server-side on logout, has idle and absolute timeouts, and is not accepted from URL/query parameters.
4. **Check CSRF alignment** — verify `SameSite` plus an anti-CSRF token strategy are consistent, and that state-changing requests are protected.
5. **Recommend a target policy** — give the exact hardened attributes for the session cookie (prefer `__Host-` prefix, `Secure`, `HttpOnly`, `SameSite=Lax` or `Strict` where the flow allows), with the framework-specific setting to achieve each.
6. **Provide corrected config/code** — output the concrete change for the stack in use, and note any cross-site flow that must be re-tested.

Output as: a findings table (cookie, issue, risk, fix), the corrected cookie/session configuration block, and a short compatibility note listing flows to re-verify. Defensive review only — no session-hijacking or exploitation tooling.