Cybersecurity glossary
What are Server-Sent Events (SSE)?
Learn what Server-Sent Events are, how browsers receive one-way HTTP streams, when to choose SSE vs WebSockets, and which security and proxy settings keep streams reliable.
Definition
Server-Sent Events (SSE) are a web technology for one-way, long-lived HTTP streams where a server pushes text events to a browser or client over a persistent connection, commonly using the text/event-stream media type.
Why Server-Sent Events matter
Polling wastes requests asking “any update yet?” Short polling adds latency and load. For many dashboards, notifications, and progress bars, the server already knows when something changed.
Server-Sent Events (SSE) give you a simple, HTTP-native push channel: one long response that delivers named text events as they happen, with browser-friendly automatic reconnection.
How an SSE stream works
Client opens EventSource (or equivalent)
It issues an HTTP GET to an events endpoint, often with cookies or tokens for auth.
Server responds with text/event-stream
Headers disable caching and keep the connection open for streaming.
Server writes event frames
Lines like data: and optional id:/event: fields form discrete messages.
Client dispatches events to handlers
JavaScript receives messages without parsing a custom binary protocol.
Interruption triggers reconnect
Browsers reconnect and may send Last-Event-ID so the server can resume.
Server ends or times out intentionally
Idle limits and max durations prevent abandoned streams from living forever.
SSE vs WebSockets vs polling
| Approach | Direction | Best fit |
|---|---|---|
| SSE | Server → client | Live feeds, notifications, job progress |
| WebSocket | Bidirectional | Chat, collaborative editing, low-latency duplex |
| Short polling | Client asks repeatedly | Simple cases; higher overhead at scale |
| Long polling | Held request until event | Legacy compromise where SSE unavailable |
Practical strengths and limits
Works over ordinary HTTP
No protocol upgrade required; easier for some proxies and HTTP tooling.
Automatic browser reconnection
EventSource handles retry basics when event IDs are used well.
Text-oriented payloads
Great for JSON-in-text events; less ideal for binary frames.
One-way by design
Client-to-server data still needs normal HTTP requests or another channel.
Security and reliability considerations
Authenticate the stream
Do not expose event endpoints anonymously if they carry private data.
Authorize continuously
If permissions change, stop the stream; do not assume handshake auth lasts forever without checks.
Disable proxy buffering
Nginx/`X-Accel-Buffering` and CDN settings must allow chunked live delivery.
Limit concurrent streams
Each open SSE holds a worker/connection—quota users and protect against reconnect storms.
Avoid caching
Mark responses private/no-store so shared caches never store personalized event streams.
Validate event content at render time
If events inject into HTML, XSS rules still apply.
Operational checklist
- Set Content-Type: text/event-stream and disable response caching.
- Turn off intermediary buffering on the SSE path; test through your real CDN/proxy.
- Emit event ids and honor Last-Event-ID for resume semantics.
- Apply authn/authz on connect and periodically for long-lived streams.
- Configure idle and maximum stream lifetimes; document client retry expectations.
- Rate-limit new stream connections per user and IP.
- Monitor open stream counts, reconnect rates, and upstream queue lag.
- Prefer HTTPS and SameSite cookie settings appropriate to your auth model.
The practical takeaway
Server-Sent Events provide a simple HTTP stream for server-to-client updates with browser-native reconnection. They shine for live status and notification feeds where duplex sockets would be overkill.
Make SSE production-ready by fixing proxy buffering, authenticating streams, bounding concurrency, and treating event payloads with the same XSS and authz care as any other response.
Related security terms
WebSocket
A bidirectional alternative often compared when designing real-time features.
HTTP Keep-Alive
Persistence concepts related to long-lived HTTP connections used by SSE.
Protocol Upgrade
Not required for SSE—SSE usually stays on standard HTTP responses.
Reverse Proxy
Must disable response buffering for SSE to stream promptly.
Rate Limiting
Limits concurrent streams and reconnect storms that can overload origins.
Frequently asked questions
What are Server-Sent Events in simple terms?
They let a website keep a connection open so the server can send updates—like live scores or job progress—without the browser asking over and over.
How is SSE different from WebSockets?
SSE is one-way (server to client) over HTTP. WebSockets are bidirectional after an upgrade handshake and use a different framing protocol.
What MIME type does SSE use?
text/event-stream. The stream is composed of event lines such as data:, event:, id:, and retry:.
Do browsers reconnect automatically?
The EventSource API reconnects by default and can resume using the Last-Event-ID header when event IDs are provided.
Can SSE work through CDNs and proxies?
Yes if buffering is disabled and timeouts are long enough. Misconfigured proxies hold the stream until it finishes—which breaks live updates.
Is SSE good for chat apps?
Only for server-to-client fanout. If clients must send frequent messages on the same channel, WebSockets or separate HTTP POSTs are usually better.
Does SSE require HTTPS?
Browsers increasingly require secure contexts for powerful APIs; use HTTPS in production regardless.
References
Explore authoritative guidance and frameworks related to server-sent events (sse).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.