XSS漏洞本质是用户输入被浏览器误解析为代码执行，检测需聚焦输入输出链路是否转义/校验/隔离到位，常见于搜索回显、评论区、URL参数反射及富文本展示等场景。
HTML代码本身不执行逻辑，但它是XSS、头部注入、URL参数篡改等漏洞的直接载体。检测和修复的关键不是“扫HTML文件”，而是盯住**用户输入如何进入HTML、又如何被输出**——只要这个链路中有一环没转义、没校验、没隔离，就可能出问题。
怎么发现<script>或onerror类XSS漏洞</script>
这类漏洞本质是用户输入被当成HTML/JS代码执行了。常见于搜索回显、评论区、URL参数反射（如?msg=hello）、富文本编辑器内容展示等场景。
- 手动测试：在输入框或URL中提交
<script>alert(1)</script>、<img src=x onerror=alert(1)>、<svg/onload=alert(1)>，看是否弹窗或源码中未转义出现 - 检查DOM渲染方式：如果代码用了
innerHTML、document.write或Vue的v-html、React的dangerouslySetInnerHTML，且数据来源不可信，基本就是漏洞点 - 注意绕过手法：大小写混淆（
ScRiPt）、HTML实体编码（<script></script>）、注释分割（<scr<!-- -->ipt>）都可能绕过弱过滤
URL参数里藏了哪些危险信号
URL参数若未经处理就进HTML、HTTP头或后端SQL，就是典型入口。重点不是参数名，而是它最终出现在哪。
- 反射型XSS：参数值直接出现在响应HTML的
<title>、<meta>、<script>标签内，比如?name=<script>…→<title><script>…</title> - CRLF注入：参数含
%0d%0a或\r\n，且被拼入HTTP响应头（如Location: %0d%0aSet-Cookie: xss=1） - 伪协议滥用：参数控制
<img src="...">的src，却允许javascript:或data:text/html;base64,... - 检测工具可辅助，但必须人工验证：Burp Suite抓包改参，看响应头和HTML源码是否原样反射
为什么前端验证拦不住攻击，而服务端转义必须做
因为浏览器、插件、curl甚至直接发HTTP请求，都能完全绕过required、pattern或JS校验。所有“前端拦住”只是用户体验优化，不是安全防线。
立即学习“前端免费学习笔记（深入）”；
- 服务端输出到HTML正文时，必须调用对应语言的转义函数：
htmlspecialchars()（PHP）、Encode.forHtmlContent()（Java）、escape()（Python Jinja2） - 输出到HTML属性值（如
value="<user_input>"）时，需额外处理引号，不能只转</> - 输出到
<script>标签内或JS字符串中，要用JS上下文转义（如JSON.stringify()包裹），而非HTML转义 - 富文本是例外，但必须用白名单过滤（只留
<p>、<strong>等），禁用on*事件和javascript:协议
CSP配置错在哪几个地方最致命
CSP不是开了就安全，配错等于没开。最常踩的坑是过度依赖'unsafe-inline'或'unsafe-eval'，尤其当项目里有大量内联脚本或eval()时，干脆放弃了防御底线。
-
script-src 'self' https://cdn.example.com比script-src 'unsafe-inline'严格十倍；真要内联，用nonce或hash机制 -
default-src 'self'是起点，但必须显式覆盖img-src、connect-src、frame-src等，否则它们会继承default-src，可能意外放开危险源 -
report-uri或report-to必须配，否则你根本不知道策略有没有被绕过；先用Content-Security-Policy-Report-Only灰度上线 - CSP无法替代转义：它只是最后一道网，如果
innerHTML已把恶意脚本写进DOM，CSP最多阻止执行，但页面结构已被污染
真正容易被忽略的是“上下文敏感”——同一个用户输入，在<div>里要HTML转义，在href里要URL编码，在<script>里要JS字符串转义。漏掉任一上下文，防护就断了一环。
