[whatwg/fetch] Clarify why omitting CORS headers in the preflight response helps against side-channel attacks (Issue #1588)

## TL;DR

[Section 3.2.3](https://fetch.spec.whatwg.org/#http-responses) contains the following passage:

> A successful HTTP response, i.e., one where the server developer intends to share it, to a CORS request can use any status, **as long as it includes the headers stated above with values matching up with the request**.
> 
> A successful HTTP response to a CORS-preflight request is similar, except it is restricted to an ok status, e.g., 200 or 204.
>
> Any other kind of HTTP response is not successful and will either end up not being shared or fail the CORS-preflight request. **Be aware that any work the server performs might nonetheless leak through side channels, such as timing.** If server developers wish to denote this explicitly, the 403 status can be used, **coupled with omitting the relevant headers**.

(my emphases)

I think this passage would benefit from some clarification. In particular, what useful information a side-channel attacker could glean from the presence of CORS headers in the preflight response is unclear to me. Also, what "this" means in

> If server developers wish to denote this explicitly

is unclear to me.

## More context

As [discussed](https://matrix.to/#/!AGetWbsMpFPdSgUrbs:matrix.org/$OgQ-Mt3qtH6ec-UsIsvNITsVJWuuU-ZQrnvuqhGS0DQ?via=matrix.org&via=mozilla.org&via=igalia.com) with @annevk on https://whatwg.org/chat, clarification of this passage may free developers of CORS middleware libraries to return more CORS headers than they typically do, which would make CORS issues easier to debug. Here is one example.

Suppose Alice configures CORS on `https://alice.com` to allow `https://alice-client.com` with request headers `Authorization`. However, in her client (running on `https://alice-client.com`), she also sends some `Foo` request header:

```javascript
fetch('//alice.com', {headers: {'Foo': 'Foo'}})`
```

Obviously, CORS preflight then fails because the `Foo` header isn't allowed in Alice's CORS config. But most middleware libraries would omit the `Access-Control-Allow-Origin` header altogether from the response. When debugging the CORS error in the browser, Alice would be confronted with an error message like

> Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

which is correct but a bit misleading as to the actual reason why the server didn't respond with the required CORS headers (i.e. that request header `Foo` is not allowed).

In my experience, many CORS-related questions asked on Stack Overflow stem from this design decision. However, this lack of debuggability can be remedied. Browser vendors could produce more verbose/informative messages, but that's probably quite a tall order. Instead, a CORS middleware library could be designed to respond to Alice's preflight request with

```http
Access-Control-Allow-Origin: https://alice-client.com
```
or perhaps with

```http
Access-Control-Allow-Origin: https://alice-client.com
Access-Control-Allow-Headers: authorization
```

Either way, the browser's resulting error message would be much more useful for debugging purposes:

> Request header field Foo is not allowed by Access-Control-Allow-Headers in preflight response.

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

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