一、安全概述：前端安全的重要性、常见攻击类型概览、安全工程化思维
1.1 为什么前端安全越来越重要？
说实话，五年前我刚入行时，前端安全还是个「边缘话题」。那时候大家觉得，安全是后端的事，前端就是个展示层，能有什么风险？
但现在完全不一样了。你想想看，现在的单页应用（SPA）承载了多少业务逻辑？用户登录、支付流程、敏感数据展示……这些全都在浏览器里跑。一旦前端失守，后果不堪设想。
我在项目中遇到过一家电商公司，他们的前端代码里直接硬编码了管理员的 API Token。结果被爬虫抓到了，整个后台数据被拖走。嗯，这锅前端得背。
前端安全的重要性，说白了就三点：
- 用户数据保护：姓名、手机号、银行卡、身份证……这些一旦泄露，用户可能面临诈骗、盗刷
- 业务逻辑安全：优惠券滥用、刷单、恶意下单，这些攻击往往从前端发起
- 品牌信誉维护：一次安全事件，可能让用户对你彻底失去信任
核心观点：前端不再是「安全盲区」。作为前端工程师，我们必须把安全当成基本功，而不是可有可无的加分项。
1.2 常见攻击类型概览
我整理了一下，前端最常见的攻击类型大概有这几种。每个我都踩过坑，咱们一个一个说。
1.2.1 XSS（跨站脚本攻击）
这是前端安全里的「头号杀手」。攻击者把恶意脚本注入到页面中，然后偷你的 Cookie、篡改页面内容、甚至模拟你的操作。
我记得有一次，一个论坛项目上线后，用户反馈说页面弹出了奇怪的广告。查了半天，发现是评论区没有做转义处理，攻击者直接贴了一段 <script>alert('hack')</script>。嗯，这就是典型的存储型 XSS。
XSS 主要分三种：
| 类型 | 特点 | 常见场景 |
|---|---|---|
| 存储型 XSS | 恶意代码存到服务器，每次访问都触发 | 评论区、用户资料、富文本编辑器 |
| 反射型 XSS | 恶意代码在 URL 中，需要诱导用户点击 | 搜索框、错误页面、URL 参数 |
| DOM 型 XSS | 纯前端漏洞，不经过服务器 | 前端路由、hash 参数、innerHTML 赋值 |
避坑指南：我曾经以为只要后端做了转义就万事大吉。但 DOM 型 XSS 是纯前端问题，后端根本管不到。所以前端自己也得做好防御，别甩锅。
1.2.2 CSRF（跨站请求伪造）
这个攻击很有意思。你登录了银行网站，然后不小心点开了一个钓鱼页面。这个页面偷偷向银行发了个转账请求，因为你的 Cookie 还在，银行就以为是你在操作。
为什么会这样？因为 Cookie 是自动携带的。浏览器不管这个请求是谁发的，只要域名对，Cookie 就跟着走。
我见过一个案例：某社交平台用户发帖时，只需要一个 GET 请求。攻击者就在论坛里贴了一张图片，图片的 src 指向那个发帖接口。结果所有看到这张图片的用户，都莫名其妙发了一条广告帖。
1.2.3 点击劫持
攻击者把目标网站用 iframe 嵌入到一个透明层里，然后诱导用户点击按钮。你以为点的是「领取优惠券」，实际上点的是「删除账号」。
嗯，这个攻击现在少了一些，因为主流浏览器都支持了 X-Frame-Options 头。但如果你在开发内部系统，还是得注意。
1.2.4 供应链攻击
这个比较新，但危害极大。攻击者往你用的 npm 包里植入恶意代码，然后你 npm install 的时候，就把病毒请进了家门。
我记得 2021 年有个叫 ua-parser-js 的包被篡改了，影响了几百万个项目。你想想看，一个你天天用的工具库，突然变成了定时炸弹。
1.3 安全工程化思维
好，讲完了攻击类型，咱们聊聊更重要的东西——思维模式。
很多前端同学觉得安全就是「加几个过滤器」「写几行正则」。但说实话，这种「打补丁」的思路，永远防不住真正的攻击者。
我个人习惯把安全工程化思维总结成三个层次：
1.3.1 默认安全（Secure by Default）
什么意思？就是你在写代码的时候，默认就是安全的。而不是「先写功能，再补安全」。
举个例子：
// ❌ 不安全：先写功能，再考虑转义
function renderComment(text) {
document.getElementById('comment').innerHTML = text;
}
// ✅ 安全：默认使用安全的 API
function renderComment(text) {
const el = document.getElementById('comment');
el.textContent = text; // 自动转义，默认安全
}你想想看，用 textContent 代替 innerHTML，是不是零成本就防住了 XSS？这就是默认安全的力量。
1.3.2 纵深防御（Defense in Depth）
不要依赖单一防线。前端做了输入校验，后端也得做。前端用了 HTTPS，后端也得配好 HSTS。前端做了 CSP，后端也得配合设置响应头。
我见过太多项目，前端觉得「后端会做校验」，后端觉得「前端已经过滤了」，结果两边都没做。嗯，漏洞就是这么来的。
1.3.3 自动化与持续监控
安全不是一次性的工作。你这次修复了漏洞，下次新功能可能又引入新的风险。
我个人建议在 CI/CD 流程中加入安全扫描：
- 使用
npm audit检查依赖包漏洞 - 使用 ESLint 插件检测 XSS 风险
- 使用 Snyk 或 SonarQube 做持续安全监控
小技巧：我习惯在 package.json 的 scripts 里加一条 "precommit": "npm audit"。这样每次提交代码前，都会自动检查依赖安全。虽然有点烦，但真能救命。
1.4 本章小结
这一章咱们聊了三个核心问题：
- 前端安全为什么重要——用户数据、业务逻辑、品牌信誉，一个都不能少
- 常见攻击类型——XSS、CSRF、点击劫持、供应链攻击，每个都有血淋淋的案例
- 安全工程化思维——默认安全、纵深防御、自动化监控，这才是长久之计
说实话，安全这条路没有终点。你永远不知道下一个漏洞会从哪里冒出来。但只要你养成了安全工程化的思维习惯，就能在大多数攻击发生之前，把它们扼杀在摇篮里。
下一章，咱们会深入聊聊 XSS 的防御实战。我会手把手教你配置 CSP、使用 DOMPurify、以及如何用 React/Vue 的安全机制。嗯，到时候见。