创业前端架构：合规、可信、安全三位一体

　　去年十一，我在杭州西溪那边一个创业公司蹲了两周，帮他们切前端基建——不是做架构图，是真撸袖子改 webpack config、重写 CSP header 生成逻辑、把所有 localStorage 都抠出来打补丁。那天下午四点零七分，王工蹲在机柜前拿手机 flashlight 照着看交换机端口灯，光斑抖得跟心电图似的；我正用 Chrome DevTools 手动删掉第三个重复的 Content-Security-Policy meta 标签，听见隔壁会议室玻璃门“咔哒”一声弹开，李婷端着那杯永远喝不完的桂圆红枣茶进来，杯子底还沾着两粒没化开的红糖渣。

　　我说三位一体站得住？站得住。但不是因为多高明，是优胜劣汰筛出来的。你信不信，三个月后活下来的那三家，没一家是靠「设计文档写得漂亮」撑住的——全靠半夜三点回滚失败、重跑 CI、手撕第三方 SDK 里的 eval 调用、硬塞 X-Content-Type-Options: nosniff 进 nginx.conf 的子配置里。对，就是那种缩进错两格就 502 的子配置。这个我敢打包票，当时我亲手改的，第三行少了个分号，dev 环境不报，预发直接挂掉整个登录态初始化链路，整整十八秒白屏，连 loading 图都懒得画。

　　我原以为把 SRI 加进 script 标签就完事了，结果上线第一天，用户反馈「点不动按钮」。查了一小时，发现是某个埋点 SDK 内部自己拼了 base64 字符串再 eval，而我们开了 strict-dynamic，它一 eval 就被拦了。没人告诉你 strict-dynamic 不拦 inline event handler，但拦所有非白名单哈希的动态执行——这玩意儿文档写得像玄学考题。后来我把那个 SDK 源码 clone 下来，注释全删了，只留三行，重新 build，手动算 sha256 放进 integrity，才算混过去。可这事真解决了吗？没有。它第二天又偷偷加载了个 cdn.jsdelivr.net 的 fallback.js，哈希又对不上……

文章配图，仅供参考

　　还有一次，合规团队甩过来一份《个人信息保护影响评估表》，要求「前端需声明全部数据收集行为并提供实时关闭开关」。技术侧一看：哦，就是加个 toggle？结果开发小张当天就提交了 PR，把所有 track() 包进 if (window.__privacy_switch)。第二天早上九点十五，法务在群里问：「你们这个开关状态，是否同步给服务端？」我愣了三秒，抓起键盘敲了半行 curl，才想起来我们压根没存前端开关状态，更没和后端账号体系对齐。当时桌上那盒鱼香肉丝外卖还剩半盒，米饭冷透了，酱汁渗进一次性饭盒褶皱里，黑一块褐一块的。谁接的电话？财务的老刘，问社保代缴进度，我一边按免提一边想：这个开关，是不是该在 token 里加个 flag？还是走本地 storage + 同步到 user profile 接口？算了，先 reload 页面试试……

　　可信不是靠证书链长度堆出来的，是靠每次发版后，运营妹子截屏发群说「客户说这次跳转不卡了」；安全也不是靠漏扫报告绿条多少，是靠某天凌晨一点四十七分，微信弹出一条预警——不是来自阿里云盾，是我们自己写的那个简陋的 js 错误聚合脚本，捕获到某台 iPad 上连续三次触发 one rror，错误堆栈里嵌着一个 src 值为 data:text/html;base64,…… 的 iframe。我们追下去，发现是竞品爬虫注入的伪装页面，试图窃取 window.location.href —— 它没偷到，但暴露了我们没对 document.write 做任何拦截。后来补了一行 if (location.protocol === 'data:') throw new Error('wtf')，上线前我还特意试了三次：chrome devtools console 里输 document.write('…')，果然炸了。这个我说不准是不是最佳实践，但它确实挡住了那一波，就那三天。

　　说到 iPad……上个月我去深圳见另一家，他们前端用 Vue3 + Pinia + 一套自研的微前端沙箱。我坐那儿听他们讲“隔离模型”，突然看见 QA 小姐右手无名指指甲缝里嵌着蓝黑色油墨，估计是刚修过打印机——她边点头边搓手指，把那点蓝黑搓成了灰白。我没插嘴，等他们说完才问：「沙箱拦截了 postMessage 里的 Blob 吗？」全场静了五秒。最后他们运维兄弟挠着后颈说：“呃……应该…没拦？我们只拦了 eval 和 new Function。” 我点点头，没往下问。其实我想说的是：你沙箱再漂亮，用户拖一个带恶意 Blob 的 PDF 进 drop zone，解压时调了 WebAssembly.instantiateStreaming，照样能绕开所有「隔离」——但那一刻，窗外有辆工程车鸣笛，三长一短，像某种暗号，我忽然不想说了。

　　所以别跟我扯什么「架构先行」「顶层设计」。创业公司的前端安全观，本质上就是一堆故障驱动的临时补丁拼起来的防水布。合规是倒逼你砍掉那些顺手就加的 cookie；可信是逼你在 fetch 里多写两行 response.headers.get('x-trust-level') 判定；安全是逼你把所有 setTimeout(fn, 0) 全替成 queueMicrotask(fn)，就为了躲过 CSP 的 script-src 规则里那个该死的 unsafe-eval 黑名单兜底逻辑。至于优胜劣汰？很简单——扛不住两次监管突击检查的，活不过 Q4；扛不住一次钓鱼邮件导致静态资源被劫持的，连年会都不用参加了。

　　昨天我删掉了自己写了三年的「前端安全 checklist」markdown 文档。里面第二十七条写着「确保 HSTS header 在所有入口页生效」，但实际连主域名都还没上 HSTS preload list。文档太干净了，看着假。我现在只留一个 README.md，第一行就写：「上次失效是在十一期间，原因：nginx 版本低不支持 add_header … always；已降级为 set_header」。后面跟着两个未关闭 issue，标题分别是「CSP 中 unsafe-inline 为什么还在？」和「为啥用户反馈「注销后还能进历史订单页」？」——没写解决方案，只写了：「等审计组来再碰」。

　　现在我在整理一份极简模板：三个 .js 文件、两个 .json 配置、一份必须手写签名的 release note——别的，先别碰。要是你真想试，下周三下午两点，我在老地方，带着那台总在风扇响到第六秒突然停一下的 Macbook Pro。记得带伞，西溪最近老下雨，雨不大，但下得人烦躁。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!