Session Replay Attacks Have Nothing to Do With Session Replay Tools

A session replay attack is a network security exploit: an attacker captures a valid authenticated request or token and re-sends it to impersonate the user. A session replay tool is a frontend debugging product: it records DOM changes so an engineer can watch what a user saw. These two things share three words and nothing else — no common mechanism, no common defense, no common threat model. Yet the search results blend them together, and I have watched that blend produce genuinely wrong conclusions in vendor security reviews.

This article covers both, separately, and then gives you the paragraph to paste when a security questionnaire confuses them.

Part 1: the actual session replay attack

A replay attack works because HTTP requests are, by default, self-contained and repeatable. If I capture a valid request — a session cookie, a bearer token, a signed API call — and the server can’t tell a re-sent copy from the original, I can replay it and the server will happily act on it. No password cracking required; the credential was already valid.

Where capture happens in practice:

• Unencrypted or downgraded transport. Rare on the modern web, still common on internal networks and IoT.
• Cross-site scripting. Any XSS that can read tokens from document.cookie or local storage turns into a replay attack one fetch later.
• Leaked artifacts. HAR files attached to support tickets, tokens pasted into logs, Authorization headers captured by a misconfigured proxy.
• Malicious or compromised middleboxes. Anything that terminates TLS and re-originates traffic can capture everything.

The defenses are old, boring, and effective:

1. TLS everywhere, including internal hops. Capture is the prerequisite; make capture hard.
2. Short-lived tokens. A bearer token that expires in ten minutes limits the replay window to ten minutes. Refresh-token rotation with reuse detection catches the replay itself: if a rotated refresh token is used twice, someone captured it.
3. Nonces and timestamps on sensitive operations. A server-issued single-use nonce makes each request valid exactly once. Signed timestamps with a tight acceptance window bound the replay opportunity to seconds.
4. Bind tokens to context. Cookies with Secure, HttpOnly, and SameSite; token binding to a TLS session or device key where your stack supports it.

OWASP’s guidance on session management covers the testing side well. None of this is exotic — it’s the standard hygiene list, and it has been for two decades.

Part 2: session replay tools, which are something else entirely

A session replay product injects a JavaScript snippet that observes the DOM — via MutationObserver, in the lineage of the open-source rrweb library — and records structural changes, mouse movement, scrolling, and console/network metadata. Playback reconstructs the page from that recorded structure. It’s a screen recording in spirit, though technically it’s a DOM event log, not video.

Nothing is intercepted in transit. Nothing is re-sent to your server. There is no authentication artifact involved at any point. The security questions a replay tool raises are real but completely different ones: what data does the recording contain, is sensitive content masked before it leaves the browser, who can watch the recordings, and how long are they kept. That’s a data-protection review, not an attack-surface review. (For what a recording does and doesn’t contain, see what session replay actually records.)

Why the name collision causes real damage

The confusion isn’t hypothetical. Three failure modes I’ve seen in security reviews:

A replay tool gets rejected for the wrong reason. Someone searches “session replay security risk,” reads about token replay attacks, and concludes the debugging tool “enables session hijacking.” The review then misses the actual risks — unmasked PII, recording retention, third-party data flow — because it was busy defending against an attack the tool cannot perform.

A replay attack finding gets dismissed for the wrong reason. The inverse: a pentest report flags missing replay protection on an API, and someone responds “we don’t use session replay, we removed Hotjar last year.” I have seen a variant of this exchange in writing.

Questionnaires ask incoherent questions. “Does your product protect against session replay?” is unanswerable as posed. Answering “yes” or “no” both mislead, depending on which meaning the author had.

The etymology, for what it’s worth: security people used “replay attack” first — it predates the web. The product category borrowed “replay” in the video-playback sense decades later. Both usages are legitimate; they just collided.

The questionnaire answer you can crib

When a security review conflates the two, here’s a paragraph that untangles it without being condescending. Adapt freely:

“Session replay” refers to two unrelated things. (1) A session replay attack is the re-transmission of captured authentication material (cookies, tokens, signed requests) to impersonate a user. We mitigate this with TLS on all connections, short-lived access tokens with refresh rotation and reuse detection, and single-use nonces on sensitive state-changing operations. (2) A session replay tool is a frontend diagnostics product that records DOM changes for debugging. Our deployment masks all text input and designated sensitive elements client-side before transmission, restricts playback access by role, and retains recordings for [N] days. The tool does not capture, store, or transmit authentication credentials and cannot be used to replay requests against our services.

Two sentences of context, one concrete control list per meaning. Most reviewers accept it on the first pass, and the ones who follow up will at least follow up on the right topic.

If you remember one thing: a replay attack is about requests; a replay tool is about rendering. Any security discussion that doesn’t make that distinction in its first paragraph is about to waste everyone’s time.