CORS Header Generator and Tester

A web page can freely display images and run scripts from other sites, but it cannot read the responses of a fetch or XMLHttpRequest to another origin unless that origin agrees. The agreement is called cross-origin resource sharing, CORS, and it is made with response headers. When it goes wrong the browser prints a red error and the call fails, which makes CORS the most common source of confusion for people who build front ends against an API. This page generates the headers and also tests a request against them.

Simple and preflighted requests

The Fetch standard splits requests into two groups. A simple request uses GET, HEAD or POST, no custom headers and a form-like content type; the browser sends it straight away and then checks the response headers before letting the script read it. Everything else, including a JSON body (Content-Type: application/json), a PUT or DELETE, or an Authorization header, is preflighted: the browser first sends an OPTIONS request that asks permission, naming the method and headers, and only sends the real request if the answer approves it.

The headers

Access-Control-Allow-Origin names the one origin that may read the response, or * for any. It cannot list several. Access-Control-Allow-Methods and Access-Control-Allow-Headers answer the preflight. Access-Control-Allow-Credentials: true lets the request carry cookies or HTTP authentication, and it cannot be combined with a wildcard origin, methods or headers. Access-Control-Expose-Headers lets scripts read response headers beyond the basic set, and Access-Control-Max-Age tells the browser how long to cache the preflight result.

What the generator writes

Enter your allowed origins, one per line. For one origin the page writes it directly. For several, it explains the pattern servers must follow: compare the request’s Origin header with your list and echo the match, adding Vary: Origin. The default settings produce Access-Control-Allow-Origin: https://app.example.com, methods GET, POST, OPTIONS, headers Content-Type, Authorization and Access-Control-Max-Age: 600. Pick a server tab to get the same rules as configuration for your platform.

Using the tester

On the Test tab, fill in the page origin where the script runs, the method, any custom request headers, the content type of the body and whether the request includes credentials. Then paste the response headers your server sent to the preflight OPTIONS request, if one is needed, and to the real request. The page walks through the browser’s steps one at a time and reports where it fails: no Allow-Origin header, a mismatched origin, a method missing from Allow-Methods, a header missing from Allow-Headers, or a credentials request combined with a wildcard. Checking the preflight and the actual response separately matches what the browser does.

Limits

CORS governs what browsers let scripts read. It does not stop curl, servers or other programs from calling your API, so it is not authentication or access control. The tester models the Fetch standard and does not send real requests. Configuration snippets are starting points that you should adapt to your stack, particularly for dynamic origin lists.

Related tools

• HTTP Headers to JSON turns pasted response headers into structured data.
• Security Headers Generator and Auditor checks the other protective headers.
• CSP Generator and Evaluator controls where a page itself may connect.
• Cookie Security Auditor checks the cookies that credentialed requests carry.