Unsafe `Access-Control-Allow-Headers` behavior

[jyxjjj]

I found this at laravel 12.17.0 with php-cors 1.3.0
path: vendor/fruitcake/php-cors/src/CorsService.php

$this->allowAllHeaders = in_array('*', $this->allowedHeaders);

if ($this->allowAllHeaders === true) {
    $allowHeaders = (string) $request->headers->get('Access-Control-Request-Headers');
    $this->varyHeader($response, 'Access-Control-Request-Headers');
}

$response->headers->set('Access-Control-Allow-Headers', $allowHeaders);

And this at MDN

Any header. The value * only counts as a special wildcard value for requests without credentials (requests without [HTTP cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) or HTTP authentication information). In requests with credentials, it is treated as the literal header name * without special semantics. The [Authorization](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization) header doesn't accept wildcard and always needs to be listed explicitly.

So we should check if supports_credentials is true to generate Access-Control-Request-Headers right?

[jyxjjj]

Therefore, to match the behavior defined by the CORS specification and enforced by modern browsers, maybe we need to check supports_credentials before reflecting Access-Control-Request-Headers when * is used in Access-Control-Allow-Headers.
And warning it will be a break feature.

[barryvdh]

I think we return the list of headers (and methods and origins) especially to work around the limitation of the browser.
We could simplify it however by returning the explicit * wildcard value when no credentials are used, similar to the behavior for the origins:
https://github.com/fruitcake/php-cors/blob/master/src/CorsService.php#L206-L208