查XSS漏洞需盯用户输入是否未经转义插入HTML上下文，重点检查表单回显、URL参数反射、富文本渲染；测试应覆盖事件属性如onerror；查Clickjacking须验响应头X-Frame-Options或CSP frame-ancestors；重定向漏洞关键看location赋值是否源于location.search等可控源；客户端验证可被轻易绕过，必须测试服务端校验。
直接看源码和响应头，比跑扫描器更快定位真实风险点。很多所谓“高危漏洞”在代码里一眼就能断定是否可利用，关键在知道盯哪里、怎么验证。
查XSS漏洞：重点看用户输入如何进DOM
真正的XSS触发点不是有没有<script>，而是用户可控数据是否未经转义就插入HTML上下文。常见坑位包括：
• 表单回显区域（如搜索结果页的<div id="keyword">${keyword}</div>）
• URL参数反射（如?msg=hello被直接写入document.write()或innerHTML）
• 富文本编辑器内容渲染（检查dangerouslySetInnerHTML或v-html是否绕过过滤）
测试时别只试<script>alert(1)</script>，更要试<img src=x onerror=alert(1)>和<svg/onload=alert(1)>——很多过滤器放行事件属性。
查框架嵌入漏洞：先看响应头，再验iframe行为
Clickjacking风险不取决于页面有没有<iframe>，而在于它是否允许被别人<iframe>套用。必须检查两个地方：
• 响应头中是否存在X-Frame-Options（值为DENY或SAMEORIGIN）
• 或Content-Security-Policy中是否含frame-ancestors 'none'或frame-ancestors 'self'
手动验证方法：本地建一个HTML文件，用<iframe src="目标网址"></iframe>加载，如果能正常显示且无控制台报错，说明防御缺失。注意：某些站点用JavaScript防框架（如if (top !== self) top.location = self.location;），但这类脚本容易被禁用或绕过，不能替代响应头。
查重定向与跳转漏洞：追踪所有动态location赋值
只要看到window.location.href、window.location.replace()、document.location或<meta http-equiv="refresh">，且其值来源于location.search、location.hash或document.cookie，就必须人工校验。
典型危险模式：
• const url = new URLSearchParams(location.search).get('redirect'); → 直接window.location.href = url
• content="0; url=" + getQueryParam("next")（服务端拼接）
验证方式：改URL参数为?redirect=https://evil.com，观察是否跳转。若跳转成功，再试javascript:alert(1)或data:text/html,<script>alert(1)</script>——后者可能绕过简单协议校验。
立即学习“前端免费学习笔记（深入）”；
查客户端验证绕过：删掉required和pattern后还能提交吗
HTML表单的required、pattern、minlength、type="email"全是装饰。真正要测的是服务器是否照单全收。
实操步骤：
• 用浏览器开发者工具删掉required属性，输入空值或超长字符串提交
• 把type="email"改成type="text"，输入test' OR '1'='1类SQL注入payload
• 用Burp Suite拦截请求，把password字段从8位改成128位再发出去
如果服务器返回200并处理了这些“非法”数据，说明后端没做校验——这本身不是XSS或SQLi，但它是后续攻击的跳板。
最常被忽略的一点：很多漏洞不是孤立存在的。比如一个未过滤的URL参数，既能触发重定向，又能被富文本编辑器取出来渲染成onerror事件，还能作为<iframe src>的值——得通盘看数据流向，而不是只盯单个标签或函数。
