A replay attack captures and retransmits valid authentication data to gain unauthorized access. An attacker records a successful login or API request and replays it later. Prevention: timestamps with short validity windows, nonces (single-use tokens), sequence numbers, and challenge-response protocols that produce unique values per session.
Replay attacks reuse captured credentials or tokens without needing to understand their contents. If an API authenticates via a static token in a header and an attacker captures it via network sniffing, they can replay that exact request indefinitely. TLS prevents network-level capture, but replays still occur at the application layer (stolen tokens, logged requests). Prevention mechanisms: timestamps (reject requests older than N seconds – requires synchronized clocks), nonces (random values used once and recorded by the server – reject duplicates), sequence numbers (monotonically increasing – reject out-of-order), and challenge-response (server sends a random challenge, client signs it – each response is unique and non-replayable). TLS 0-RTT (early data) in TLS 1.3 is explicitly vulnerable to replay by design – middleboxes can replay the 0-RTT data to the server. Applications must mark 0-RTT handlers as idempotent.
CSRF (Cross-Site Request Forgery)
CSRF tricks a user's browser into making authenticated requests to a site where the user is logged in. An attacker's page includes a form or image that submits to the target site – the browser automatically attaches the user's cookies. Prevention: anti-CSRF tokens, SameSite cookies, and checking Origin/Referer headers.
Man-in-the-Middle (MITM)
A man-in-the-middle attack intercepts communication between two parties, reading or modifying traffic without either party's knowledge. TLS prevents MITM by authenticating the server via certificates and encrypting the channel. MITM succeeds when: TLS is absent (HTTP), certificate validation is disabled, or the attacker controls a trusted CA.