Intent to Ship: CORS non-wildcard request-header

[Yutaka Hirano]

(The implementation CL is under review. This intent is written as if it's landed.)

Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink component

Blink>SecurityFeature>CORS

TAG review

Not needed because this implements an existing feature.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones. We have an enterprise policy so that administrators can keep the existing behavior. We're planning to remove the policy on Chrome 103. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals

Debuggability

We'll show a CORS error to the devtools console.

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

Yes

Flag name

CorsNonWildcardRequestHeadersSupport

Requires code in //chrome?

False (or, True only for the enterprise policy.)

Tracking bug

https://crbug.com/1176753

Estimated milestones

97

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742041264816128

[Yoav Weiss]

On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

(The implementation CL is under review. This intent is written as if it's landed.)

Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink component

Blink>SecurityFeature>CORS

TAG review

Not needed because this implements an existing feature.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones.

Can you similarly send deprecation reports as well? How long have the deprecation messages been in place? Did we see any decline in the numbers?

Have we looked into which URLs are triggering this? (and if it's a few medium-sized properties or many tiny ones) 

Did we try outreach?

We have an enterprise policy so that administrators can keep the existing behavior. We're planning to remove the policy on Chrome 103. 2: https://www.chromestatus.com/metrics/feature/popularity#AuthorizationCoveredByWildcard

Gecko: Positive Firefox showed a positive signal in a private thread.

WebKit: Positive Apple showed a positive signal in a private thread.

Web developers: No signals

Debuggability

We'll show a CORS error to the devtools console.

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

Yes

Flag name

CorsNonWildcardRequestHeadersSupport

Requires code in //chrome?

False (or, True only for the enterprise policy.)

Tracking bug

https://crbug.com/1176753

Estimated milestones

97

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742041264816128

--
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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

[Yutaka Hirano]

On Thu, Oct 21, 2021 at 6:25 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Thu, Oct 21, 2021 at 9:55 AM Yutaka Hirano <yhi...@chromium.org> wrote:

(The implementation CL is under review. This intent is written as if it's landed.)

Contact emails

yhi...@chromium.org

Specification

https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Summary

A CORS non-wildcard request header[1] is an HTTP request header which is not covered by the wildcard symbol ("*") in the access-control-allow-headers header. "authorization" is the only member of CORS non-wildcard request-header. Currently we treat the header as a usual header, which is problematic for security reasons. Implement it, and change the current behavior. 1: https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name

Blink component

Blink>SecurityFeature>CORS

TAG review

Not needed because this implements an existing feature.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interoperability risk is low because Mozilla and Apple showed an intent to implement this behavior. There is some compatibility risk, as the use counter[2] shows 0.04% websites would be affected. To mitigate the risk, we've shown a deprecation message for a few milestones.

Can you similarly send deprecation reports as well? How long have the deprecation messages been in place? Did we see any decline in the numbers?

We've shown the deprecation message since Chrome 94 whose beta promotion was on Aug 26 and stable release was on Sep 21. 

We use CountDeprecation which sends deprecation reports automatically IIUC.

I don't see any decline.

 

Have we looked into which URLs are triggering this? (and if it's a few medium-sized properties or many tiny ones) 

I haven't looked at the data.

Did we try outreach?

No.

[Mike West]

I think it's reasonable for us to dig into the data a little bit to determine whether the 0.04% number quoted above will result in user-facing breakage. Yutaka, is that something you'd be willing to dig into?

The direction seems philosophically correct to me, so I'd like to see it ship, but I'd also like to make sure we're not making the web worse for users by doing so.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

[Yutaka Hirano]

Thank you for the feedback.

Do you have concrete steps for the investigation in your mind?

[Yutaka Hirano]

(friendly ping)

[Chris Harrelson]

Would it be feasible to get a random list of 10-20 sites that hit the use counter and see if they are broken badly by this feature?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EqkidJF3mjfnztmMnKrEpb%3DPTvW-kpW0s_bWCM%3DOXY8A%40mail.gmail.com.

[Yoav Weiss]

Friendly ping on Chris' question

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Yutaka Hirano]

Sorry for the delay!

I checked 10 sites. I saw console errors in three sites among them:

 1. https://cchatty.com/

 2. https://techrxiv.org/

 3. https://bodyshake.com/

I only see a visible breakage in 1 (cards in the main panel are invisible). On other sites I don't see any visible differences.

Please note that this feature is related to authorization so it is likely to break things when signing in.

(friendly ping)

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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

--
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/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

--
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.

[Yoav Weiss]

On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <yhi...@chromium.org> wrote:

Sorry for the delay!

I checked 10 sites. I saw console errors in three sites among them:

 1. https://cchatty.com/

 2. https://techrxiv.org/

 3. https://bodyshake.com/

I only see a visible breakage in 1 (cards in the main panel are invisible). On other sites I don't see any visible differences.

Please note that this feature is related to authorization so it is likely to break things when signing in.

So it's possible that the breakage only occurs for logged in users, and is not something you'd be able to see when spot checking their homepage?

[Yutaka Hirano]

On Thu, Dec 2, 2021 at 12:29 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Dec 1, 2021 at 4:00 PM Yutaka Hirano <yhi...@chromium.org> wrote:

Sorry for the delay!

I checked 10 sites. I saw console errors in three sites among them:

 1. https://cchatty.com/

 2. https://techrxiv.org/

 3. https://bodyshake.com/

I only see a visible breakage in 1 (cards in the main panel are invisible). On other sites I don't see any visible differences.

Please note that this feature is related to authorization so it is likely to break things when signing in.

So it's possible that the breakage only occurs for logged in users, and is not something you'd be able to see when spot checking their homepage?

 

Yeah, I think so.

[Mike West]

From my perspective, it's a bit worrying that you found user-visible breakage in a random sampling of the otherwise small number of sites that fall into this category. As Yoav suggested, there's some additional likelihood that we're not seeing some breakage that requires sign-in. It might be worthwhile to raise a deprecation warning for this behavior, and remove it after giving developers some time to adjust, perhaps with an enterprise policy for good measure. I'd be happy with a 3-release timeline, with removal thereafter. That might drive the usage down to the point where we can reasonably remove it. If it doesn't, we might need to do some more research (wiring this counter up to UKM, for instance) to see if we can track down more clear sources of potential breakage.

-mike

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Yutaka Hirano]

We've been showing a deprecation message since 94. Sadly the deprecation message hasn't decreased the usage so far.

(friendly ping)

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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

--
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/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

--
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.

[Yoav Weiss]

Hey Yutaka!

We discussed this at the API owners meeting today (Daniel, Chris, Alex, MikeT and myself).

It seems like the risk here is too high to remove support as is, and a reasonable next step may be to add the metric to UKM and get a more detailed view of which sites are using it and how. That would enable us to better assess breakage, and reach out to those sites to reduce current usage until potential breakage reaches acceptable levels.

One other question that came up: Is the usage related to developers adding the "Authorization" header on their own, or is it something the browser sends under certain circumstances? (e.g. when receiving 401 responses with "WWW-Autenticate" headers)

Would renaming the headers used in such authentication protocols be a useful alternative to consider? I'm guessing that doing that would require server changes as well, so won't necessarily help with cases of existing content, but may help to move newer auth flows to make safer CORS choices.

Cheers :)

Yoav

(friendly ping)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.

[Yutaka Hirano]

Hi Yoav,

Thank you for the suggestions. I'll try to add UKM.

> One other question that came up: Is the usage related to developers adding the "Authorization" header on their own, or is it something the browser sends under certain circumstances? (e.g. when receiving 401 responses with "WWW-Autenticate" headers)

This is only for authorization headers set by scripts (via fetch() and XHR). Authorization headers the browser attaches are out of scope.

(friendly ping)

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/CABihn6G2mzUAH_Ghrqmb1xM7XetfKgB%3DMUkX0DED7yWbL4JfGg%40mail.gmail.com.

--
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/CABihn6GB-CbbCqx0VHa7%3DLoZr%2BZN-O7o7XwTGkxXEYQa9OfupQ%40mail.gmail.com.

--
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.

[Chris Harrelson]

Hi, just checking in on this intent. From the API owners' perspective, we're going to wait for the UKM, thanks.

[Javier Garcia Visiedo]

Hi, 

I'm taking over this issue, currently writing the UKM collection review document. IIUC the ask is to opt in the existing use counter for the feature into a UKM. I was wondering (and sorry for the naive question) what would a UKM add to our research, over the existing counter? Or is the intention to add some other metrics to it? Thanks! 

Cheers

Javier