[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f19oxpaobf18fr":3},{"code":4,"message":5,"data":6,"timestamp":24},10000,"success",{"full_name":7,"position":8,"stars_gained":8,"description":9,"language":10,"stars":11,"forks":8,"age_days":12,"hn_threads":13,"one_liner":14,"summary_md":15,"topic":16,"github_topics":19,"license":20,"homepage":21,"updated_at":22,"history":23},"SkyZeroZx\u002Fcorner-shop",0,"Angular 22 SSR + NestJS demo: the trust boundaries of Angular HTTP (DevFest Callao 2026)","TypeScript",64,1,[],"A two-mode Angular SSR demo that makes HTTP trust-boundary leaks visible, for Angular teams learning secure HTTP design.","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.\n\n## The problem\n\nAn 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.\n\n## What's different\n\nThe 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.\n\nThe 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.\n\n## Who should try it\n\nGood 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.\n\n## Requirements and limitations\n\nThe 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](https:\u002F\u002Fgithub.com\u002FSkyZeroZx\u002Fcorner-shop\u002Fblob\u002Fmain\u002FREADME.md) are the place to check exact commands and ports. The attacker config in [config.ts](https:\u002F\u002Fgithub.com\u002FSkyZeroZx\u002Fcorner-shop\u002Fblob\u002Fmain\u002Fapps\u002Fapi\u002Fsrc\u002Fapp\u002Fconfig.ts) and the service worker group in [ngsw-config.json](https:\u002F\u002Fgithub.com\u002FSkyZeroZx\u002Fcorner-shop\u002Fblob\u002Fmain\u002Fapps\u002Fshop\u002Fngsw-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.\n\n## HotRepo's take\n\nHotRepo 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.",{"slug":17,"name":18},"developer-tools","Developer Tools",[],"MIT",null,"2026-10-25T02:59:12Z",[],1792921424]