Session, cookies, and passkeys
Assess session issuance, recovery, revocation, and privilege changes as one continuous account-authority lifecycle.
This is the complete downloadable file. Open plain text ↗
---
name: session
description: "Assess session issuance, recovery, revocation, and privilege changes as one continuous account-authority lifecycle."
---
# Session, cookies, and passkeys
Assess session issuance, recovery, revocation, and privilege changes as one continuous account-authority lifecycle.
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
## Bring to the review
- Session and cookie configuration
- Recovery and logout flows
- Approved browser sessions
## Review guide
### 1. Inventory authority
Identify the server-recognized session, its binding attributes, expiry, rotation, and the events that should revoke it.
### 2. Map transitions
Review login, recovery, credential change, role change, and logout for consistent reauthentication and invalidation rules.
### 3. Check parallel state
Confirm the same revocation rules reach browser sessions, APIs, and persistent connections.
### 4. Review recovery proof
Ensure account recovery establishes ownership without leaving older authority usable.
## What to produce
- Session lifecycle map
- Revocation expectations
- Recovery control notes
## Common mistakes
- Treating logout as a client-only event
- Ignoring active sessions after recovery
- Confusing encryption with token authenticity
## Reading and source context
### Resources
- [OWASP Session Management: privilege-transition integrity](https://vulns.co/research/resources/owasp-session-privilege-transition-integrity/)
- [OWASP Forgot Password](https://vulns.co/research/resources/owasp-account-recovery-state-integrity/)
- [Adversarial passkeys: account recovery must close every continuing source of authority](https://vulns.co/research/resources/usenix-2026-passkey-remediation-authority-lifecycle/)
### Diagrams
- [Recovery must preserve account ownership](https://vulns.co/research/diagrams/account-recovery-challenge-lifecycle/)
### Reports
- [GitLab recovery delivery lacked verified-address binding](https://vulns.co/research/reports/gitlab-recovery-address-binding-cve-2023-7028/)
- [Microsoft account recovery lacked consistent attempt-limit enforcement](https://vulns.co/research/reports/microsoft-account-recovery-rate-limit-consistency-2021/)
- [Instagram recovery challenges were insufficiently bound to accounts](https://vulns.co/research/reports/instagram-recovery-challenge-account-binding-2019/)
## Provenance
Editorial guide by vulns.co / GK Data. Updated 2026-10-11.
Library snapshot: 2026-10-04; commit d5550c7891119cf1379e235721541c947850a3b3.
The guide is an editorial synthesis. Linked records preserve their own sources and review dates.
Reader: https://vulns.co/skills/session/
The review
What to look for
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
Inventory authority
Identify the server-recognized session, its binding attributes, expiry, rotation, and the events that should revoke it.
Map transitions
Review login, recovery, credential change, role change, and logout for consistent reauthentication and invalidation rules.
Check parallel state
Confirm the same revocation rules reach browser sessions, APIs, and persistent connections.
Review recovery proof
Ensure account recovery establishes ownership without leaving older authority usable.
What to produce
- Session lifecycle map
- Revocation expectations
- Recovery control notes
Common mistakes
- Treating logout as a client-only event
- Ignoring active sessions after recovery
- Confusing encryption with token authenticity
Continue the study
Reading & source context
Editorial notes above connect these references. Open each record for its original source and review date.
Visual models
Connected disclosures
From the field toolkit
Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.