SkyZeroZx/corner-shop

这是一个可以本地跑起来的教学演示，不是能直接装进项目的安全库。它同时提供 unsafe 与 safe 两套模式，让你亲手看到 token、内部 header 和用户数据在 Angular SSR 的几道边界上怎么漏出去，再对比改一个决策后的结果。

解决什么问题

一个 Angular 应用在代码审查时看起来没问题：auth 拦截器会给请求加 Bearer token，SSR 用请求头拼 URL，Service Worker 缓存了订单接口。但上线后可能出现 token 被发往另一个源、上一个用户的订单页被下一个人看到。这个项目把担心变成可复现的本地场景：同一套页面在 unsafe 模式里通过推广链接、伪造 Host、重定向、transfer cache 和 Service Worker 泄露数据；safe 模式在每道边界改一个决策，npm run verify 会并排打印两种模式各自漏了什么。

有什么不同

核心机制是双模式切换。拦截器代码基本不变，变的是 URL 处理、SSR 的 host 白名单、重定向、transfer cache 和 ngsw-config.json，所以你能看到单个决策的影响，而不是读一篇重写过的教程。项目还带一个 NestJS 写的 attacker 服务，专门记录收到的请求，证据很直接：token 真的到了 9999 端口，或者 SSR 页面用伪造的 Host 渲染后内部 key 被打到日志里。README 还记录了更窄的一条路径：SSR 下 provideHttpClient(withXhr()) 走 xhr2，重定向时会带上 Authorization，也不截断重定向循环；Angular 22 默认用 fetch，ServerXhr 已标记废弃并计划在 Angular 23 移除。这是明确的兼容性取舍，不是泛泛的风险提醒。

代价是范围有限：它只是演示，不是能装上的检查清单。实验绑定在打了全部补丁的 Angular 22.2.3 上，密钥是回环地址上的测试数据，不是生产配置。你得到的是关于重定向、Host 校验和缓存隔离的更具体的问题，而不是一个即插即用的修复。

谁值得试

适合能本地跑起整套服务的 Angular 开发者和代码审查者，想看到拦截器决策如何与 SSR、边缘缓存、Service Worker 在真实请求链路上互相影响。也适合作为会议演讲后的延伸实验，因为实验对应演讲里的六道边界。不适合需要把安全方案套到其他框架或非 Angular SSR 技术栈的人，也不适合想直接接入 CI 的团队——这里给的是实验，需要阅读和修改。不要求看过演讲才能跑 npm run verify，但有人带着走一遍边界会更容易理解输出。

使用条件与边界

整套服务需要 Node.js 22.12 或更高版本（作者用 24.16 测试），npm run verify 还需要 Chrome 或 Edge；应用服务本身跑在本地，密钥是回环地址上的测试数据。流程是安装、构建，然后 npm start 或 npm run start:safe，具体命令和端口以项目说明为准。探索时会改动 attacker 的 config.ts 和 Service Worker 的 ngsw-config.json，所以后续维护更像持续做实验，而不是一次安装后不再管。README 是节选，部分 safe 模式改动和 advisory 引用在这里看不到，动手前最好确认它到底覆盖了哪些边界。

HotRepo 点评

HotRepo 从 2026-10-24 开始跟踪该项目，2026-10-25 在新项目榜（typescript）上看到 64 颗总星、第 19 名。这只是单日快照，不是可比的每日序列，目前无法判断关注度能否持续。投入时间前，先跑一次 npm run verify，确认 safe 模式确实覆盖你关心的那些实验。