What is Session and Token Replay?

Back to learning

Session and token replay happens when an attacker uses valid authentication state instead of logging in again. The session may come from a stolen browser cookie, bearer token, API key, OAuth token, mobile app token, or service credential.

This is why account protection cannot stop at a successful login. A session can be valid and still be used by the wrong actor.

Why replay is hard to see

A replayed token often looks legitimate at first glance. It may pass signature checks, match an active session, and carry the right account identifier. If the application only asks "is this token valid?", the request is allowed.

The better question is "does this use still fit the context in which the token was issued?"

Risk can change when:

• The same session appears from a new network, proxy, ASN, or geography.
• The device or browser evidence changes during the session.
• A session created after recovery immediately requests sensitive changes.
• An API token is used from a new client or route pattern.
• A token starts making unusually high request volumes.
• The user changes password, MFA, email, or recovery settings.

None of these signs proves theft. They are reasons to adjust confidence.

Sensitive actions need fresh decisions

A long-lived session can be fine for low-risk browsing and still be too weak for changing account control. Applications should consider fresh authentication, step-up checks, session downgrade, or review before:

• Changing email, phone, password, MFA, passkeys, or recovery methods
• Creating, rotating, or expanding API keys and service tokens
• Adding payment methods or payout destinations
• Exporting account data
• Changing admin roles or permissions
• Approving refunds, credits, or support overrides

This is especially important after password reset, device change, support recovery, or suspicious login pressure.

Token handling basics

Good token handling reduces the replay window:

• Use secure, HTTP-only cookies for browser sessions where appropriate.
• Avoid putting tokens in URLs, logs, analytics events, or screenshots.
• Rotate or revoke sessions after account-control changes.
• Expire idle and absolute sessions deliberately.
• Scope API tokens to the workload that needs them.
• Show safe prefixes or identifiers in UI, not raw secrets after creation.
• Keep an audit trail for token creation, use, rotation, and revocation.

The point is not to challenge every request. The point is to make stolen or misused state easier to detect and easier to contain.

How Peakhour evidence helps

Request-path evidence can help operators see when a valid-looking session starts behaving differently. Bot signals, proxy context, browser and network fingerprints, route intent, response outcomes, and rate keys can all support decisions around session risk.

Those signals should be used carefully. They are context, not identity. A privacy tool, mobile network, or browser update can change the evidence for a legitimate user. The response should fit the consequence: log, challenge, rotate, rate limit, hold, block, or review.