Tighten application/x-www-form-urlencoded
CORS safe-list carveout?
#1706
Labels
application/x-www-form-urlencoded
CORS safe-list carveout?
#1706
Right now cross-origin POST requests with the
Content-Type: application/x-www-form-urlencoded
header are safe-listed, 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 (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 theContent-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?
The text was updated successfully, but these errors were encountered: