Skip to main content
WebSockets Tutorial
CHAPTER 17 Beginner

WebSocket Security Best Practices

Updated: May 14, 2026
20 min read

# CHAPTER 17

WebSocket Security Best Practices

1. Introduction

With a persistent, two-way connection open directly into your server's backend, security vulnerabilities can be disastrous. WebSockets bypass traditional HTTP security mechanisms like CORS (Cross-Origin Resource Sharing) defaults, making them uniquely susceptible to abuse if not properly configured. In this chapter, we will explore origin validation, rate limiting, and input sanitization to harden your WebSocket infrastructure.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Prevent Cross-Site WebSocket Hijacking (CSWSH).
  • Validate the Origin header during the handshake.
  • Implement rate limiting to prevent Denial of Service (DoS) attacks.
  • Sanitize payload data to prevent XSS and injection attacks.

3. Beginner-Friendly Explanation

Imagine a bank teller window.
  • Origin Validation: The teller checks your ID to make sure you are an actual customer, not a robber wearing a disguise (Cross-Site Hijacking).
  • Rate Limiting: If you start screaming 100 requests per second at the teller, the teller will pull down the security shutter and ignore you so they can serve other people safely.
  • Input Sanitization: If you slide a note that has a bomb inside it under the glass, the teller scans it, neutralizes it, and throws it in the trash before opening it.

4. Real-World Examples

  • CSWSH Attack: You are logged into secure-bank.com. You click a malicious link to evil-site.com. evil-site.com's JavaScript silently opens a WebSocket connection to wss://secure-bank.com. If the bank doesn't check the *Origin*, the connection succeeds, and the evil site steals your live financial data!

5. Origin Validation

During the HTTP Upgrade Handshake, the browser automatically sends an Origin header indicating which website executed the JavaScript. Your server must verify this header!

Example Handshake Request:

http
1234 
GET /chat HTTP/1.1
Host: api.example.com
Upgrade: websocket
Origin: https://mycoolapp.com

If the server sees an Origin of https://evil-site.com, it must reject the handshake with a 403 Forbidden status.

6. Rate Limiting (Throttling)

Because WebSockets stay open, a malicious user can write a while(true) loop to send 10,000 messages a second, starving your server's CPU. You must track how many messages a connection sends over a time window.

7. Concept: Rate Limiting Implementation

javascript
123456789101112131415161718 
// Server-side pseudocode
function onMessage(client, message) {
    const now = Date.now();
    
    // Check if the client has sent a message in the last 100ms
    if (now - client.lastMessageTime < 100) {
        client.warnings++;
        
        if (client.warnings > 5) {
            client.send(JSON.stringify({error: "Rate limit exceeded"}));
            client.close(); // Kick the user
            return;
        }
    }
    
    client.lastMessageTime = now;
    // Process message normally...
}

8. Input Sanitization

A WebSocket server accepts strings. Malicious users will try to send SQL commands or HTML scripts. If a user sends {"text": "<script>alert('Hacked')</script>"}, and you broadcast that string to 100 other users whose browsers render it directly into the DOM, you have just facilitated a massive XSS attack. Rule: Always strip HTML tags from text payloads on the server *before* broadcasting.

9. Frame Size Limits

Attackers might try to send a single 5-Gigabyte message to crash your server's RAM (Buffer Overflow/DoS). Your WebSocket server configuration must enforce a strict maxframesize. If a client sends a payload larger than, say, 2MB, the server should instantly sever the connection.

10. Best Practices

  • Validate Everything: Do not trust the client. Validate the token, validate the JSON structure, validate the string length, and sanitize the content.
  • Use WSS: We covered this in Chapter 12, but it bears repeating. Never transmit unencrypted data.

11. Common Mistakes

  • Assuming WebSockets are subject to CORS: Standard AJAX/Fetch requests follow CORS policies, blocking cross-domain requests automatically. WebSockets *do not* follow CORS. The browser will allow any site to attempt a WebSocket handshake to your server. You must manually check the Origin header.

12. Mini Exercises

  1. 1. Open your browser console on any website.
  1. 2. Look at the socket.send() function. Think about how easy it is for an attacker to write for(let i=0; i<1000000; i++) socket.send("Spam"); in the console. This is why your server needs Rate Limiting!

13. Coding Challenges

Challenge 1: Write a regex or use a library concept in PHP/JS that takes an incoming chat message string and safely escapes all < and > characters so they render as safe text (&lt; and &gt;) instead of executable HTML.

14. MCQs with Answers

Question 1

How can you prevent an unauthorized website from connecting to your WebSocket server?

Question 2

Why should a WebSocket server enforce a maximum payload size?

15. Interview Questions

  • Q: Explain Cross-Site WebSocket Hijacking (CSWSH) and how to mitigate it.
  • Q: What strategies would you employ on the backend to prevent a malicious user from spamming your chat server?

16. FAQs

Q: Does WSS protect against XSS or Spam? A: No. WSS only encrypts the data so it cannot be read *in transit*. It does not stop an attacker from sending malicious, encrypted spam directly to your server. You still must validate and sanitize.

17. Summary

In Chapter 17, we learned that WebSockets are powerful, but that power can be weaponized. By strictly validating the Origin header, enforcing frame sizes, rate-limiting incoming messages, and sanitizing payloads, we protect our servers from DoS attacks and our users from malicious code injections.

18. Next Chapter Recommendation

We have talked a lot about the "Server", but how do you actually write one? Proceed to Chapter 18: Building WebSocket Servers with PHP to discover the tools and libraries required to host your own backend.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Scaling WebSocket Applications
Next Chapter Building WebSocket Servers with PHP

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

❓ Related Quizzes 5

🎥 Related Videos 1