fix(http): preserve redirect provenance in HTTP transfer cache - #70946

This a duplicate of #69531
And see #69531 (comment).

As note I don't think this can be considered a security more than harderning.

Also to reject a redirect you can use redirect: 'error'

Thanks for pointing me to #69531. I reviewed its TransferCache changes and agree that there is overlap around HttpResponse.redirected.

There is one behavior in this PR that #69531 does not appear to cover, though: preserving the final response URL separately from the request URL.

#69531 stores redirected and the Fetch response type, but the reconstructed HttpResponse.url still comes from REQ_URL.

The regression here specifically exercises a case where those URLs differ:

request:
https://app.example/api/runtime-config

actual SSR response:
redirected = true
url = https://attacker.example/runtime-config.json

Current TransferCache replay produces:

redirected = undefined
url = https://app.example/api/runtime-config

With the redirected preservation from #69531 alone, the replay would still be approximately:

redirected = true
url = https://app.example/api/runtime-config

so an interceptor which intentionally follows redirects but validates the final origin would still lose the destination needed for that decision.

Angular's interceptor documentation also describes using event.redirected together with event.url for redirect handling, including security checks.

Regarding redirect: 'error': I agree that this is an effective mitigation when the application's intended policy is to reject every redirect. The case here is different: an application allows redirects but applies policy to the final destination, for example allowing an expected redirect while rejecting an unexpected cross-origin one.

The security-relevant framework behavior reported through OSS VRP is the change in the result of the same application policy across the SSR/hydration boundary:

actual SSR response:
redirected = true
final URL = unexpected origin
→ interceptor rejects

TransferCache replay:
redirect provenance/final destination is lost
→ same interceptor accepts

The report also contains an end-to-end credential-disclosure consequence under additional application prerequisites. I'm not claiming that Angular applications generally leak credentials; the underlying framework behavior is the provenance change above.

I also updated this PR to take the TransferState payload concern raised on #69531 into account. Redirect provenance is now serialized only when meaningful:

...(responseUrl !== null && responseUrl !== requestUrl
  ? {[RESPONSE_URL]: responseUrl}
  : {}),
...(redirected === true ? {[REDIRECTED]: true} : {}),

Therefore, for a non-redirected response whose final URL equals the request URL, neither additional field is serialized. There is now a regression test for that behavior as well.

Thanks for the review. I've pushed an updated version of the PR and addressed the requested changes.

Changes made:

• Updated the commit scope from fix(common) to fix(http).
• Moved the redirect provenance tests inside describe('transferCacheInterceptorFn') so they use the existing runOnServer / runInterceptor helpers.
• Added a regression test verifying that HTTP_TRANSFER_CACHE_ORIGIN_MAP correctly maps the final response URL when a redirect occurs.
• Replaced the hasOwnProperty assertions with the requested Jasmine toBeUndefined() matchers.
• Rebasing was also done against the latest main.

The focused //packages/common/http/test:test target passes, and the changed files pass formatting and git diff --check.

Regarding the classification as hardening rather than a security issue: understood. For my own understanding, could you clarify what makes this fall on the hardening side?

The reason I ask is that the report demonstrates a case where the same redirect-aware application policy can produce different results across SSR and hydration because the transferred response loses the final response URL / redirect provenance.

Under the additional application prerequisites described in the report, we were also able to demonstrate a conditional credential-disclosure chain: an attacker-controlled redirected response could be accepted from TransferCache during hydration, influence a runtime API base URL, and cause a later application auth interceptor to send a bearer token to the attacker-controlled origin. The same chain was blocked when the real redirect provenance was preserved.

I'm not suggesting that Angular directly leaks credentials in every application, since the token-disclosure step depends on application-specific behavior and the prerequisites described in the report. I'm mainly trying to understand which part of that demonstrated chain is considered outside Angular's security boundary, so I can apply the same criterion to future reports.

Regarding the classification as hardening versus a security vulnerability:

In the context of the framework, a security vulnerability generally refers to a flaw where Angular directly enables an exploit or breaks an internal security boundary (for example, a sanitizer bypass, template injection leading to XSS, or an SSRF triggered by framework internals).

In this case:

1. Fidelity vs. Security Boundary: TransferCache is an optimization mechanism that records HTTP responses on the server and replays them during client hydration to avoid duplicate requests. The issue was primarily a fidelity bug where reconstructed HttpResponse instances dropped metadata (redirected and final url) that was present on the server.
2. Application-Level Preconditions: The potential for security impact (such as token leakage) relies on specific application design choices:
   • An SSR request fetching untrusted/redirectable resources.
   • An interceptor or business logic that chooses to validate destination origins after following redirects rather than rejecting unexpected redirects up front (e.g. redirect: 'error').
   • Downstream logic dynamically trusting the resulting endpoint for sensitive follow-up requests without independent validation.
3. Defense-in-Depth: While preserving redirect provenance allows applications that implement client-side redirect policies to make consistent decisions across SSR and hydration, the framework itself is not vulnerable rather, preserving this metadata provides defense-in-depth and eliminates an unexpected discrepancy between server and client states.

Thanks again.

Can you please address the testing failure. (the internal test one is a flake).

Can you please address the testing failure. (the internal test one is a flake).

Thanks for pointing this out.

I addressed the public testing failure. The issue was that the two new TransferCache symbols, REDIRECTED and RESPONSE_URL, were not yet present in the hydration bundle golden-symbol file.

I updated packages/core/test/bundling/hydration/bundle.golden_symbols.json and rebased again onto the latest main.

I verified the final commit locally:

• //packages/core/test/bundling/hydration:symbol_test passes.
• //packages/common/http/test:test passes.
• Formatting passes.
• git diff --check is clean.

The updated commit has now been pushed.