1. 前端安全到底在防什么前端安全这个词刚入行的同学听起来容易觉得虚。页面能跑、按钮能点、接口能通不就完了吗但真正做过线上项目的人都知道前端是离用户最近的一层也是最容易被当成突破口的一层。用户输入的数据在这里落地第三方资源在这里加载浏览器各种存储机制在这里被调用稍有不慎一个看似不起眼的细节就能变成整个系统的软肋。我做了十多年前端从最早写jQuery插件到现在搞微前端架构踩过的安全坑不算少。最典型的一次是某次大促前夜运营同学在后台配置了一个带特殊字符的商品标题结果整个列表页的DOM结构被撑爆样式全乱排查到凌晨三点才发现是拼接HTML时没做转义。这件事让我彻底意识到前端安全不是“有空再优化”的选项而是从第一行代码开始就要刻在脑子里的习惯。这篇文章想聊的就是把前端常见的安全问题一次性捋清楚。我会按攻击类型、触发原理、实际代码场景、防御手段这个顺序来讲每个点都配上能直接抄的代码片段和配置示例。不管你是刚学完HTML CSS的新手还是已经能独立带项目的资深开发都能从中找到能立刻用上的东西。核心关键词就一个前端安全。围绕它展开的XSS、CSRF、点击劫持、依赖链攻击、敏感信息泄露等问题咱们一个一个拆。2. XSS跨站脚本攻击前端安全的第一大敌人2.1 XSS到底是怎么发生的XSS的全称是Cross-Site Scripting翻译过来叫跨站脚本攻击。名字听着绕原理其实特别简单攻击者想办法把一段可执行的脚本代码塞进你的页面里当其他用户访问这个页面时这段代码就在他们的浏览器里跑起来了。因为浏览器分不清这段代码是你写的还是攻击者写的所以它会老老实实执行。举个最朴素的例子。假设你有个搜索页面用户输入关键词后页面显示“您搜索的是xxx”。如果代码写成这样const keyword new URLSearchParams(location.search).get(q); document.getElementById(result).innerHTML 您搜索的是 keyword;正常用户输入“前端安全”页面显示“您搜索的是前端安全”没问题。但如果攻击者构造了这样一个链接https://example.com/search?qimg srcx onerroralert(document.cookie)用户点开这个链接innerHTML会把这段字符串当成HTML解析img标签的onerror事件触发alert(document.cookie)就执行了。攻击者可以把alert换成任何恶意代码比如偷偷把cookie发到自己的服务器。这就是最典型的反射型XSS。还有存储型XSS恶意代码被存进数据库所有访问该页面的用户都会中招危害更大。以及DOM型XSS完全在前端JS里发生不经过服务器。2.2 防御XSS的核心思路防御XSS的核心原则只有一条永远不要信任任何用户输入永远不要直接把不可信数据插入到HTML里。具体落地的时候分几个层面来做。第一层是输出编码。根据数据要插入的位置选择对应的编码方式。插入HTML内容区用HTML实体编码插入HTML属性用属性编码插入JavaScript代码块用JS编码插入URL参数用URL编码。很多同学只知道一个HTML转义结果把数据放进onclick属性里就出问题了。第二层是使用安全的API。能用textContent就不用innerHTML能用setAttribute就不用字符串拼接。React、Vue这些框架默认会对插值做转义但dangerouslySetInnerHTML和v-html是明确的逃生舱口用的时候必须确保内容已经过严格净化。第三层是CSP内容安全策略。这是一个HTTP响应头告诉浏览器只允许加载和执行哪些来源的资源。配置得当的话即使攻击者成功注入了脚本浏览器也会拒绝执行。一个相对严格的CSP配置长这样Content-Security-Policy: default-src self; script-src self https://trusted-cdn.com; style-src self unsafe-inline; img-src self data: https:; object-src none; base-uri self; form-action self这里script-src self表示只允许执行同源脚本内联脚本和eval都会被拦。object-src none禁止加载Flash等插件内容。base-uri self防止攻击者通过base标签劫持相对路径。注意CSP配置里尽量避免使用unsafe-inline和unsafe-eval这两个指令会大幅削弱防护效果。如果必须用内联脚本可以用nonce或hash机制。第四层是输入验证。虽然输入验证不能替代输出编码但能在早期过滤掉明显恶意的内容。比如用户年龄字段只允许数字那就用正则严格限制别等到输出的时候再处理。2.3 富文本场景下的XSS防护实际项目里最头疼的是富文本编辑器场景。用户需要加粗、斜体、插入链接、上传图片这些功能天然需要保留一部分HTML标签。这时候不能简单粗暴地全部转义得用白名单机制做净化。推荐使用成熟的净化库比如DOMPurify。它的用法很简单import DOMPurify from dompurify; const dirty img srcx onerroralert(1)p正常内容/p; const clean DOMPurify.sanitize(dirty, { ALLOWED_TAGS: [p, b, i, u, a, img, br], ALLOWED_ATTR: [href, src, alt, title] }); document.getElementById(content).innerHTML clean;DOMPurify会解析HTML移除不在白名单里的标签和属性同时处理各种绕过技巧比如svg里的脚本、math标签的变体等。自己写正则做净化几乎一定会被绕过这不是危言耸听是无数安全事件验证过的结论。还有一个细节容易被忽略href属性里的javascript:协议。a hrefjavascript:alert(1)点击/a这种写法点击就会执行脚本。DOMPurify默认会处理这个问题但如果自己写过滤逻辑一定要检查协议白名单只允许http:、https:、mailto:、tel:这些安全协议。3. CSRF跨站请求伪造借用户之手干坏事3.1 CSRF的攻击逻辑CSRF的全称是Cross-Site Request Forgery跨站请求伪造。它的思路和XSS不同XSS是往页面里注入代码CSRF是诱导用户在已登录状态下去访问一个攻击者构造的页面这个页面会自动向目标网站发起请求。举个例子。假设某银行网站有个转账接口https://bank.com/transfer?toxxxamount1000用的是cookie鉴权。用户登录银行后cookie就存在浏览器里。这时候用户点开了一个恶意页面页面里藏了这样一段代码img srchttps://bank.com/transfer?toattackeramount10000 styledisplay:none浏览器加载这个img时会自动向银行网站发起GET请求并且带上该网站的cookie。银行服务器一看cookie有效就执行了转账操作。用户完全不知情。这就是CSRF的可怕之处它不需要窃取用户的cookie只需要借用用户的登录状态。攻击者甚至不需要知道cookie的内容浏览器会自动带上。3.2 防御CSRF的几种武器防御CSRF最有效的手段是CSRF Token。服务器在渲染表单时生成一个随机token存在session里同时放在表单的隐藏字段中。提交时服务器比对token是否匹配。攻击者的页面无法获取这个token因为同源策略限制了跨域读取。form action/transfer methodPOST input typehidden namecsrf_token value随机生成的token input typetext nameto input typenumber nameamount button typesubmit转账/button /form服务器端验证逻辑app.post(/transfer, (req, res) { const { csrf_token, to, amount } req.body; if (csrf_token ! req.session.csrfToken) { return res.status(403).send(CSRF token验证失败); } // 执行转账逻辑 });第二种武器是SameSite Cookie属性。设置SameSiteLax或SameSiteStrict后浏览器在跨站请求时不会发送cookie。Lax模式允许顶级导航的GET请求携带cookieStrict模式则完全禁止。对于大多数网站Lax是平衡安全性和用户体验的选择。Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnlySecure表示只在HTTPS连接中发送cookieHttpOnly表示JavaScript无法读取cookie能有效缓解XSS窃取cookie的问题。第三种武器是验证请求头。检查Origin和Referer头确认请求来自合法来源。不过这两个头在某些情况下可能被省略或伪造所以只能作为辅助手段。实操心得CSRF Token要绑定用户session并且设置合理的过期时间。不要用固定token也不要把token放在URL里URL会被记录在浏览器历史、服务器日志、Referer头里容易泄露。3.3 前后端分离架构下的CSRF防护现在很多项目是前后端分离的前端用React或Vue后端提供RESTful API。这种架构下如果鉴权用的是JWT放在localStorage里那CSRF的风险会小一些因为攻击者的页面无法读取localStorage。但JWT放在cookie里的话CSRF风险依然存在。我的建议是如果JWT存在cookie里必须配合SameSite属性和CSRF Token双重防护。如果JWT存在localStorage里要注意XSS的风险因为XSS可以读取localStorage。两种方案各有取舍没有银弹。对于API请求可以在请求头里加一个自定义字段比如X-Requested-With: XMLHttpRequest然后服务器检查这个头。跨域请求默认不能带自定义头除非服务器明确允许。这也是一种轻量级的防护手段。4. 点击劫持与界面伪装攻击4.1 点击劫持的原理点击劫持的英文是Clickjacking也叫UI覆盖攻击。攻击者做一个透明的iframe覆盖在一个诱导性的页面上。用户以为自己在点击“领取奖品”按钮实际上点击的是iframe里某个网站的真实按钮比如“确认转账”或“授权登录”。这种攻击的防御手段主要是设置响应头。X-Frame-Options可以告诉浏览器是否允许页面被iframe嵌入X-Frame-Options: DENYDENY表示完全禁止嵌入SAMEORIGIN表示只允许同源页面嵌入。这个头兼容性很好老浏览器也支持。更现代的方案是CSP的frame-ancestors指令Content-Security-Policy: frame-ancestors selfframe-ancestors比X-Frame-Options更灵活可以指定多个允许的来源。如果两者同时存在frame-ancestors优先级更高。前端还可以用JavaScript做辅助防御比如检测当前页面是否在iframe中if (window.self ! window.top) { window.top.location window.self.location; }但这种方式可以被绕过只能作为补充不能替代响应头。4.2 界面伪装与视觉欺骗除了iframe覆盖还有一种攻击叫界面伪装。攻击者把恶意页面的外观做得和目标网站一模一样诱导用户输入账号密码。这种攻击严格来说不算技术漏洞更多是钓鱼手段但前端可以做些事情来帮助用户识别。比如在敏感操作页面显示用户自定义的标识像“上次登录时间”、“欢迎语”等让用户确认这是真实网站。银行网站常用这招。另外全站强制HTTPS配合HSTS头能防止中间人篡改页面内容。Strict-Transport-Security: max-age31536000; includeSubDomains; preload这个头告诉浏览器在接下来的一年内该域名的所有请求都必须用HTTPS。includeSubDomains覆盖所有子域名preload表示可以申请加入浏览器预加载列表连第一次HTTP请求都不会发出。5. 第三方依赖与供应链安全5.1 npm生态的依赖风险现代前端项目动辄几百个npm包直接依赖可能只有几十个但传递依赖能到上千个。这些包来自全球各地的开发者质量参差不齐。一个包被投毒整个项目就沦陷了。2018年有个著名事件某个流行的npm包被作者注入恶意代码会窃取用户的比特币钱包信息。这个包被下载了数百万次影响范围极广。还有更隐蔽的攻击者注册和知名包名字很像的包比如cross-env和crossenv开发者手滑打错字就中招了。防御供应链攻击首先要锁定依赖版本。package-lock.json和yarn.lock必须提交到版本库确保每次安装的依赖树完全一致。其次要定期审计依赖npm audit npm audit fixnpm audit会检查依赖中的已知漏洞并给出修复建议。对于无法自动修复的要评估风险必要时手动升级或替换。还可以用npm outdated查看哪些包有新版本定期更新。但更新前要在测试环境充分验证避免引入破坏性变更。5.2 第三方脚本的安全管理很多项目会引入第三方脚本比如统计工具、客服插件、广告SDK。这些脚本运行在页面里拥有和自家代码一样的权限能读取DOM、cookie、localStorage。如果第三方脚本被入侵后果不堪设想。管理第三方脚本第一要限制来源只从可信CDN加载。第二要用SRISubresource Integrity校验文件完整性script srchttps://cdn.example.com/lib.js integritysha384-xxxxxxxxxxxxxxxxxxxxxxxx crossoriginanonymous/scriptintegrity值是文件的哈希浏览器加载后会校验不匹配就拒绝执行。crossoriginanonymous表示跨域请求不带凭证。第三对于非关键的第三方脚本可以异步加载避免阻塞页面。还可以用iframe沙箱隔离限制其访问父页面的能力。注意SRI只对静态文件有效如果第三方脚本是动态生成的SRI无法使用。这时候只能靠CSP限制来源并定期审查第三方脚本的行为。6. 敏感信息泄露与前端存储安全6.1 前端存储的坑前端能用的存储机制有好几种cookie、localStorage、sessionStorage、IndexedDB。每种都有适用场景但用错了就是安全隐患。cookie会自动随请求发送所以适合存session标识但要设置HttpOnly、Secure、SameSite。localStorage容量大适合存不敏感的用户偏好但XSS能直接读取。sessionStorage和localStorage类似但关闭标签页就清空。IndexedDB适合存大量结构化数据同样受同源策略保护但XSS也能访问。绝对不要把敏感信息存在前端。API密钥、数据库密码、用户密码明文这些都不应该出现在前端代码或存储里。有些同学图省事把API密钥写在JS文件里以为压缩混淆就安全了。实际上打开开发者工具就能看到混淆只是增加阅读难度不是加密。6.2 源码泄露与Source Map生产环境的Source Map是个双刃剑。它能帮助定位线上错误但也可能泄露源码结构和业务逻辑。如果Source Map文件被公开访问攻击者能还原出接近原始的代码发现潜在漏洞。我的做法是生产环境生成Source Map但只上传到错误监控平台不部署到CDN。或者用hidden-source-map模式生成map文件但不添加引用注释只有知道文件名的人才能访问。// webpack.config.js module.exports { devtool: hidden-source-map, // 其他配置 };另外要确保.env文件、配置文件、备份文件不会被部署到Web目录。Nginx配置里加上规则禁止访问.开头的隐藏文件和常见备份后缀location ~ /\. { deny all; } location ~* \.(env|log|bak|sql|zip|tar\.gz)$ { deny all; }6.3 错误信息与日志泄露开发环境的详细错误堆栈对调试很有帮助但生产环境必须关闭。一个未捕获的异常可能把数据库表名、文件路径、框架版本都暴露出来。攻击者收集这些信息后能更有针对性地发起攻击。前端要做的是统一错误处理给用户展示友好的提示同时把详细错误上报到监控平台。不要直接把error.stack渲染到页面上。window.addEventListener(error, (event) { // 上报到监控平台 reportError({ message: event.message, filename: event.filename, lineno: event.lineno, colno: event.colno, stack: event.error?.stack }); // 给用户展示友好提示 showFriendlyMessage(页面出了点小问题请稍后重试); // 阻止默认的控制台输出 return true; });7. 常见问题与排查技巧实录7.1 安全自查清单项目上线前我习惯过一遍下面这个清单。每项都确认过心里才踏实。检查项检查内容风险等级XSS防护所有用户输入是否经过编码或净化高CSP配置是否设置了合理的Content-Security-Policy高CSRF防护敏感操作是否有Token或SameSite保护高点击劫持是否设置了X-Frame-Options或frame-ancestors中依赖安全是否运行过npm audit且无高危漏洞高敏感信息前端代码和存储中是否包含密钥或密码高HTTPS是否全站HTTPS并配置HSTS高Source Map生产环境是否隐藏或限制访问中错误处理生产环境是否关闭详细错误输出中第三方脚本是否使用SRI且限制来源中7.2 排查XSS的实用技巧遇到疑似XSS的问题我一般按这个顺序排查。先看数据流用户输入从哪来经过哪些处理最终插入到哪里。重点检查innerHTML、outerHTML、document.write、eval、setTimeout字符串参数这些危险API。然后看编码插入HTML内容区用HTML实体编码插入属性用属性编码插入JS用JS编码。很多漏洞是因为编码方式用错了比如把用户输入直接拼进onclick属性里HTML实体编码在属性里会被解码等于没编码。最后看CSP打开开发者工具看Console里有没有CSP违规报告。如果有说明有脚本被拦截了可能是攻击尝试也可能是自己的代码需要调整。7.3 依赖漏洞的应急处理npm audit报出高危漏洞时先别慌。第一步看漏洞详情确认影响范围。有些漏洞只在特定条件下触发如果你的项目没用那个功能风险就低。第二步看有没有修复版本有就升级。第三步如果暂时无法升级看能否通过配置或代码调整规避。我遇到过一种情况某个依赖的漏洞需要升级大版本才能修复但大版本有破坏性变更短期升不了。这时候的临时方案是用overrides字段强制指定子依赖的版本{ overrides: { vulnerable-package: ^2.0.1 } }这个字段在npm 8.3以上支持能强制所有依赖使用指定版本。但用之前要测试确保不会引入兼容性问题。7.4 安全与体验的平衡做安全防护最怕的是为了安全把用户体验搞崩。CSP配得太严内联脚本全挂SameSite设成Strict从外部链接跳转过来登录状态就丢了CSRF Token过期时间太短用户填个长表单提交就失败。我的经验是安全策略要分层核心操作严格非核心操作宽松。比如支付、改密码、授权登录这些必须强验证浏览、搜索、看公开内容可以适当放宽。CSP可以用Report-Only模式先跑一段时间收集违规报告确认不影响正常功能后再强制启用。Content-Security-Policy-Report-Only: default-src self; report-uri /csp-report这个头不会拦截任何内容只上报违规行为。观察一两周把误报处理完再切换到强制模式。8. 把安全变成开发习惯写了这么多其实核心就一句话前端安全不是某个阶段的任务而是贯穿开发全流程的习惯。写组件的时候多想一步“这个数据来自用户我转义了吗”引入依赖的时候多看一眼“这个包靠谱吗”配置服务器的时候多检查一遍“响应头设对了吗”。我自己的做法是在项目里建一个SECURITY.md把上面那些检查项和配置示例都记进去。每次新项目启动直接复制过来按清单过一遍。新同学入职也让他们先读这个文档知道哪些线不能踩。还有一个习惯是定期做安全演练。找个测试环境自己尝试构造XSS payload、CSRF请求、点击劫持页面看看防护措施是否生效。这种实战比看文档印象深得多。最后分享一个我常用的XSS测试payload集合放在测试环境里验证防护效果img srcx onerroralert(1) svg onloadalert(1) a hrefjavascript:alert(1)click/a iframe srcjavascript:alert(1) div stylebackground:url(javascript:alert(1)) input onfocusalert(1) autofocus details open ontogglealert(1)这些payload在测试环境跑一遍如果都被拦截或转义了说明防护基本到位。如果有一个弹窗就顺着数据流往回查找到漏洞点修复。安全这件事做得好没人夸出了事就是大事。与其事后救火不如平时多花点时间把基础打牢。上面这些内容都是我这些年踩坑踩出来的经验希望能帮你少走点弯路。
1. 前端安全到底在防什么前端安全这个词刚入行的同学听起来容易觉得虚。页面能跑、按钮能点、接口能通不就完了吗但真正做过线上项目的人都知道前端是离用户最近的一层也是最容易被当成突破口的一层。用户输入的数据在这里落地第三方资源在这里加载浏览器各种存储机制在这里被调用稍有不慎一个看似不起眼的细节就能变成整个系统的软肋。我做了十多年前端从最早写jQuery插件到现在搞微前端架构踩过的安全坑不算少。最典型的一次是某次大促前夜运营同学在后台配置了一个带特殊字符的商品标题结果整个列表页的DOM结构被撑爆样式全乱排查到凌晨三点才发现是拼接HTML时没做转义。这件事让我彻底意识到前端安全不是“有空再优化”的选项而是从第一行代码开始就要刻在脑子里的习惯。这篇文章想聊的就是把前端常见的安全问题一次性捋清楚。我会按攻击类型、触发原理、实际代码场景、防御手段这个顺序来讲每个点都配上能直接抄的代码片段和配置示例。不管你是刚学完HTML CSS的新手还是已经能独立带项目的资深开发都能从中找到能立刻用上的东西。核心关键词就一个前端安全。围绕它展开的XSS、CSRF、点击劫持、依赖链攻击、敏感信息泄露等问题咱们一个一个拆。2. XSS跨站脚本攻击前端安全的第一大敌人2.1 XSS到底是怎么发生的XSS的全称是Cross-Site Scripting翻译过来叫跨站脚本攻击。名字听着绕原理其实特别简单攻击者想办法把一段可执行的脚本代码塞进你的页面里当其他用户访问这个页面时这段代码就在他们的浏览器里跑起来了。因为浏览器分不清这段代码是你写的还是攻击者写的所以它会老老实实执行。举个最朴素的例子。假设你有个搜索页面用户输入关键词后页面显示“您搜索的是xxx”。如果代码写成这样const keyword new URLSearchParams(location.search).get(q); document.getElementById(result).innerHTML 您搜索的是 keyword;正常用户输入“前端安全”页面显示“您搜索的是前端安全”没问题。但如果攻击者构造了这样一个链接https://example.com/search?qimg srcx onerroralert(document.cookie)用户点开这个链接innerHTML会把这段字符串当成HTML解析img标签的onerror事件触发alert(document.cookie)就执行了。攻击者可以把alert换成任何恶意代码比如偷偷把cookie发到自己的服务器。这就是最典型的反射型XSS。还有存储型XSS恶意代码被存进数据库所有访问该页面的用户都会中招危害更大。以及DOM型XSS完全在前端JS里发生不经过服务器。2.2 防御XSS的核心思路防御XSS的核心原则只有一条永远不要信任任何用户输入永远不要直接把不可信数据插入到HTML里。具体落地的时候分几个层面来做。第一层是输出编码。根据数据要插入的位置选择对应的编码方式。插入HTML内容区用HTML实体编码插入HTML属性用属性编码插入JavaScript代码块用JS编码插入URL参数用URL编码。很多同学只知道一个HTML转义结果把数据放进onclick属性里就出问题了。第二层是使用安全的API。能用textContent就不用innerHTML能用setAttribute就不用字符串拼接。React、Vue这些框架默认会对插值做转义但dangerouslySetInnerHTML和v-html是明确的逃生舱口用的时候必须确保内容已经过严格净化。第三层是CSP内容安全策略。这是一个HTTP响应头告诉浏览器只允许加载和执行哪些来源的资源。配置得当的话即使攻击者成功注入了脚本浏览器也会拒绝执行。一个相对严格的CSP配置长这样Content-Security-Policy: default-src self; script-src self https://trusted-cdn.com; style-src self unsafe-inline; img-src self data: https:; object-src none; base-uri self; form-action self这里script-src self表示只允许执行同源脚本内联脚本和eval都会被拦。object-src none禁止加载Flash等插件内容。base-uri self防止攻击者通过base标签劫持相对路径。注意CSP配置里尽量避免使用unsafe-inline和unsafe-eval这两个指令会大幅削弱防护效果。如果必须用内联脚本可以用nonce或hash机制。第四层是输入验证。虽然输入验证不能替代输出编码但能在早期过滤掉明显恶意的内容。比如用户年龄字段只允许数字那就用正则严格限制别等到输出的时候再处理。2.3 富文本场景下的XSS防护实际项目里最头疼的是富文本编辑器场景。用户需要加粗、斜体、插入链接、上传图片这些功能天然需要保留一部分HTML标签。这时候不能简单粗暴地全部转义得用白名单机制做净化。推荐使用成熟的净化库比如DOMPurify。它的用法很简单import DOMPurify from dompurify; const dirty img srcx onerroralert(1)p正常内容/p; const clean DOMPurify.sanitize(dirty, { ALLOWED_TAGS: [p, b, i, u, a, img, br], ALLOWED_ATTR: [href, src, alt, title] }); document.getElementById(content).innerHTML clean;DOMPurify会解析HTML移除不在白名单里的标签和属性同时处理各种绕过技巧比如svg里的脚本、math标签的变体等。自己写正则做净化几乎一定会被绕过这不是危言耸听是无数安全事件验证过的结论。还有一个细节容易被忽略href属性里的javascript:协议。a hrefjavascript:alert(1)点击/a这种写法点击就会执行脚本。DOMPurify默认会处理这个问题但如果自己写过滤逻辑一定要检查协议白名单只允许http:、https:、mailto:、tel:这些安全协议。3. CSRF跨站请求伪造借用户之手干坏事3.1 CSRF的攻击逻辑CSRF的全称是Cross-Site Request Forgery跨站请求伪造。它的思路和XSS不同XSS是往页面里注入代码CSRF是诱导用户在已登录状态下去访问一个攻击者构造的页面这个页面会自动向目标网站发起请求。举个例子。假设某银行网站有个转账接口https://bank.com/transfer?toxxxamount1000用的是cookie鉴权。用户登录银行后cookie就存在浏览器里。这时候用户点开了一个恶意页面页面里藏了这样一段代码img srchttps://bank.com/transfer?toattackeramount10000 styledisplay:none浏览器加载这个img时会自动向银行网站发起GET请求并且带上该网站的cookie。银行服务器一看cookie有效就执行了转账操作。用户完全不知情。这就是CSRF的可怕之处它不需要窃取用户的cookie只需要借用用户的登录状态。攻击者甚至不需要知道cookie的内容浏览器会自动带上。3.2 防御CSRF的几种武器防御CSRF最有效的手段是CSRF Token。服务器在渲染表单时生成一个随机token存在session里同时放在表单的隐藏字段中。提交时服务器比对token是否匹配。攻击者的页面无法获取这个token因为同源策略限制了跨域读取。form action/transfer methodPOST input typehidden namecsrf_token value随机生成的token input typetext nameto input typenumber nameamount button typesubmit转账/button /form服务器端验证逻辑app.post(/transfer, (req, res) { const { csrf_token, to, amount } req.body; if (csrf_token ! req.session.csrfToken) { return res.status(403).send(CSRF token验证失败); } // 执行转账逻辑 });第二种武器是SameSite Cookie属性。设置SameSiteLax或SameSiteStrict后浏览器在跨站请求时不会发送cookie。Lax模式允许顶级导航的GET请求携带cookieStrict模式则完全禁止。对于大多数网站Lax是平衡安全性和用户体验的选择。Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnlySecure表示只在HTTPS连接中发送cookieHttpOnly表示JavaScript无法读取cookie能有效缓解XSS窃取cookie的问题。第三种武器是验证请求头。检查Origin和Referer头确认请求来自合法来源。不过这两个头在某些情况下可能被省略或伪造所以只能作为辅助手段。实操心得CSRF Token要绑定用户session并且设置合理的过期时间。不要用固定token也不要把token放在URL里URL会被记录在浏览器历史、服务器日志、Referer头里容易泄露。3.3 前后端分离架构下的CSRF防护现在很多项目是前后端分离的前端用React或Vue后端提供RESTful API。这种架构下如果鉴权用的是JWT放在localStorage里那CSRF的风险会小一些因为攻击者的页面无法读取localStorage。但JWT放在cookie里的话CSRF风险依然存在。我的建议是如果JWT存在cookie里必须配合SameSite属性和CSRF Token双重防护。如果JWT存在localStorage里要注意XSS的风险因为XSS可以读取localStorage。两种方案各有取舍没有银弹。对于API请求可以在请求头里加一个自定义字段比如X-Requested-With: XMLHttpRequest然后服务器检查这个头。跨域请求默认不能带自定义头除非服务器明确允许。这也是一种轻量级的防护手段。4. 点击劫持与界面伪装攻击4.1 点击劫持的原理点击劫持的英文是Clickjacking也叫UI覆盖攻击。攻击者做一个透明的iframe覆盖在一个诱导性的页面上。用户以为自己在点击“领取奖品”按钮实际上点击的是iframe里某个网站的真实按钮比如“确认转账”或“授权登录”。这种攻击的防御手段主要是设置响应头。X-Frame-Options可以告诉浏览器是否允许页面被iframe嵌入X-Frame-Options: DENYDENY表示完全禁止嵌入SAMEORIGIN表示只允许同源页面嵌入。这个头兼容性很好老浏览器也支持。更现代的方案是CSP的frame-ancestors指令Content-Security-Policy: frame-ancestors selfframe-ancestors比X-Frame-Options更灵活可以指定多个允许的来源。如果两者同时存在frame-ancestors优先级更高。前端还可以用JavaScript做辅助防御比如检测当前页面是否在iframe中if (window.self ! window.top) { window.top.location window.self.location; }但这种方式可以被绕过只能作为补充不能替代响应头。4.2 界面伪装与视觉欺骗除了iframe覆盖还有一种攻击叫界面伪装。攻击者把恶意页面的外观做得和目标网站一模一样诱导用户输入账号密码。这种攻击严格来说不算技术漏洞更多是钓鱼手段但前端可以做些事情来帮助用户识别。比如在敏感操作页面显示用户自定义的标识像“上次登录时间”、“欢迎语”等让用户确认这是真实网站。银行网站常用这招。另外全站强制HTTPS配合HSTS头能防止中间人篡改页面内容。Strict-Transport-Security: max-age31536000; includeSubDomains; preload这个头告诉浏览器在接下来的一年内该域名的所有请求都必须用HTTPS。includeSubDomains覆盖所有子域名preload表示可以申请加入浏览器预加载列表连第一次HTTP请求都不会发出。5. 第三方依赖与供应链安全5.1 npm生态的依赖风险现代前端项目动辄几百个npm包直接依赖可能只有几十个但传递依赖能到上千个。这些包来自全球各地的开发者质量参差不齐。一个包被投毒整个项目就沦陷了。2018年有个著名事件某个流行的npm包被作者注入恶意代码会窃取用户的比特币钱包信息。这个包被下载了数百万次影响范围极广。还有更隐蔽的攻击者注册和知名包名字很像的包比如cross-env和crossenv开发者手滑打错字就中招了。防御供应链攻击首先要锁定依赖版本。package-lock.json和yarn.lock必须提交到版本库确保每次安装的依赖树完全一致。其次要定期审计依赖npm audit npm audit fixnpm audit会检查依赖中的已知漏洞并给出修复建议。对于无法自动修复的要评估风险必要时手动升级或替换。还可以用npm outdated查看哪些包有新版本定期更新。但更新前要在测试环境充分验证避免引入破坏性变更。5.2 第三方脚本的安全管理很多项目会引入第三方脚本比如统计工具、客服插件、广告SDK。这些脚本运行在页面里拥有和自家代码一样的权限能读取DOM、cookie、localStorage。如果第三方脚本被入侵后果不堪设想。管理第三方脚本第一要限制来源只从可信CDN加载。第二要用SRISubresource Integrity校验文件完整性script srchttps://cdn.example.com/lib.js integritysha384-xxxxxxxxxxxxxxxxxxxxxxxx crossoriginanonymous/scriptintegrity值是文件的哈希浏览器加载后会校验不匹配就拒绝执行。crossoriginanonymous表示跨域请求不带凭证。第三对于非关键的第三方脚本可以异步加载避免阻塞页面。还可以用iframe沙箱隔离限制其访问父页面的能力。注意SRI只对静态文件有效如果第三方脚本是动态生成的SRI无法使用。这时候只能靠CSP限制来源并定期审查第三方脚本的行为。6. 敏感信息泄露与前端存储安全6.1 前端存储的坑前端能用的存储机制有好几种cookie、localStorage、sessionStorage、IndexedDB。每种都有适用场景但用错了就是安全隐患。cookie会自动随请求发送所以适合存session标识但要设置HttpOnly、Secure、SameSite。localStorage容量大适合存不敏感的用户偏好但XSS能直接读取。sessionStorage和localStorage类似但关闭标签页就清空。IndexedDB适合存大量结构化数据同样受同源策略保护但XSS也能访问。绝对不要把敏感信息存在前端。API密钥、数据库密码、用户密码明文这些都不应该出现在前端代码或存储里。有些同学图省事把API密钥写在JS文件里以为压缩混淆就安全了。实际上打开开发者工具就能看到混淆只是增加阅读难度不是加密。6.2 源码泄露与Source Map生产环境的Source Map是个双刃剑。它能帮助定位线上错误但也可能泄露源码结构和业务逻辑。如果Source Map文件被公开访问攻击者能还原出接近原始的代码发现潜在漏洞。我的做法是生产环境生成Source Map但只上传到错误监控平台不部署到CDN。或者用hidden-source-map模式生成map文件但不添加引用注释只有知道文件名的人才能访问。// webpack.config.js module.exports { devtool: hidden-source-map, // 其他配置 };另外要确保.env文件、配置文件、备份文件不会被部署到Web目录。Nginx配置里加上规则禁止访问.开头的隐藏文件和常见备份后缀location ~ /\. { deny all; } location ~* \.(env|log|bak|sql|zip|tar\.gz)$ { deny all; }6.3 错误信息与日志泄露开发环境的详细错误堆栈对调试很有帮助但生产环境必须关闭。一个未捕获的异常可能把数据库表名、文件路径、框架版本都暴露出来。攻击者收集这些信息后能更有针对性地发起攻击。前端要做的是统一错误处理给用户展示友好的提示同时把详细错误上报到监控平台。不要直接把error.stack渲染到页面上。window.addEventListener(error, (event) { // 上报到监控平台 reportError({ message: event.message, filename: event.filename, lineno: event.lineno, colno: event.colno, stack: event.error?.stack }); // 给用户展示友好提示 showFriendlyMessage(页面出了点小问题请稍后重试); // 阻止默认的控制台输出 return true; });7. 常见问题与排查技巧实录7.1 安全自查清单项目上线前我习惯过一遍下面这个清单。每项都确认过心里才踏实。检查项检查内容风险等级XSS防护所有用户输入是否经过编码或净化高CSP配置是否设置了合理的Content-Security-Policy高CSRF防护敏感操作是否有Token或SameSite保护高点击劫持是否设置了X-Frame-Options或frame-ancestors中依赖安全是否运行过npm audit且无高危漏洞高敏感信息前端代码和存储中是否包含密钥或密码高HTTPS是否全站HTTPS并配置HSTS高Source Map生产环境是否隐藏或限制访问中错误处理生产环境是否关闭详细错误输出中第三方脚本是否使用SRI且限制来源中7.2 排查XSS的实用技巧遇到疑似XSS的问题我一般按这个顺序排查。先看数据流用户输入从哪来经过哪些处理最终插入到哪里。重点检查innerHTML、outerHTML、document.write、eval、setTimeout字符串参数这些危险API。然后看编码插入HTML内容区用HTML实体编码插入属性用属性编码插入JS用JS编码。很多漏洞是因为编码方式用错了比如把用户输入直接拼进onclick属性里HTML实体编码在属性里会被解码等于没编码。最后看CSP打开开发者工具看Console里有没有CSP违规报告。如果有说明有脚本被拦截了可能是攻击尝试也可能是自己的代码需要调整。7.3 依赖漏洞的应急处理npm audit报出高危漏洞时先别慌。第一步看漏洞详情确认影响范围。有些漏洞只在特定条件下触发如果你的项目没用那个功能风险就低。第二步看有没有修复版本有就升级。第三步如果暂时无法升级看能否通过配置或代码调整规避。我遇到过一种情况某个依赖的漏洞需要升级大版本才能修复但大版本有破坏性变更短期升不了。这时候的临时方案是用overrides字段强制指定子依赖的版本{ overrides: { vulnerable-package: ^2.0.1 } }这个字段在npm 8.3以上支持能强制所有依赖使用指定版本。但用之前要测试确保不会引入兼容性问题。7.4 安全与体验的平衡做安全防护最怕的是为了安全把用户体验搞崩。CSP配得太严内联脚本全挂SameSite设成Strict从外部链接跳转过来登录状态就丢了CSRF Token过期时间太短用户填个长表单提交就失败。我的经验是安全策略要分层核心操作严格非核心操作宽松。比如支付、改密码、授权登录这些必须强验证浏览、搜索、看公开内容可以适当放宽。CSP可以用Report-Only模式先跑一段时间收集违规报告确认不影响正常功能后再强制启用。Content-Security-Policy-Report-Only: default-src self; report-uri /csp-report这个头不会拦截任何内容只上报违规行为。观察一两周把误报处理完再切换到强制模式。8. 把安全变成开发习惯写了这么多其实核心就一句话前端安全不是某个阶段的任务而是贯穿开发全流程的习惯。写组件的时候多想一步“这个数据来自用户我转义了吗”引入依赖的时候多看一眼“这个包靠谱吗”配置服务器的时候多检查一遍“响应头设对了吗”。我自己的做法是在项目里建一个SECURITY.md把上面那些检查项和配置示例都记进去。每次新项目启动直接复制过来按清单过一遍。新同学入职也让他们先读这个文档知道哪些线不能踩。还有一个习惯是定期做安全演练。找个测试环境自己尝试构造XSS payload、CSRF请求、点击劫持页面看看防护措施是否生效。这种实战比看文档印象深得多。最后分享一个我常用的XSS测试payload集合放在测试环境里验证防护效果img srcx onerroralert(1) svg onloadalert(1) a hrefjavascript:alert(1)click/a iframe srcjavascript:alert(1) div stylebackground:url(javascript:alert(1)) input onfocusalert(1) autofocus details open ontogglealert(1)这些payload在测试环境跑一遍如果都被拦截或转义了说明防护基本到位。如果有一个弹窗就顺着数据流往回查找到漏洞点修复。安全这件事做得好没人夸出了事就是大事。与其事后救火不如平时多花点时间把基础打牢。上面这些内容都是我这些年踩坑踩出来的经验希望能帮你少走点弯路。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
