Sec-WebSocket-Accept

TL;DR: Server response to Sec-WebSocket-Key during WebSocket handshake. Proves the server received and processed the upgrade request correctly.

What is Sec-WebSocket-Accept?

The Sec-WebSocket-Accept header is used in the WebSocket opening handshake to prove that the server received the WebSocket upgrade request.

Example

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
```javascript

## How It Works

The server computes this value from the client key by:

1. Concatenating Sec-WebSocket-Key with a GUID
2. Taking SHA-1 hash
3. Base64 encoding the result

If the computed value does not match what the client expects, the browser rejects the upgrade.

## Server Calculation Example

```javascript
import crypto from 'node:crypto'

function createWebSocketAccept(secWebSocketKey) {
  const GUID = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'
  return crypto.createHash('sha1').update(secWebSocketKey + GUID).digest('base64')
}

Troubleshooting Failed Handshakes

Common causes:

• wrong GUID or hash algorithm
• accidental whitespace/newline corruption in the key
• mismatched Connection / Upgrade headers
• unsupported Sec-WebSocket-Version

When debugging, inspect the full 101 response, not only Sec-WebSocket-Accept.

Related Headers

• Sec-WebSocket-Key
• Upgrade
• 101 Switching Protocols

The WebSocket Handshake in Full

Understanding why Sec-WebSocket-Accept exists requires understanding the full upgrade flow. A WebSocket connection starts as a plain HTTP/1.1 request. The client sends an Upgrade: websocket header along with a randomly generated Sec-WebSocket-Key. The server must prove it received and understood this specific request before the protocol switches.

The proof mechanism works by concatenating the client’s key with a fixed magic GUID (258EAFA5-E914-47DA-95CA-C5AB0DC85B11) defined in RFC 6455, computing a SHA-1 hash of the result, and base64-encoding it. The client performs the same calculation independently and compares the result. If they match, the server genuinely processed the WebSocket upgrade request.

This handshake design prevents two specific problems. First, it stops caching proxies from accidentally serving a cached HTTP response to a WebSocket upgrade request, because the accept value is unique per connection. Second, it ensures the server is actually a WebSocket server and not just any HTTP server that blindly returns 101 Switching Protocols.

The security model here is not about secrecy — the GUID is public knowledge. It is about protocol correctness: both sides must implement the same algorithm to complete the handshake. If a server returns a wrong or missing Sec-WebSocket-Accept, the browser will refuse to open the WebSocket connection and report a handshake failure in the console.