内容摘要：去年秋天，我帮一个做电商的朋友看他的独立站。打开首页，F12一按，控制台里躺着一条没删掉的调试日志，里面赫然写着后台接口的完整路径和一枚测试用的 token。我问他，这 token 过期了吗。他愣了一

去年秋天，网站我帮一个做电商的前端朋友看他的独立站。打开首页，渗透F12一按，网站控制台里躺着一条没删掉的前端调试日志，里面赫然写着后台接口的渗透完整路径和一枚测试用的 token。我问他，网站这 token 过期了吗。前端他愣了一下，渗透说不知道，网站从来没管过。前端我拿这枚 token 直接请求了订单列表接口，渗透返回了最近三十天的网站全部客户姓名、电话和收货地址。前端整个过程不到两分钟，渗透没有用任何扫描器，没有绕 WAF，就是打开浏览器看了一眼。

前端渗透经常被低估。很多人觉得前端就是切图、调样式，安全问题归后端管。这个想法本身就挺危险的。浏览器是攻击者最舒服的入口，因为它天然就在用户侧，所有代码都摊在桌面上，你随便看。后端你还能藏一藏，前端藏不住。

我见过最常见的一类问题，是 source map 没关。开发环境打包时生成了 .map 文件，上线时一并传到了生产服务器。攻击者拿到 app.js.map，等于拿到了你整个项目的源码结构，包括组件命名、接口封装、甚至注释里写的内部系统地址。有一次我翻一个 map 文件，看到注释里写着「TODO: 这里鉴权先跳过，上线前补」。上线了，没补。

另一类是接口泄露。前端代码里硬编码的 API 路径、密钥、第三方服务 token，这些东西在压缩后依然可读。有人觉得混淆一下就行了，把变量名改成 a、b、c。但字符串改不了，URL 改不了，请求结构改不了。你把 fetch('/api/v2/internal/user/list') 混淆成 fetch(a+b+c)，a 的值还是那个路径。打开 Network 面板，请求一发，什么都看见了。

DOM 型 XSS 是另一个重灾区。前端路由拿 location.hash 或者 location.search 直接渲染到页面里，没做转义。攻击者构造一个链接，参数里塞 <img src=x onerror=alert(1)>，用户点开就中招。这种漏洞在后台管理系统里特别多，因为很多管理后台的前端是外包做的，验收时只看了功能通不通，没看安全。我测过一个 CMS 的编辑页面，URL 里 ?title= 后面的内容直接 innerHTML 进 DOM，连基本的编码都没有。用这个漏洞可以偷管理员的 cookie，然后登录后台，然后拿 shell。

还有 postMessage 滥用。跨窗口通信时没校验 origin，任何页面都能给它发消息。配合 window.open，攻击者可以诱导用户点击，然后向目标窗口注入数据。这种漏洞隐蔽，利用链长，但一旦打通，危害不比 XSS 小。

怎么防。前端安全没有银弹，但有几件事必须做。source map 生产环境坚决不传，构建配置里关掉。所有接口调用走后端代理，密钥不落前端。DOM 操作能用 textContent 就别用 innerHTML，实在要用，先过一遍 DOMPurify。postMessage 必须校验 event.origin，白名单写死。CSP 头配上，虽然不能挡住所有攻击，但能提高利用门槛。

最后说一句。前端渗透的门槛比很多人想象的低，低到打开浏览器就能开始。但它的破坏力不比后端小，因为前端往往连着最敏感的用户数据和最核心的业务逻辑。别再把前端当门面了，它也是战场。