[whatwg/fetch] Tighten `application/x-www-form-urlencoded` CORS safe-list carveout? (Issue #1706)

Right now cross-origin POST requests with the `Content-Type: application/x-www-form-urlencoded` header [are safe-listed](https://fetch.spec.whatwg.org/#cors-safelisted-request-header), and thus don't trigger CORS preflight requests. I believe this is to grandfather-in the fact that you could always make these requests with `<form method=post>` before preflight requests were a thing. However, my understanding is that we generally want these kinds of non-form-initiated requests to require preflights, hence the fact that we require preflights for _other_ content types.

But other specs can simply use the `Content-Type: application/x-www-form-urlencoded` request header to avoid preflights on a request that really should send preflights. In fact, my understanding is that FedCM [did this on accident](https://fedidcg.github.io/FedCM/#ref-for-concept-request-header-list%E2%91%A2) (the spec was **not** trying to bypass the preflight requirement, they just thought it was the most sensible value). However I think it is Fetch's intention to require preflights for these kinds of requests (since they're "new", and not HTML form-initiated), so I'm wondering if we should change Fetch (and its implementations) to actually require preflight requests for POSTs _even if_ they have the `Content-Type: application/x-www-form-urlencoded` request header, but if they are not specifically triggered by actual HTML forms.I'm now sure how Fetch would check this — I assumed we could check "initiator" but there doesn't seem to be a value for forms specifically.

I think that would prevent consumers from using this content-type on _new_, non-form-initiated requests while accidentally bypassing preflight requests without realizing it. Rather, these requests would get a preflight, because they aren't initiated from HTML forms and therefore shouldn't be grandfathered-in in the same way that HTML forms are.

Thoughts?

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

Message ID: <whatwg/fetch/issues/1706@github.com>