Re: [whatwg/fetch] What to do about requests that should (maybe) preflight but don't? (#567)

These are the bits you can potentially control in a request:

* URL
* method
* headers
* body

To make a request without a CORS preflight, you can only control a couple of headers and the method has to be either GET or POST. There's no restrictions on the body or URL in that case, but the `Content-Type` header can only be a couple of limited MIME types.

Now browsers sometimes go beyond those restrictions and don't issue a CORS preflight, but whenever this has happened thus far that comes with different restrictions. E.g., for reports the MIME type is fixed (and rather unique), the body is mostly controlled by the browser following the MIME type definition, and methods and headers are also fixed (and not interesting). That makes it highly unlikely those requests could be used for an attack.

It's a little unclean though as the browser effectively has some super powers that are not available (and cannot be made available) to content. And as long as it's not clearly documented it means that browsers end up issuing requests server administrators might not expect (this is also assuming there's no rogue extensions and such in play).

I think the simplest thing to do would be to embrace that it's unclean and clearly document these further same-origin policy exceptions in Fetch and encourage anyone that wants to introduce yet more to first discuss that and strongly consider abiding by the same-origin policy instead (and use CORS preflights if need be). But I'm happy to consider alternatives.

-- 
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/567#issuecomment-316684824