SkyZeroZx/corner-shop

A compact, runnable teaching demo rather than a library: spin up an Angular 22 SSR shop plus a NestJS API and an attacker log server, then compare an unsafe mode with a safe mode across five HTTP boundaries. Worth trying if you want hands-on evidence of why interceptor-only thinking fails.

The problem

An Angular team ships an app where an auth interceptor adds a bearer token, SSR builds URLs from request headers, and a service worker caches API responses. Everything looks correct in code review, yet tokens can leave for another origin and one user's order page can render for the next. The demo turns that vague worry into a local reproduction: the same screens in unsafe mode leak through a promo URL, a forged Host header, a redirect, the transfer cache and the service worker; safe mode changes one decision per boundary, and npm run verify prints what leaked in each mode.

What's different

The mechanism is the side-by-side mode switch. Interceptor text stays the same while URL handling, SSR host allowlists, redirects, transfer caching and ngsw-config.json change, so you see the effect of a single decision rather than a rewritten tutorial. An attacker NestJS server logs incoming requests, giving concrete proof: a token arriving at port 9999, or an internal key exposed when the SSR page is rendered with a spoofed Host. The README also documents a narrower xhr2 path used by provideHttpClient(withXhr()) under SSR, where Authorization is forwarded on redirects and loops are not cut; Angular 22 defaults to fetch, and ServerXhr is deprecated and slated for removal in Angular 23, making that path an explicit compatibility trade-off rather than a generic claim.

The cost is scope: this is a demo, not a checklist you install. Labs are tied to Angular 22.2.3 with all patches, and secrets are test data on loopback rather than production configuration. You leave with sharper questions about redirects, Host validation and cache partitioning, not a drop-in fix.

Who should try it

Good fit: Angular developers and reviewers who can run the stack locally and want to see an interceptor decision interact with SSR, edge caches and a service worker on real request traces. It also suits conference follow-up study, since the labs map to a talk's six boundaries. Poor fit: anyone who needs a security solution to apply to another framework or a non-Angular SSR stack, and teams wanting a bundled test suite to wire into CI rather than labs to read and modify. A companion talk is not required to run npm run verify, but a session that walks the boundaries would help interpret the output.

Requirements and limitations

The stack needs Node.js 22.12 or newer (tested with 24.16), and npm run verify needs Chrome or Edge; the app servers themselves are local and use loopback test secrets. Setup follows install, build, then npm start or npm run start:safe; the project instructions are the place to check exact commands and ports. The attacker config in config.ts and the service worker group in ngsw-config.json are the files you will change while exploring, so the work is investigative upkeep rather than install-and-forget. Because the README is excerpted, several safe-mode changes and advisory references are not visible here; check the repository README before assuming which boundaries are covered end to end.

HotRepo's take

HotRepo first tracked the project on 2026-10-24 and observed 64 total stars on the NEW-REPOSITORY board (typescript, #19) on 2026-10-25. That is a one-day snapshot, not a comparable daily series, so persistence of interest cannot yet be judged. Before investing time, verify that the safe mode actually covers the labs you care about by running npm run verify once.