fix(@angular/ssr): introduce trustProxyHeaders option to safely validate and sanitize proxy headers#33031
Conversation
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'],
});
```
d22ebae to
e769eae
Compare
| if (trustProxyHeaders === undefined) { | ||
| const lower = headerName.toLowerCase(); | ||
|
|
||
| return lower === 'x-forwarded-host' || lower === 'x-forwarded-proto'; |
There was a problem hiding this comment.
Consider: Regarding the question of whether or not we care about other X-Forwarded-* headers, should we do lower !== 'x-forwarded-proxy' instead?
| } | ||
|
|
||
| if (trustProxyHeaders === undefined) { | ||
| if (lowerKey === 'x-forwarded-host' || lowerKey === 'x-forwarded-proto') { |
There was a problem hiding this comment.
Consider: Could we simplify this along the lines of getAllowedProxyHeaderValue like the other PR, but return string | undefined | false with false indicating deopt? Something along those lines?
| }; | ||
| 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.
| 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: This means someone could curl http://example.test/ -H "X-Angular-Deopt-Csr: true" and force the server to return the CSR bundle, which might normally not be allowed. Could that potentially be a separate cache poisoning issue?
| 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?
…
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: