Re: [whatwg/fetch] Listing headers safe only for certain values is a bad idea (#313)

So, in summary,

- Regarding effectiveness in guiding server authors to learn attack vectors carefully
  - I doubt that whitelisting in client side enforcement logic is very effective
  - We could require server side to announce whitelist of header values for each header. This is effective, but I don't think it's realistic approach.
  - We could just make value validation in UA stricter (either only for cross-origin or both same and cross origin) so that UA throw for header values considered to be bad without sending the request. This is also not realistic due to compatibility.
- Regarding effectiveness in protecting vulnerable servers from attacks in place of server authors
  - Even if we make the CORS preflight condition stricter, it would be just a temporary resolution. Unless developers are enforced to make the right checks before making their server emit "Access-Control-Allow-Headers", some of them would do only "Access-Control-Allow-Headers" implementation.

So, I think triggering CORS preflight for non-safelisted headers (protecting server developers temporarily and give chance to stop and think) is the best we can in web browser side, and the rest (implement the right validation before starting responding to CORS preflight) should be the responsibility of the server side.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/313#issuecomment-245828914