Check CORS headers and preflight releases

CORS applies to a specific origin

Browsers limit the reading of answers between different origins. An origin consists of protocol, host and, if applicable, port. https://app.example.org is therefore different than http://app.example.org. Enter the origin of your calling application, not the complete URL of a subpage. The tool sends this value as an origin header.

What the Test Actually Sends

For diagnosis, a GET request and an OPTIONS preflight are sent without cookies or access data. A selected method, such as PUT, is only announced in the Access Control Request Method header and is not executed. Therefore, the GET response cannot confirm the actual response headers of a later POST or PUT call. Redirects are not tracked and must be viewed separately.

Treat Wild Cards and Credentials Properly

Without access data, Access-Control-Allow-Origin: * can suffice. With credentialed requests, you need a suitable specific origin and access control-allow credentials: true. Wildcards for methods or headers also have a different meaning. Authorization must be explicitly released. A dynamically returned origin should be considered when caching together by Vary: Origin.

A release is not a security assessment

CORS does not replace authentication or CSRF protection. A very broad release is not automatically correct for your product, even if the browser allows access to it. The checker evaluates the entered combination and does not send secret header values. Finally, check in the browser of your application whether authentication, redirects and actual method work together. Basics Explained MDN on CORS.

Frequent questions