Cybersecurity glossary
What is a Protocol Upgrade?
Learn what a protocol upgrade is in HTTP, how Upgrade and related headers switch connection modes, common targets like WebSockets, and the security checks that must happen at switch time.
Definition
A protocol upgrade is a negotiated switch of an existing connection from one application protocol to another—most commonly an HTTP/1.1 connection upgrading to WebSockets or another non-HTTP framed protocol using the HTTP Upgrade mechanism.
Why protocol upgrades matter
HTTP is excellent for request/response traffic. Some applications need long-lived, bidirectional messaging that does not fit neatly into repeated HTTP calls.
A protocol upgrade lets a connection start with familiar HTTP semantics—auth cookies, TLS, reverse proxies—then switch into another framing mode without opening a brand-new transport from scratch. WebSockets are the everyday example.
How an HTTP upgrade handshake works
Client opens an HTTP connection
Usually HTTPS. The first messages still look like normal HTTP requests.
Client asks to switch protocols
It sends Upgrade and Connection headers naming the target protocol (for example, websocket).
Server validates the request
Authn, authz, Origin checks, and endpoint policy run before agreeing to switch.
Server responds with 101
Switching Protocols confirms the change; hop-by-hop headers complete the handshake.
Both sides speak the new protocol
Frames or messages follow the upgraded rules for the rest of the connection lifetime.
Proxies must cooperate
Intermediaries need explicit support or the upgrade fails or is mishandled.
Upgrade vs other negotiation styles
| Mechanism | When it happens | Common use |
|---|---|---|
| HTTP Upgrade (101) | After an HTTP request on an existing connection | WebSockets on HTTP/1.1 |
| TLS ALPN | During TLS handshake | Selecting h2 / HTTP/1.1 for HTTPS |
| Alt-Svc discovery | After responses advertise alternatives | Pointing clients at HTTP/3 |
| Plain streaming HTTP | No protocol switch | SSE text/event-stream responses |
Common upgrade targets
WebSockets
Bidirectional messages for chat, collaboration, and live dashboards.
Cleartext HTTP/2 (h2c)
Some internal setups upgrade or prior-knowledge connect without TLS—rare on the public web.
Custom internal protocols
Legacy systems sometimes tunnel proprietary framing after an HTTP handshake.
Not usually HTTP/3
HTTP/3 arrives via QUIC/UDP discovery, not a classic TCP HTTP Upgrade.
Security checks at upgrade time
Once you return 101, many HTTP-centric controls no longer see discrete requests. The handshake is your last chance to apply connection-level policy.
Authenticate before 101
Do not upgrade anonymous sockets to privileged channels and “fix it later.”
Validate Origin and Host
Cross-site pages may initiate upgrades; treat Origin like a CSRF control.
Authorize the endpoint
Ensure the user may open that channel or room before switching protocols.
Configure proxies explicitly
Timeouts, buffering, and header forwarding differ for upgraded connections.
Operational checklist
- Document which routes may upgrade and which protocols are allowed.
- Enforce authn/authz/Origin checks on the upgrade request itself.
- Verify CDN/load balancer WebSocket or Upgrade support in staging.
- Set idle and max-lifetime limits on upgraded connections.
- Continue per-message authorization after the switch—not only at handshake.
- Log upgrade success/failure with user, origin, and target endpoint.
- Prefer WSS (TLS) for WebSocket upgrades on the public internet.
- Regression-test proxy idle timeouts that silently drop long-lived sockets.
The practical takeaway
A protocol upgrade renegotiates what an already-open connection speaks—classically moving from HTTP/1.1 into WebSockets with a 101 response. It is powerful for real-time apps and easy to misconfigure at proxies.
Treat the upgrade request as a privileged gate: authenticate, authorize, validate origins, and ensure every intermediary understands the new traffic. After 101, you are no longer in ordinary HTTP request territory.
Related security terms
WebSocket
The most common destination protocol after an HTTP upgrade on the web.
WebSockets Security
Hardening guidance once a connection has switched to WebSocket framing.
HTTP/1.1
The HTTP version whose Upgrade mechanism is classically used.
HTTP/2
Often negotiated via ALPN instead of HTTP Upgrade for browsers over TLS.
Server-Sent Events (SSE)
A related real-time pattern that usually stays on HTTP without an Upgrade switch.
Frequently asked questions
What is a protocol upgrade in simple terms?
It is when a connection starts as HTTP and both sides agree to switch into another mode—like WebSockets—so they can keep talking with different rules on the same TCP/TLS link.
What status code means the upgrade succeeded?
101 Switching Protocols. After that, the connection no longer speaks ordinary request/response HTTP on that socket.
Is HTTP/2 in browsers an Upgrade?
Usually not. Browsers typically negotiate HTTP/2 with ALPN during the TLS handshake rather than upgrading afterward. Cleartext h2c can use Upgrade in some non-browser setups.
Do reverse proxies always support upgrades?
Not automatically. Proxies must be configured to allow Upgrade/WebSocket traffic and to forward the right headers end to end.
What security checks belong on the upgrade request?
Authentication, Origin/Host validation, authorization for the target endpoint, and rate limits—before you return 101.
Is SSE a protocol upgrade?
No. Server-Sent Events typically remain HTTP with a streaming text/event-stream response.
Can upgrades be abused?
Yes. Cross-site WebSocket hijacking, unauthenticated upgrades, and proxy smuggling-style issues appear when the handshake is weakly validated.
References
Explore authoritative guidance and frameworks related to protocol upgrade.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.