From 801011feb47e9db2b11281ac0c1d46f9d72c68a1 Mon Sep 17 00:00:00 2001 From: Alan Agius <17563226+alan-agius4@users.noreply.github.com> Date: Thu, 18 Jun 2026 08:07:14 +0000 Subject: [PATCH] docs: document support for standard forwarded proxy header Update the security guide to document that the Angular SSR request handling pipeline now supports and validates the standard RFC 7239 `Forwarded` header. Previously, only non-standard `X-Forwarded-*` headers were supported for resolving proxy-forwarded protocols, hosts, and ports. With this update: - The standard `Forwarded` header parameters (such as `host` and `proto`) are validated and take precedence over corresponding `X-Forwarded-*` headers when trusted. - The `trustProxyHeaders` option and `NG_TRUST_PROXY_HEADERS` environment variable can be configured to trust the `Forwarded` header. For more details on the implementation, see the corresponding PR: https://github.com/angular/angular-cli/pull/33406 --- adev/src/content/guide/security.md | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/adev/src/content/guide/security.md b/adev/src/content/guide/security.md index d4854d6d89fe..35ffbd4e0a5a 100644 --- a/adev/src/content/guide/security.md +++ b/adev/src/content/guide/security.md @@ -369,17 +369,17 @@ For more information, see the XSSI section of this [Google web security blog pos ## Preventing Server-Side Request Forgery (SSRF) -Angular includes strict validation for `Host`, `X-Forwarded-Host`, `X-Forwarded-Proto`, `X-Forwarded-Prefix` and `X-Forwarded-Port` headers in the request handling pipeline to prevent header-based [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF). +Angular includes strict validation for `Host`, `Forwarded`, `X-Forwarded-Host`, `X-Forwarded-Proto`, `X-Forwarded-Prefix`, and `X-Forwarded-Port` headers in the request handling pipeline to prevent header-based [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF). The validation rules are: -- `Host` and `X-Forwarded-Host` headers are validated against a strict allowlist and cannot contain path separators. +- `Host`, `X-Forwarded-Host`, and the `host` parameter of the `Forwarded` header are validated against a strict allowlist and cannot contain path separators. - `X-Forwarded-Port` header must be numeric. -- `X-Forwarded-Proto` header must be `http` or `https`. +- `X-Forwarded-Proto` header and the `proto` parameter of the `Forwarded` header must be `http` or `https`. - `X-Forwarded-Prefix` header must start with `/` and contain only alphanumeric characters, hyphens, and underscores, separated by single slashes. -- By default, all `X-Forwarded-*` headers are treated as untrusted and are removed from the request. To retain them, they must be explicitly allowed by configuring `trustProxyHeaders`. +- By default, the `Forwarded` header and all `X-Forwarded-*` headers are treated as untrusted and are removed from the request. To retain them, they must be explicitly allowed by configuring `trustProxyHeaders`. -Invalid headers trigger an error log, and unallowed proxy headers are removed from the request. Requests with unrecognized hostnames will result in a `400 Bad Request` is issued. +Invalid headers trigger an error log, and unallowed proxy headers are removed from the request. Requests with unrecognized hostnames will result in a `400 Bad Request` being issued. NOTE: Most cloud providers and CDN providers perform automatic validation of these headers before a request ever reaches the application origin. This inherent filtering significantly reduces the practical attack surface. @@ -436,21 +436,27 @@ IMPORTANT: You can use `*` as a value in `allowedHosts` to allow all hostnames, ### Configuring trusted proxy headers -By default, Angular ignores all `X-Forwarded-*` headers. If your application is behind a trusted reverse proxy (like a load balancer) that sets these headers, you can configure Angular to trust them. +By default, Angular ignores the standard `Forwarded` header and all `X-Forwarded-*` headers. If your application is behind a trusted reverse proxy (like a load balancer) that sets these headers, you can configure Angular to trust them. + +If the `Forwarded` header is trusted, its `host` and `proto` parameters are extracted and take precedence over the corresponding `x-forwarded-host` and `x-forwarded-proto` headers. You can configure `trustProxyHeaders` when initializing the application engine: ```typescript const appEngine = new AngularAppEngine({ - trustProxyHeaders: ['x-forwarded-host', 'x-forwarded-proto'], // Trust specific headers + trustProxyHeaders: ['forwarded'], // Trust the standard Forwarded header +}); + +const appEngine = new AngularAppEngine({ + trustProxyHeaders: ['x-forwarded-host', 'x-forwarded-proto'], // Trust non-standard headers }); const nodeAppEngine = new AngularNodeAppEngine({ - trustProxyHeaders: true, // Trust all X-Forwarded-* headers + trustProxyHeaders: true, // Trust standard Forwarded and all X-Forwarded-* headers }); ``` -For the Node.js variant `AngularNodeAppEngine`, you can also provide the `NG_TRUST_PROXY_HEADERS` environment variable (with comma-separated list of headers as a value) to allow the usage of these headers. +For the Node.js variant `AngularNodeAppEngine`, you can also provide the `NG_TRUST_PROXY_HEADERS` environment variable (with a comma-separated list of headers as a value) to allow the usage of these headers. ```bash {hideDollar} export NG_TRUST_PROXY_HEADERS="X-FORWARDED-HOST,X-FORWARDED-PREFIX"