前端安全常见漏洞防范

前端安全这事，离我们并不远

很多前端开发者听到“安全”二字，第一反应往往是：“后端去搞防火墙和权限不就行了？我只管画页面、调接口。”但现实是，前端往往是攻击者最先接触到的“门面”。页面一打开，代码就摆在用户眼皮底下，逻辑、路径、临时数据，全都半透明。去年有个朋友创业做活动页，图省事把管理员入口藏在注释里，结果被人扫出来，顺藤摸瓜改了配置，整个活动被薅出几十万优惠券。那一刻他才明白，前端并不是“只读”的展示层，而是攻防的第一道门槛。

XSS：把代码当内容，后果很直接

跨站脚本攻击（XSS）可以说是前端最经典的坑。简单说，就是本该是文字的地方，被人塞进了可执行的代码。我见过一个社区系统，用户昵称没做过滤，有人填了带有脚本的昵称，别人一打开评论区就弹窗、偷 cookie。更狠的是，攻击者把恶意脚本藏在图片链接里，通过外链传播，点开即中招。前端最容易栽在“拼接 innerHTML”和“盲目信任接口返回”这两件事上。就像做菜不洗菜，直接下锅，吃相再好看也容易吃坏肚子。防范的核心思路其实朴素：能文本就别当代码，能过滤就别偷懒，能做白名单就别搞黑名单。

CSRF 和开放重定向：信任是把双刃剑

前端常要和各种链接、跳转打交道，稍有松懈就会掉进 CSRF（跨站请求伪造）和开放重定向的陷阱。前者的典型场景是：用户登录状态下，访问了恶意页面，那个页面悄悄发起了一笔转账或改密请求，因为带着合法 cookie，后端傻傻照办。而开放重定向则是把用户往不可控的地址一推，比如登录完“跳转至原页面”，如果不校验目标域名，攻击者就能把用户引到钓鱼站。我曾见过一个营销页为了省事，用 URL 参数决定跳转地址，被人改成伪装成活动站的域名，一批用户稀里糊涂交了信息。对前端而言，关键不是把链接藏得多深，而是把“不该自动做的事”拦住，比如校验来源、加 token、限制跳转范围。

敏感信息别放明处，代码一查就露馅

前端代码本质上要下发到浏览器，这就决定了它不适合存放关键秘密。可我仍见过有人在页面里写死 API 密钥、测试账号甚至内部路径，美其名曰“方便调试”。更有甚者，把环境配置一股脑打包上线，等到被爬虫抓到，尝试弱口令直接撞进后台。前端常见的误区是混淆“不可见”和“拿不到”：代码压缩、隐藏字段、注释删除，真算不上安全。一个比较务实的做法是把权限和密钥尽量往后收，前端只拿短期令牌，用完即废；同时把关键逻辑做轻量化剥离，让前端即使被看穿，也拼不出完整流程。

依赖和配置：别人的坑，也会埋自己

现在的项目离不开各种库和组件，可依赖一多，漏洞就像“搭便车”一样跟进来。几年前某个被广泛使用的打包工具被植入恶意代码，不少前端项目在不知情的情况下上线了带后门的版本。更常见的是配置松懈：SourceMap 没关，线上错误直接暴露源码路径；调试接口留着，跨域策略设成“*”，等于把家门钥匙插在锁上。依赖升级不及时，就像住在没换锁的小区里，明知有风险却懒得动。安全并不总是宏大叙事，很多时候就是把这些“小门小窗”关好——锁好源、收紧跨域、关掉不必要的暴露，问题就少了一大半。

从前端到安全，其实没有想象中那么远。它不要求每个人都成为黑客，但需要一份“多想一步”的谨慎：多校验一次输入，多问一句“这个数据能不能信”，多确认一次“这个跳转是否可控”。技术会变，漏洞的形式也会翻新，可那些朴素的边界意识，始终是最可靠的防线。做好这些，并不会让页面瞬间变得炫酷，却能让系统在风雨来临时，站得更稳一点。