如果以下陈述为真，
- 所有文档都与 HTTP 标头
Content-Type: text/html; charset=UTF-8一起提供。 - 所有 HTML 属性都括在单引号或双引号中。
- 文档中没有
<script>标签。
在 Web 服务器上生成 HTML 时，是否存在htmlspecialchars($input, ENT_QUOTES, 'UTF-8')（将&、"、'、<、>转换为相应的命名 HTML 实体）不足以防止跨站点脚本的情况？
htmlspecialchars()足以防止文档创建时HTML注入，并具有您声明的限制（即不注入标签内容/未引号属性）。
但是，还有其他种类的注入可能导致XSS，并且：
文档中没有 <脚本> 标签。
此条件并不涵盖 JS 注入的所有情况。例如，您可能有一个事件处理程序属性（需要在 HTML 转义中执行 JS-转义）：
<div onmouseover="alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!
或者，更糟糕的是，javascript：link（需要 JS-escaping in URL -escape in HTML -escaping）：
<a href="javascript:alert('<?php echo htmlspecialchars($xss) ?>')"> // bad!
无论如何，通常最好避免使用这些构造，尤其是在模板化时。写<?php echo htmlspecialchars(urlencode(json_encode($something))) ?>是相当乏味的。
而且......注入问题也可能发生在客户端（DOM XSS）; htmlspecialchars()不会保护你免受一段JavaScript写入innerHTML（通常在糟糕的jQuery脚本中.html()）没有显式转义。
和。。。XSS的原因比注射更广泛。其他常见原因是：
允许用户创建链接，而无需检查已知良好的 URL 方案（
javascript:是最著名的有害方案，但还有更多）故意允许用户直接或通过轻标记方案（如BBCODE总是可利用）创建标记
允许用户上传文件（可以通过各种方式重新解释为HTML或XML）
假设你没有使用较旧的PHP版本（5.2左右），htmlspecialchars是"安全的"（当然，正如Bg提到的@Royal考虑后端代码）
在较旧的 PHP 版本中，格式错误的 UTF-8 字符使此函数容易受到攻击
我的 2 美分：只需始终通过告诉允许的内容来清理/检查您的输入，而不仅仅是转义所有内容/对所有内容进行编码
即，如果有人必须输入电话号码，我可以想象允许以下字符：0123456789（）+-.和一个空格，但所有其他字符都被忽略/删除
这同样适用于地址等，在其地址中为点/块/心等指定 UTF-8 字符的人一定是精神病患者......
据我所知，是的。我无法想象它不能避免 xss 的情况。如果你想完全安全，请使用strip_tags（）