fix(@angular/ssr): introduce trustProxyHeaders option to safely validate and sanitize proxy headers#33031
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces the trustProxyHeaders configuration to AngularAppEngine, allowing for explicit control over which X-Forwarded-* headers are trusted during SSR. It replaces the previous header-patching approach with a more efficient sanitization process and adds a mechanism to deoptimize to CSR when certain proxy headers are present but untrusted. Review feedback suggests that the new VALID_PREFIX_REGEX is overly restrictive regarding dots in path segments and that the warning for unconfigured proxy headers should be adjusted to reduce log noise for default allowed headers.
…ate and sanitize proxy headers
This commit adds the `trustProxyHeaders` option to `AngularAppEngineOptions` and `AngularNodeAppEngineOptions` to configure, validate, and sanitize `X-Forwarded-*` headers.
- When `trustProxyHeaders` is `undefined` (default):
- Allows `X-Forwarded-Host` and `X-Forwarded-Proto`.
- Intercepts `X-Forwarded-Prefix` and triggers a dynamic CSR deoptimization to skip SSR if present.
- Logs an informative message when receiving any other `X-Forwarded-*` headers.
- When `false`:
- Ignores and strips all proxy headers from the request.
- When `true`:
- Trusts all proxy headers.
- When a string array:
- Allows only the proxy headers provided inside the array.
Example:
```ts
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'],
});
```
alan-agius4
force-pushed
the
x-forward-prefix-validation-patch
branch
from
d22ebae to
e769eae
Compare
alan-agius4
added
the
action: review
alan-agius4
added
the
target: patch
| }; | ||
| if (trustProxyHeaders === undefined && receivedXForwarded) { | ||
| // eslint-disable-next-line no-console | ||
| console.warn('Received "X-Forwarded-*" headers but "trustProxyHeaders" was not configured.'); |
There was a problem hiding this comment.
Suggestion: Can we provide any more context here? We should at least state that we ignored the header, otherwise it's not clear why we're logging this at all and potentially link to angular.dev if/when we have content there.
There was a problem hiding this comment.
Yeah that's on my list of todos.
| const { redirectTo, status, renderMode, headers } = matchedRoute; | ||
| const { redirectTo, status, renderMode, headers, preload } = matchedRoute; | ||
|
|
||
| if (request.headers.get('x-angular-deopt-csr') === 'true') { |
There was a problem hiding this comment.
Question: Is this covering both the Node and web standard request use cases? Do we need to check this in two places like the other PR does?
There was a problem hiding this comment.
Yes it is as app.ts is common
alan-agius4
force-pushed
the
x-forward-prefix-validation-patch
branch
3 times, most recently
from
01575d6 to
b7281a2
Compare
…y validate and sanitize proxy headers
alan-agius4
force-pushed
the
x-forward-prefix-validation-patch
branch
from
b7281a2 to
e769eae
Compare
2 participants
…
This commit adds the
trustProxyHeadersoption toAngularAppEngineOptionsandAngularNodeAppEngineOptionsto configure, validate, and sanitizeX-Forwarded-*headers.trustProxyHeadersisundefined(default):X-Forwarded-HostandX-Forwarded-Proto.X-Forwarded-Prefixand triggers a dynamic CSR deoptimization to skip SSR if present.X-Forwarded-*headers.false:true:Example: