SSE Security, CORS & Credentials

Technical Deep Dive & Specifications

1. The CORS Protocol Requirements for EventSource

When connecting to a cross-origin SSE stream:

// Cross-Origin connection with Cookies / Credentials
const sse = new EventSource('https://api.example.com/live-stream', {
  withCredentials: true
});

The server must return the following HTTP response headers:

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Connection: keep-alive

[!CAUTION] If withCredentials: true is set, the server MUST NOT send Access-Control-Allow-Origin: *. The browser's CORS security policy will reject the connection immediately with a security error.

2. The Custom Header Dilemma & Solutions

The native EventSource API does not support custom request headers (like Authorization: Bearer <jwt>).

// ❌ INVALID - The browser silently ignores any headers object!
const sse = new EventSource('/stream', {
  headers: { 'Authorization': 'Bearer my-jwt-token' } 
});

To authenticate SSE streams in production, choose one of these three battle-tested architecture patterns:

+-----------------------------------------------------------------------------------------------+
|                               SSE AUTHENTICATION STRATEGIES                                   |
+-----------------------------------------------------------------------------------------------+
|  Strategy                     | Mechanism                                | Security Profile   |
+-------------------------------+------------------------------------------+--------------------+
|  1. HttpOnly Session Cookie   | Uses `withCredentials: true`             | ⭐ High (Prevents  |
|     (Recommended for Web)     | Cookies sent automatically over HTTPS    | XSS token theft)   |
+-------------------------------+------------------------------------------+--------------------+
|  2. Single-Use Ticket / Token | Client POSTs for short-lived ticket;     | ⭐ High (Avoids    |
|     (For API Microservices)   | Connects via `?ticket=<single_use_uuid>` | URL token logging) |
+-------------------------------+------------------------------------------+--------------------+
|  3. Fetch + ReadableStream    | Uses `fetch()` with custom headers       | ⭐ Moderate-High   |
|     (Polyfill Approach)       | Parses stream chunks manually in JS      | (Requires manual   |
|                               |                                          | reconnect logic)   |
+-------------------------------+------------------------------------------+--------------------+

The Ephemeral Ticket Pattern (Strategy 2 Walkthrough)

1. Client sends authenticated REST call: POST /api/auth/sse-ticket with Authorization: Bearer <token>.
2. Backend generates a 30-second single-use cryptographically random ticket (stored in Redis).
3. Backend returns { ticket: "tkt_8f9a2b..." }.
4. Client opens stream: new EventSource('/api/stream?ticket=tkt_8f9a2b...').
5. Backend validates ticket, burns it from Redis immediately, and keeps the stream open.

CLIENT                                REST API                               SSE GATEWAY
  |                                       |                                       |
  |--- 1. POST /auth/sse-ticket (Bearer)->|                                       |
  |<-- 2. HTTP 200 { ticket: "xyz" } -----|                                       |
  |                                                                               |
  |--- 3. new EventSource('/stream?ticket=xyz') --------------------------------->|
  |                                                                               | (Validates & Burns xyz)
  |<-- 4. HTTP 200 text/event-stream (data: ...) ---------------------------------|

3. Content Security Policy (CSP) Configuration

If your web application enforces a strict Content Security Policy, you must explicitly permit the SSE streaming origin under the connect-src directive:

Content-Security-Policy: default-src 'self'; connect-src 'self' https://api.example.com https://realtime.example.com;

4. Preventing Cross-Site Scripting (XSS) in Real-Time UIs

Because SSE payloads arrive as plain text, injecting raw event.data directly into innerHTML allows malicious users to execute arbitrary JavaScript on other users' screens:

// ❌ VULNERABLE TO ZERO-CLICK STORED XSS!
sse.onmessage = (e) => {
  document.getElementById('chat').innerHTML += `<div>${e.data}</div>`;
};

// ✅ SECURE - Use textContent or DOM safe node creation
sse.onmessage = (e) => {
  const msgEl = document.createElement('div');
  msgEl.textContent = e.data; // Browser auto-escapes HTML/scripts
  document.getElementById('chat').appendChild(msgEl);
};

💻 Interactive Code Playground

Below is an interactive SSE Security & Authentication Playground. It lets you experiment with CORS credentials validation, single-use ticket exchange, and XSS payload rendering safety.

Starter Code

Line-by-Line Code Breakdown

• Lines 105–118: Demonstrates the ephemeral ticket acquisition pattern: exchanging a long-lived JWT for a short-lived, single-use ticket before instantiating EventSource.
• Lines 120–128: Simulates the backend gateway validating the ticket and burning it from Redis upon first connection. Even if the URL is logged in proxy logs, the token cannot be reused.
• Lines 135–138 (btnRenderVulnerable): Illustrates the classic stored XSS vulnerability when developers assign element.innerHTML = event.data.
• Lines 140–143 (btnRenderSecure): Demonstrates the safe sanitization pattern using element.textContent, preventing script execution.

Expected Browser Render Output

🔒 SSE Security, CORS & Authentication
+------------------------------------+------------------------------------+
| 1. Single-Use Ticket Handshake     | 2. XSS Payload Injection Defense   |
+------------------------------------+------------------------------------+
| [ POST /auth/sse-ticket ]          | [ Render innerHTML ] [ Safe text ] |
| [ Open EventSource(?ticket=...) ]  |                                    |
|                                    | Rendered Result:                   |
| Logs:                              | <img src=x onerror=...> Hello!     |
| [10:55:01] 200 OK: Generated tkt_x | (Safe string, not executed)        |
| [10:55:02] Stream OPEN             |                                    |
+------------------------------------+------------------------------------+