Workerman防范XSS攻击的代码方法

在 Workerman 中防范 XSS 攻击的关键在于“输出时精准转义、输入时严格验证”——绝不能依赖存储前转义或框架自动防护，而必须在 HTML 渲染的最终环节，使用 `htmlspecialchars($input, ENT_QUOTES, 'UTF-8')` 或 `htmlentities()` 对所有用户输入进行上下文敏感的转义；同时辅以 `filter_var()` 类型校验、文本长度限制等输入层防御，才能真正阻断反射型与存储型 XSS 的双重风险，避免因单引号遗漏、编码不一致或数据污染导致的绕过与连锁问题。

Workerman 本身不自动处理 XSS，所有输出到 HTML 的用户输入都必须手动转义——这是防范反射型和存储型 XSS 的核心前提。

输出前必须用 htmlentities() 或 htmlspecialchars() 转义

反射型 XSS 多发生在 URL 参数直接 echo 到页面的场景（比如搜索结果页、错误提示页）；存储型则出现在从数据库读出内容后未过滤就渲染。两者共同点是：数据最终以未编码形式混入 HTML 文本流。

• htmlentities() 更彻底，会转义所有可表示的字符（含非 ASCII），适合多语言环境；htmlspecialchars() 只转义 < > " ' &，性能略高，日常够用
• 务必指定 ENT_QUOTES 和 UTF-8：htmlspecialchars($input, ENT_QUOTES, 'UTF-8')，否则单引号或编码不一致会导致绕过
• 不要在入库前转义（即“存储时转义”），那会让数据变脏、后续 JSON 输出或 API 返回出错；只在输出到 HTML 时转义

不能只靠转义：对输入也要做基础验证和长度限制

转义解决的是“输出安全”，但输入层放行恶意 payload（比如超长 JS 字符串、嵌套 script 标签）仍可能引发其他问题（如日志污染、前端解析异常、服务端内存溢出）。

• 使用 filter_var() 验证基础类型：filter_var($email, FILTER_VALIDATE_EMAIL)、filter_var($url, FILTER_VALIDATE_URL)
• 对自由文本字段强制长度限制：mb_strlen($content) <= 1000，避免存储型 XSS 携带巨型 payload
• 禁止客户端传入