Three headers that together define a CORS policy
Allowing origin https://www.veomark.com, methods GET, POST, OPTIONS, and no credentials produces: Access-Control-Allow-Origin: https://www.veomark.com, Access-Control-Allow-Methods: GET, POST, OPTIONS, and Access-Control-Allow-Headers: Content-Type, Authorization.
Access-Control-Allow-Origin set to a specific origin (rather than a wildcard *) is what lets that one origin's browser-based requests succeed while requests from any other origin are blocked by the browser's same-origin policy -- this is the core mechanism CORS uses to selectively open up cross-origin access.
OPTIONS in the allowed methods list matters even if your API doesn't have an OPTIONS endpoint of its own -- browsers automatically send an OPTIONS preflight request before certain cross-origin requests (like ones using custom headers or non-simple methods), and the server needs to respond to that preflight correctly for the actual request to proceed.
Why credentials and wildcard origins don't mix
Static header text. This does not send a real preflight. If Allow-credentials were set to true (allowing cookies or HTTP auth to be sent cross-origin), Access-Control-Allow-Origin cannot be a wildcard * -- browsers specifically reject that combination for security reasons, requiring an exact origin value instead whenever credentials are involved.
This generates static header text for you to add to your actual server configuration or application code -- it doesn't send a real preflight request or verify against a live server, so it can't confirm your actual backend is configured to emit these headers correctly.
Access-Control-Allow-Headers needs to list every custom header your client-side request actually sends (beyond the small set of CORS-safelisted headers) -- Content-Type and Authorization are common examples, but any other custom header your API requires needs to be added to this list or the browser will block the request.
Testing this in a real request flow
This header set works alongside, not instead of, a working server route -- ensure your server or serverless function actually returns these headers on both the preflight OPTIONS response and the real response.
If you're debugging why a request is being blocked, the HTTP Header Parser can help inspect what headers a real response is actually sending back.
Frequently Asked Questions (FAQ)
Why does Access-Control-Allow-Origin need to be a specific URL instead of a wildcard?
A wildcard (*) allows any origin to make the cross-origin request, which is too permissive for most APIs, especially any that handle sensitive data. Setting it to a specific origin like https://www.veomark.com restricts cross-origin access to just that one trusted origin.
Why is OPTIONS in the allowed methods list even though I don't have an OPTIONS route?
Browsers automatically send an OPTIONS preflight request before many cross-origin requests to check whether the actual request is allowed. Your server needs to respond successfully to that automatic preflight, even without a dedicated OPTIONS route of your own, which is why OPTIONS needs to be included in Allow-Methods.
Can I use a wildcard origin together with credentials?
No. Static header text. This does not send a real preflight. Browsers specifically block the combination of a wildcard Access-Control-Allow-Origin with Access-Control-Allow-Credentials: true for security reasons -- credentials require an exact origin value.
Does this tool verify my server is actually sending these headers correctly?
No. It generates static header text for you to add to your own server or application configuration. It doesn't send a real request or preflight to check whether your actual backend responds with these headers.
What should I add to Access-Control-Allow-Headers if my API uses a custom header?
Add the name of every custom header your client sends beyond the standard CORS-safelisted set -- if your API requires a header like X-API-Key, it needs to be explicitly listed here or the browser will block the request during the preflight check.
