You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At various times it's suggested that Sec-* or other new headers should be able to bypass the CORS preflight requirement. The problem with this is that servers have limits on the total number of bytes used by headers and the closer browser- and attacker-controlled headers get to this limit the easier it would be to steal infer confidential information, such as cookies. (This is perhaps mitigated somewhat by partitioning, but the scopes are not the same, and partitioning for cookies is fiddly.)
Another problem we ran into when trying to implement Private Network Access for navigation requests is that we would need to send preflight requests before navigating to a less-public IP address space. Navigation requests usually come with a long Accept header that would fail the 128 character length limit for safelisted headers.
I couldn't find any straightforward way to get around this other than adjusting the 128 limit to something larger say 256 globally. Would this make attacking a lot easier? Only exempting requests to less-public IP address space doesn't look easy as it might be complicated to pass this information down to the algorithms that determine the safelisted-ness. Is there another way to get around this restriction?
At various times it's suggested that
Sec-*
or other new headers should be able to bypass the CORS preflight requirement. The problem with this is that servers have limits on the total number of bytes used by headers and the closer browser- and attacker-controlled headers get to this limit the easier it would be to steal infer confidential information, such as cookies. (This is perhaps mitigated somewhat by partitioning, but the scopes are not the same, and partitioning for cookies is fiddly.)#1000 contained some prior discussion on this. WICG/client-hints-infrastructure#100 also raises this.
The text was updated successfully, but these errors were encountered: