Cybersecurity glossary
What is Session Replay?
Learn what session replay is, how captured tokens and recorded user sessions are reused, how replay differs from live session hijacking, and which anti-replay and masking controls reduce the risk.
Definition
Session replay is the reuse of a previously captured user session—typically by resubmitting stolen cookies, bearer tokens, or recorded request sequences—so an attacker can act as that user later, without performing a new login. The same name also describes client-side recording tools that capture DOM, clicks, and keystrokes and can leak secrets if they are misconfigured.
Why a recorded login is still a login
Authentication proves who you are once. A session proves you already passed that check. Session replay attacks the second object: the cookie, bearer token, or request sequence that the server will honor again. The attacker does not need your password if the artifact still works. They may have copied it from XSS, a malicious extension, an evil twin, a support recording, or a UX analytics script that was never supposed to see the password field.
That makes replay a user-threat problem as much as an application-security problem. People cannot see their session cookie. They can be socially engineered into installing the recorder, joining the hostile Wi-Fi, or sharing a screen that includes an already-authenticated admin console.
A related product category uses the same words. Session-replay analytics reconstruct a visitor’s clicks and keystrokes for UX debugging. Mis-scoped, those recordings are a searchable archive of secrets.
How captured sessions get reused
Obtain a replayable artifact
Steal a session cookie, refresh token, signed request, or a recording that includes credentials typed into the page.
Keep it valid
Act before timeout, or rely on a server that never rotated or revoked the token after logout or password change.
Replay from attacker infrastructure
Send the cookie or Authorization header from another browser, script, or device.
Skip the login ceremony
The application treats the request as an already-authenticated user and skips MFA that was only bound to the original sign-in.
Perform the high-value action
Change recovery email, export data, approve a payment, or mint API keys before anyone notices a second location.
Optionally refresh the foothold
Use a replayed refresh token to mint new access tokens and survive the original session’s idle timeout.
Two meanings teams should not mix up
Token and request replay
A captured cookie or API call is sent again. Defense is lifetime, rotation, binding, and server-side revocation.
UX session recording
A script stores DOM and input for playback. Defense is aggressive masking, sampling, and treating the vendor as a credential store.
Network capture replay
Packets from a MITM or evil twin are resent. Defense is TLS plus anti-replay nonces on sensitive operations.
Support and screen-share residue
Recorded help-desk sessions and shared screens leak tokens and passwords that can be replayed after the call.
Replay versus hijacking versus fixation
| Issue | Timing | Typical fix |
|---|---|---|
| Session hijacking | Take over a session that is still live | HttpOnly cookies, XSS reduction, theft detection |
| Session replay | Reuse a captured artifact later or from elsewhere | Short life, rotation, binding, anti-replay nonces |
| Session fixation | Force a known ID before login, then wait | Issue a new session ID at authentication |
| UX recording leak | Secrets stored in playback for analysts | Mask inputs, block recorders on auth pages |
Making captured sessions useless
- Keep access tokens short-lived; rotate refresh tokens on use and revoke the family on logout, password change, and MFA reset.
- Bind sessions where practical (device, certificate, DPoP) so a cookie copied to another client fails.
- Require step-up authentication for recovery-email, payee, and API-key changes even if the session is already valid.
- Set Secure, HttpOnly, and appropriate SameSite on session cookies; never store session IDs in JavaScript-readable storage if you can avoid it.
- Put anti-replay nonces or idempotency keys on state-changing requests so a captured POST cannot be repeated for profit.
- If you deploy session-recording analytics, mask all password, MFA, payment, and token fields, and disable the SDK on login and admin routes.
- Treat unexpected new locations using an old session as theft: alert, step-up, and invalidate rather than only logging.
- Forbid unapproved recording extensions and help-desk tools on privileged workstations; they are session-capture malware with a vendor logo.
The recorder you invited in
Product teams add playback scripts to see why a checkout failed. Attackers add similar scripts with XSS. The data looks the same: every keystroke in a form. If your masking list is a best-effort CSS selector, assume passwords and session tokens will eventually be recorded. The incident then is not a glamorous exploit. It is a support engineer searching recordings for “login.”
The practical takeaway
Session replay turns a captured proof of prior authentication into a second login. Hijacking steals the wheel while you drive. Replay uses the spare key later. Analytics recordings can mint those spare keys by accident.
Expire and bind sessions, nonce the actions that move money or identity, and keep recorders off pages where people type secrets. If a copied cookie still works from a café in another country after the user hit logout, the session was never really closed.
Related security terms
Session Hijacking
Live takeover of an active session; replay is the later reuse of a captured artifact from that session.
Session Management
Timeouts, rotation, and binding controls that make stolen session data expire or fail when replayed.
Cross-Site Scripting (XSS)
A common way to steal cookies or inject a recorder that captures keystrokes for later replay.
Secure Cookie
HttpOnly, Secure, and SameSite flags shrink how session cookies can be captured before replay.
Man-in-the-Middle (MITM)
Network interception on an evil twin or hostile proxy is a classic way to obtain replayable traffic.
Frequently asked questions
What is session replay in simple terms?
Someone copies proof that you were already logged in—a cookie, a token, or a recorded sequence of requests—and uses it later to act as you. Separately, ‘session replay’ tools record your clicks and typing for analytics, which can leak passwords if masking fails.
How is session replay different from session hijacking?
Hijacking usually means taking over the session while it is still valid and often while you are still using it. Replay emphasizes using a captured artifact again—sometimes after you closed the tab—if the server still accepts it.
Does HTTPS stop session replay?
HTTPS stops eavesdroppers from reading tokens in transit. It does not stop replay of a token stolen via XSS, malware, a malicious extension, or a poorly masked recording SDK.
What is an anti-replay control?
A nonce, timestamp window, one-time refresh rotation, or token binding that makes a captured request fail the second time or fail from a different device.
Are product analytics session recordings a security issue?
They can be. If the recorder sees password fields, payment forms, or session tokens in the DOM, that vendor and anyone who can view recordings become an identity store you did not intend to create.
Can attackers replay a session after logout?
If logout only clears the browser and the server still accepts the old token, yes. Server-side invalidation and short lifetimes are what make logout real.
Do refresh tokens change the picture?
A stolen refresh token is a high-value replay target because it mints new access tokens. Rotate refresh tokens on use and bind them to the client where possible.
References
Explore authoritative guidance and frameworks related to session replay.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.