fix(@angular/ssr): enforce explicit opt-in for proxy headers

[alan-agius4]

This commit introduces a secure-by-default model for trusting proxy
headers (X-Forwarded-*) in the @angular/ssr package. Previously, the
engine relied on complex lazy header patching and regex filters to guard
against spoofed headers. However, implicit decoding behaviors by URL
constructors can render naive regex filtering ineffective against certain
percent-encoded payloads.

To harden the engine against Server-Side Request Forgery (SSRF) and
header-spoofing attacks:

• Introduced the allowedProxyHeaders configuration option to
  AngularAppEngineOptions and AngularNodeAppEngineOptions.
• By default (false), all incoming X-Forwarded-* headers are aggressively
  scrubbed unless explicitly whitelisted via trustProxyHeaders.
• Replaced the lazy cloneRequestAndPatchHeaders utility with a simplified,
  eager sanitizeRequestHeaders that centralizes the header scrubbing logic.
• Hardened verifyHostAllowed to definitively reject parsed hosts that successfully
  carry path, search, hash, or auth components, replacing previously fallible
  regex filters for stringently checked hosts.

BREAKING CHANGE:

The @angular/ssr package now ignores all X-Forwarded-* proxy headers by default. If your application relies on these headers (e.g., for resolving absolute URLs, trust proxy, or custom proxy-related logic), you must explicitly allow them using the new trustProxyHeaders option in the application server configuration.

Example:

const engine = new AngularAppEngine({
  // Allow all proxy headers
  trustProxyHeaders: true,
});

// Or explicitly allow specific headers:
const engine = new AngularAppEngine({
  trustProxyHeaders: ['x-forwarded-host', 'x-forwarded-prefix'],
});

[gemini-code-assist]

Code Review

This pull request implements support for trusting and sanitizing proxy headers (X-Forwarded-*) in the Angular SSR engine. It introduces a new configuration option to specify allowed proxy headers, replaces the request cloning/patching logic with a more performant sanitization utility, and enhances the validation of host and prefix headers. Review feedback identifies a critical naming inconsistency between 'trustProxyHeaders' and 'allowedProxyHeaders' across the public API and various modules, a property access error in the Node engine implementation, and a minor optimization for header name normalization.

[dgp1130]

Overall LGTM, main point of feedback is just making sure the documentation communicates the significance of the option and how and when to use it.

[dgp1130]

Consider: Would it be simpler to normalize false to [] and true to ['x-forwarded-host', ...] at this layer?

[dgp1130]

Question: Are there X-Forwarded-* headers other than the ones we support today which we might be blocking here? Anything else the developer might be using independent of Angular?

[dgp1130]

Consider: Might be helpful to explain in the comment what this is checking for. I assume it's really //foo which we don't want, but we should try to be clear about the intent here.

[dgp1130]

Consider: I'm not sure I fully appreciated this until now, but it feels like a lot of the core logic here is duplicated across the Node and web standard versions of this API. Is there a path to potentially consolidating some of the changes into a single location? At least the security-relevant checks?

[dgp1130]

Question: Just for my own curiosity, is there a particular benefit to using @remarks? Does our tooling do something with that? I've never used that myself.

[dgp1130]

Suggestion: I think we can make this language a little stronger to highlight the need for input sanitization and raise awareness of the security implications.

Suggested change

	trustProxyHeaders?: boolean | readonly string[];
	/**
	* Extends the scope of trusted proxy headers (`X-Forwarded-*`).
	*
	* @remarks
	* **This is a security-sensitive option!**
	*
	* When `trustProxyHeaders` is enabled, request headers such as `X-Forwarded-Host` and
	* `X-Forwarded-Prefix` are trusted by the server and used for routing. These
	* headers must be strictly validated and provided by a trusted client (e.g., at a reverse proxy, load
	* balancer, or API gateway) and must *not* be provided by untrusted end users.
	*
	* If a `string[]` is provided, only those proxy headers are allowed.
	* If `true`, all proxy headers are allowed.
	* If `false` or not provided, proxy headers are ignored.
	*
	* @default false
	*/
	trustProxyHeaders?: boolean | readonly string[];

If / when we add documentation to angular.dev, it might be good to link to it to expand on what this means in practice.

[dgp1130]

Consider: Should we log that we ignored a header in case the developer needs to set trustProxyHeaders?

[dgp1130]

Nit: Feels a little asymmetrical that AngularAppEngine normalizes headers but AngularNodeAppEngine doesn't and instead relies on request.ts to do it. Is it worth doing this at the same level of abstraction for each?