Intent to Ship: Remove Authorization header upon cross-origin redirect

[Kenichi Ishibashi]

Contact emails

ba...@chromium.org

Specification

https://fetch.spec.whatwg.org/#http-redirect-fetch

Summary

Remove Authorization header on cross origin redirects to scope a developer-controlled Authorization header to the origin of the initial request.

Blink component

Blink>Loader

TAG review

Not applicable, the spec has been already updated.
https://github.com/whatwg/fetch/pull/1544

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low. All browser vendors agreed with this change.

Gecko: Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1802086)

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=230935) Historically Safari always removed Authorization headers even for the same origin redirects. Recently the behavior has changed to preserve them on same origin redirects.

Web developers: No signals

Other signals:

WebView application risks

N/A

Debuggability

Web Developers can use DevTools network panel to see the actual request headers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/xhr/xhr-authorization-redirect.any.html?label=master&label=experimental

https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=experimental

Flag name

Not applicable

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1393520

Estimated milestones

M112

Anticipated spec changes

The spec has been already updated.

https://github.com/whatwg/fetch/issues/944

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5195900413018112

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

Any use counters on how often this happens?

On Thursday, February 2, 2023 at 8:58:35 AM UTC+1 Kenichi Ishibashi wrote:

Contact emailsba...@chromium.org

Specificationhttps://fetch.spec.whatwg.org/#http-redirect-fetch

Summary

Remove Authorization header on cross origin redirects to scope a developer-controlled Authorization header to the origin of the initial request.

Blink componentBlink>Loader

TAG review

Not applicable, the spec has been already updated.
https://github.com/whatwg/fetch/pull/1544

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Low. All browser vendors agreed with this change.

Gecko: Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1802086)

Do we know if they ran into any compat issues when shipping this?

 

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=230935) Historically Safari always removed Authorization headers even for the same origin redirects. Recently the behavior has changed to preserve them on same origin redirects.

That's encouraging in terms of lack of potential reliance on these headers.

 

Web developers: No signals

Other signals:

WebView application risks

N/A

Debuggability

Web Developers can use DevTools network panel to see the actual request headers.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests?Yes

https://wpt.fyi/results/xhr/xhr-authorization-redirect.any.html?label=master&label=experimental

https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=experimental

Flag nameNot applicable

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1393520

Estimated milestones

M112

Anticipated spec changes

The spec has been already updated.

https://github.com/whatwg/fetch/issues/944

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5195900413018112

[Kenichi Ishibashi]

Quick update, we added a use counter to see how often this could happen. I'll get back once we have data.

On Wed, Feb 8, 2023 at 11:51 PM Yoav Weiss <yoav...@chromium.org> wrote:

Any use counters on how often this happens?

On Thursday, February 2, 2023 at 8:58:35 AM UTC+1 Kenichi Ishibashi wrote:

Contact emailsba...@chromium.org

Specificationhttps://fetch.spec.whatwg.org/#http-redirect-fetch

Summary

Remove Authorization header on cross origin redirects to scope a developer-controlled Authorization header to the origin of the initial request.

Blink componentBlink>Loader

TAG review

Not applicable, the spec has been already updated.
https://github.com/whatwg/fetch/pull/1544

TAG review statusNot applicable

Risks

Interoperability and Compatibility

Low. All browser vendors agreed with this change.

Gecko: Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1802086)

Do we know if they ran into any compat issues when shipping this?

None I'm aware of. I checked the bug and related issues in GitHub but I didn't find anything.

[Kenichi Ishibashi]

Use counter reports 0.022%. My guess is that most usage happens accidentally but we are not sure.

API owners, should we do a reverse OT?

[Yoav Weiss]

One option to tighten the potential for breakage would be to e.g. sample 10 URLs that are hitting that usecounter (e.g. from the HTTPArchive data), and test them manually to see how many of them would break once this change is applied. Based on the number you'd get, we can estimate the magnitude of breakage we can expect to see in the wild.

Another option would be to roll this out with a base feature flag (that we'd want anyway) and be ready to revert if breakage is more than we'd like.

Combining those two options is probably safest.

[Kenichi Ishibashi]

Thank you Yoav for the suggestion. I couldn't find sample URLs from the HTTPArchive data (feature usage). I'll add a feature flag to prepare for reverting this change if breakage is problematic. 

[Yoav Weiss]

It's possible that we need to wait for the next HA run to get actual examples.

+Rick Viscomi would know..

[Rick Viscomi]

Am I reading the feature page correctly that it'll land in stable version 113? If so, HTTP Archive wouldn't pick that up until the May crawl.

cc @Patrick Meenan to keep me honest

[Patrick Meenan]

Looks like the feature flag was added Feb 16 which looks like it should have made the 112 branch point.  If we hold the April crawl back a couple of days and start it on the 4th after stable is released then we can pick it up in April, otherwise it would show up mid-crawl.

[Patrick Meenan]

Do we expect the Authorization header to be something that the HTTP Archive triggers in a way that the feature will trigger?  Since they are all unauthenticated single page loads, it feels like it's unlikely to be something that we hit.

[Yoav Weiss]

The way I see this, given that the usecounter is an order of magnitude higher than what we can consider trivial, we have 3 options:

1) Add the usecounters to UKM, run an analysis on early data to extract URLs that use this, and randomly sample those for manual inspection.

2) Wait for the HTTPArchive crawl to run with this usecounter, assuming that unauthed landing pages will trigger it.

3) Run an HA query that tries to find cross-origin redirects with Auth headers. I'm not sure how easy (or feasible) that would be, but Rick and Pat would know

To me, (1) seems to be the easiest, and with the least amount of potential bias (all pages vs. unauthed landing pages).

[Yoav Weiss]

Friendly ping on the above :) Does (1) sound reasonable from your perspective?

[Kenichi Ishibashi]

Hi Yoav,

Sorry I haven't sent an update in this thread. (1) sounds reasonable. I added the usercounters to UKM a few weeks ago and I'm waiting for data. I will report back after manual inspections are done.

Thanks,

[Yoav Weiss]

Sounds great, thanks!! :)

[Yoav Weiss]

Friendly ping! :) Any news on UKM data here?

[Ioan-Cristian Linte]

Any updates on this?
Other browser have already made the change for some time so it's surprising that Chrome is so worried about breaking change.

The Authorization propagating in cross origin redirects is causing a performance issue for us. Our server redirects to AWS S3 with pre-signed url and this will return 400 error as AWS S3 disallows specifying multiple authorizations (e.g. signature in url and Authorization header) in a request. Also the 400 error response includes a close connection header. To make this work, the web client checks for the 400 error and uses the response.url to make a new fetch request without the Authorization header. Because the previous connection was closed this incurs the cost of initiating a new connection.

[Kenichi Ishibashi]

Hi, sorry for the long delay.

The feature page now shows sites that use Authorization header for cross-origin redirects. I randomly picked some of them and examined to see if they could work when Chrome removes Authorization header up on cross-origin redirects. As far as I can tell, none of them are broken. We would like to ship this behind a feature flag.

Thanks,

[Yoav Weiss]

LGTM1

On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

Hi, sorry for the long delay.

The feature page now shows sites that use Authorization header for cross-origin redirects. I randomly picked some of them and examined to see if they could work when Chrome removes Authorization header up on cross-origin redirects. As far as I can tell, none of them are broken. We would like to ship this behind a feature flag.

Thanks for the analysis!

As you pointed out elsewhere, since our previous discussions on this thread, this was shipped by Firefox and Safari. 

I think that changes the risk calculus (from compat to interop) and makes shipping this (with a base feature just in case) the right choice.

[Mike Taylor]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org.

[Tom Komarnicki]

Hey,

Sorry for necro'ing this thread, I'm aware that this has been on the "done" pile for a while - and maybe it should've been brought up earlier, but how do you "disable" this feature ? It's making the BE dev exhaustingly painful, not being able to intercept requests and re-forward them to the local BE.
Is there a flag, or whatnot, to re-enable the old flow ?
Thanks

[Yoav Weiss (@Shopify)]

On Mon, Apr 15, 2024 at 2:18 PM Tom Komarnicki <tomkom...@gmail.com> wrote:

Hey,

Sorry for necro'ing this thread, I'm aware that this has been on the "done" pile for a while - and maybe it should've been brought up earlier, but how do you "disable" this feature ? It's making the BE dev exhaustingly painful, not being able to intercept requests and re-forward them to the local BE.
Is there a flag, or whatnot, to re-enable the old flow ?

Can you expand on the issue you're hitting? By "BE" do you mean backend? Or something else?

[Tom Komarnicki]

Hi there,

Here's the scenario I'm dealing with:

I'm a backend developer working on a system with two distinct parts that typically don't intersect during development. The frontend is hosted online, and that's the only place I can access it. When something goes wrong on the backend I'm developing, I usually relied on chrome extensions re-routing my traffic to my localhost using a Chrome extension. This used to work fine, but recently, I've been encountering a 401 error due to the authorization header missing from the redirected request.

Now, I'm left with two options: either manually extract data from the developer console or use tools like Fiddler and send requests via Postman to a locally hosted server. Both methods are quite time-consuming compared to the previous setup.

I'm wondering if there's a way to configure Chrome to retain all headers on redirect, as it used to function before. This would streamline the debugging process significantly.

Thanks!

[Mike Taylor]

It's possible that DevTools could support this use case, so I'd encourage you to a feature request at crbug.com/new. Thx

[David Benjamin]

Keep in mind also that cross-origin and same-origin requests generally behave very differently on the web, not just in this specific way. So if you're redirecting a portion of your origin in your dev environment, other things will also behave differently. I recognize that's not how your current dev environment works, and I gather none of the other differences had impacted you thus far. But if we could enable a setup where they appear at the same origin in the browser, your dev environment would more accurately reflect production.

For example, perhaps your backend server could proxy the frontend portions from the real frontend, so that it would all appear at the same origin. I think you wouldn't need any browser help to achieve that one. Or perhaps (I don't work on DevTools, so I'm just spitballing) there could be some DevTools features to configure some kind of transparent redirection of URL patterns on the browser side.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f208e74a-4f78-48c4-bdff-f4a847d08447%40chromium.org.

[Patrick Meenan]

FWIW, this is already possible in an extension using the devtools protocol support.  Fetch.continueRequest lets you rewrite outbound requests to go to different destinations, modify headers, etc.  It is what WebPageTest uses to allow you to point a production site to a dev instance (while keeping the origin the same as production). Extensions can have access to the devtools protocol so the existing extension should be able to be modified to do what you need it to do.