判断XSS漏洞最有效的起点是检查输出点是否做过滤或转义；未处理的echo、print、document.write()、innerHTML等调用，若参数直接来自用户输入（如$_GET、location.search），即为高危点。
直接看输出点是否做过滤或转义，是判断XSS漏洞最有效的起点。没做处理的 echo、print、document.write()、innerHTML 等调用，只要参数来自用户输入（如 $_GET、$_POST、location.search），基本就是高危点。
找所有用户输入的输出位置
XSS本质是“数据当代码执行”，所以必须顺藤摸瓜：谁拿了用户数据，又把它扔进了HTML里？重点盯这些位置：
-
echo/print/printf（PHP）——查它们的参数是否直接来自$_GET、$_POST、$_COOKIE、$_REQUEST或 HTTP 头（如$_SERVER['HTTP_USER_AGENT']） -
response.write()（Node.js/ASP.NET）——检查写入内容是否拼接了 query、body 或 header 字段 -
document.innerHTML = .../element.insertAdjacentHTML()/document.write()（前端JS）——确认右侧变量是否来自location.href、location.search、localStorage或接口返回的未过滤字段 - 模板引擎中未加安全标记的插值，比如 EJS 的
<%= data %>、Handlebars 的{{data}}（不带三花括号）、Vue 的v-html绑定
验证时别只测 alert(1)
弹窗只是证明能执行 JS，但真实环境常有 WAF、CSP、HTML 过滤或编码干扰。绕过失败不等于没漏洞，得换角度验证：
- 先试基础 payload：
<img src=x onerror=alert(1)>比<script>更容易绕过简单标签过滤 - 若页面已对
<做了 HTML 实体编码（变成），就去检查是否在属性上下文中输出，比如：<code><input value="USER_INPUT">→ 尝试闭合引号：" onfocus=alert(1) autofocus="" - DOM 型 XSS 要看 JS 逻辑：是否用
location.hash或location.search解析后直接赋值给innerHTML？用浏览器 DevTools 断点跟踪执行流比盲打更可靠 - 注意上下文编码差异：输出到 JS 字符串里要绕过单/双引号和反斜杠；输出到 CSS 里要防
expression()或url(javascript:...)
Go 和 Vue 等框架的“自动防护”不是免死金牌
像 html/template 默认转义、Vue 的 {{ }} 插值默认 HTML 转义，确实大幅降低风险，但绕过点往往藏在“例外”里：
立即学习“前端免费学习笔记（深入）”；
- Go 中显式使用
template.HTML类型会跳过转义——查所有template.HTML(...)调用，确认传入内容是否真的可信（比如是否来自数据库固定文案，而非用户评论） - Vue 的
v-html、React 的dangerouslySetInnerHTML是明确放弃防护的信号，必须确保其值经过DOMPurify.sanitize()或服务端白名单过滤 - 前后端分离项目里，前端 JS 自己 fetch 数据再渲染，后端模板的防护完全无效——审计必须覆盖前端代码，不能只看 PHP/Go 模板
- CSP（Content-Security-Policy）头能缓解 XSS 影响，但不能替代输入过滤和输出编码；它只是最后一道防线，且配置错误（比如
unsafe-inline）反而制造假安全感
真正难发现的 XSS，往往不在明面上的输入框，而在 HTTP 头、Referer、User-Agent、JSON 接口返回的富文本字段，甚至缓存系统里被污染的响应体。审计时得把“用户可控”范围划得足够宽，而不是只盯着表单字段。
