10. 安全考虑这一节描述了一些 WebSocket 协议在使用中需要注意的问题。问题被分成了不同的小节。
10.1 非浏览器客户端WebSocket 可以抵御运行在被信任的应用程序（比如浏览器）中的恶意 Javascript 脚本，比如，通过检查 |Origin| 头字段。不过当面对具有更多功能的客户端时就不能采用此方法了（检查 |Origin| 头字段）。
这份协议可以适用于运行在 web 页面中的脚本，也可以直接被主机所使用。那些主机可以因为自身的目的发送一个伪造的 |Origin| 头字段，以此迷惑服务器。服务端因此服务器不应该信息任何的客户端输入。
例子：如果服务端使用了客户端的 SQL 查询语句，所有的输入文本在提交到 SQL 服务器之前必须进行跳脱操作（escape），减少服务端被 SQL 注入的风险。
10.2 Origin 的考虑服务端不必接收来自互联网的所有请求，可以仅仅受理包含特定源的请求。如果请求的源不符合服务端的接收范围，那么服务端应该在对客户端的握手响应中包含状态码 “403 Forbidden”。
|Origin| 的作用是可以预防来自运行在可信任的客户端中的 Javascript 的恶意攻击。客户端本身可以连接到服务器，通过 |Origin| 的机制决定是否将通信的权限交给 Javascript 应用。这么做的目的不是针对非浏览器的连接，而是杜绝运行在被信任的浏览器可能的潜在威胁 - Javascript 脚本伪造 WebSocket 连接。
10.3 针对基础设施的攻击除了一端的终节点会收到攻击之外，基础设施中的其他部分，比如代理，也可能会收到攻击。
针对代理的攻击实际上是针对那些在实现上有缺陷的代理服务器，有缺陷的代理服务器的工作方式类似：
- 首先你通过 Socket 的方式和 IP 为 2.2.2.2 的服务器建立连接，连接是经由代理的。
- 在连接建立完成后，你发送了类似下面的文本：
GET /script.js HTTP/1.1Host: target.com（更多更深入的描述见 ）
这段文本首先是传到代理服务器的，代理服务器正确的工作方式是应该将此文本直接转发给 IP 为 2.2.2.2 的服务器。可是，有缺陷的代理会认为这是一个 HTTP 请求，需要采用 HTTP 代理的机制，进而访问了 target.com 并获取了 /script.js。
这种错误的工作方式并不是你所期望的。但是不可能一一检查网络中所有可能存在此问题的代理，所以最好的方式就是将客户端发送的内容都进行掩码操作，这样就不会出现那种让有缺陷的代理服务器产生迷惑的内容了。
10.4 特定实现的限制在协议实现中，可能会有一些客观的限制，比如特定平台的限制，这些限制与帧的大小或者所有帧合并后的消息的大小相关（比如，恶意的终节点可以通过发送单个很大的帧（2**60），或者发送很多很小的帧但是这些帧组成的消息非常大，以此来耗尽另一方的资源）。因此在实现中，一端应该强制使用一些限制，限制帧的大小，以及许多帧最后组成的消息的大小。
10.5 WebSocket 客户端认证这份协议没有规定任何方式可被用于服务端在握手期间对客户端进行认证。WebSocket 服务端可以使用任何在普通 HTTP 服务端中使用的对客户端的认证方式，比如 cookie，HTTP 认证，或者 TLS 认证。
10.6 连接的保密性和完整性WebSocket 协议的保密性和完整性是通过将其运行在 TLS 上达到的。WebSocket 实现必须支持 TLS 并在需要的时候使用它。
对于使用 TLS 的连接，TLS 提供的大部分好处都是基于 TLS 握手阶段协商的算法的强度。比如，一些 TLS 加密算法没有保证信息的保密性。为了使安全达到合适的程度，客户端应该只使用高强度的 TLS 算法。 具体讨论了什么是高强度的 TLS 算法， 的附录 A.5 和 附录 D.3 提供了一些指导意见。
10.7 处理错误数据客户端和服务端接收的数据都必须经过验证。如果在任意时间点上，一端接收到了无法理解的或者违反标准的数据，或者发现了不安全的数据，或者在握手期间接收到了非期望的值（比如错误的路径或者源），则可以关闭 TCP 连接。如果接收到无效数据时 WebSocket 连接已经建立，那么一端在关闭 WebSocket 连接之前，应该向另一端发送一个带有适当的状态码的关闭帧。通过使用具有适当状态码的关闭帧，可以帮助定位问题。如果在握手期间接收到了无效的数据，那么服务端应该返回适当的 HTTP 状态码 。
一个典型的安全问题就是当发送的数据采用了错误的编码时。这份协议中规定了，文本数据包含的必须是 UTF-8 编码的数据。应用程序需要通过一个长度去确定帧序列的传输何时结束，但是这个长度往往在事先不好确定（碎片化的消息）。这就给检查文本消息是否采用了正确的编码带来了困难，因为必须等到消息的所有碎片帧都接受完成了，才可以检查它们组成的消息的编码是否正确。不过如果不检查编码的话，就不能确保接收的数据可以被正确的解释，并会带来潜在的安全问题。
10.8 在 WebSocket 握手中采用 SHA-1这份文档中描述的 WebSocket 握手并不依赖于 SHA-1 算法的安全属性，比如抗碰撞性或者在 中描述的 second pre-image attack。 |
