CORS Inspector

CORS Inspector

Simulates preflight and actual requests from the server side to quickly diagnose issues with Access-Control-Allow-Origin, Access-Control-Allow-Headers, or credentials.

Server-side real simulation of CORS preflight and actual requests, 6 response headers checked item by item, precise cross-origin configuration error location, with Nginx/Node.js/Spring multi-framework fix code provided.

Related

CORS Header Generator

HTTP Headers Checker

HTTP Request Tester

Redirect Chain Checker

Security Headers Checker

SSL Certificate Checker

Use Cases

  • When browser console shows No 'Access-Control-Allow-Origin' header error, immediately use this tool to detect actual CORS headers returned by the target endpoint
  • During frontend-backend separation project integration, verify backend CORS configuration takes effect correctly, avoiding wasted time blindly changing settings
  • After configuring Nginx, Apache reverse proxy, or API gateways (Kong/APISIX/Spring Cloud Gateway), verify CORS rules are correctly forwarded
  • When credentialed cross-origin requests fail, toggle credentials mode to detect configuration conflicts between Allow-Credentials and Allow-Origin
  • After adding custom request headers (like X-Token, X-Requested-With) requests get blocked, check if they are correctly declared in Allow-Headers
  • PUT/DELETE/PATCH non-simple method cross-origin failures, check if Allow-Methods includes the corresponding method
  • Frontend cannot read custom response headers (like X-Request-Id, X-Total-Count), detect Access-Control-Expose-Headers configuration
  • After CDN acceleration, cross-origin works intermittently, check if Vary: Origin is correctly set to prevent CDN caching wrong responses
  • For production environment occasional cross-origin errors, reproduce problem scenarios and preserve complete response messages for backend investigation
  • When learning CORS principles, observe the effect of each response header through actual requests to deepen understanding of cross-origin mechanisms

How to Use

  1. Enter the complete URL of the endpoint you want to inspect in the target URL input field (supports http/https, path required)
  2. Enter your frontend page's actual origin in the request Origin field (e.g., https://example.com, note: protocol and port required, no trailing path)
  3. Select HTTP request method (GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS), defaults to GET
  4. Add any headers you need to send in the custom request headers area, one per line in format like X-Token: abc123. Content-Type values like application/json (non-simple types) automatically trigger preflight
  5. Check the 'Send credentials' option according to your scenario — must be checked if frontend code uses withCredentials=true or fetch credentials: 'include'
  6. Click the 'Start Inspection' button, the tool will sequentially send OPTIONS preflight request and actual request server-side (if preflight passes or not needed)
  7. Review analysis report: first check overall assessment, then inspect each CORS header status item by item, adjust server configuration based on red error item fix suggestions, then re-test after fixes to verify

Features

  • Server-side real simulation of preflight and actual requests, unaffected by browser cache or extensions for more accurate results
  • Separately display OPTIONS preflight responses and actual GET/POST responses, clearly identifying which step has issues
  • Item-by-item inspection of 6 core CORS response headers: Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials, Expose-Headers, Max-Age, with pass/warning/fail status for each header
  • Intelligent detection of the classic wildcard * vs credentials mode conflict, immediately flagging this most common configuration pitfall
  • Support for custom request Origin, HTTP methods (GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS), and arbitrary custom request headers
  • Toggle credentials mode (Cookie/Authorization headers/TLS client certificates) to simulate withCredentials=true scenarios
  • Automatically verify whether Vary: Origin response header is correctly set to prevent CDN/reverse proxy caching incorrect CORS responses
  • Structured display of preflight cache Max-Age configuration, evaluating performance impact of preflight request frequency
  • Check Access-Control-Expose-Headers configuration to confirm which response headers are readable by frontend JavaScript
  • Provide line-by-line fix suggestions including configuration examples for mainstream server frameworks: Nginx, Apache, Node.js/Express, Spring Boot, Python/Django/Flask
  • Complete raw request/response message logging including status codes, all response headers, and response body preview for deep troubleshooting
  • Automatically identify differences between simple requests and preflighted requests, explaining why your request triggered OPTIONS preflight
  • Detect CORS issues in redirect scenarios (whether Origin changes after 301/302/307/308 redirects)
  • Support HTTPS/HTTP mixed content scenario detection, flagging cross-origin related issues caused by mixed content

FAQ

Why does requesting endpoint work fine in Postman/curl but browser immediately reports cross-origin error?

This is the classic CORS question! Because Postman and curl are not subject to browser Same-Origin Policy at all — they are HTTP clients, not browsers, don't intercept responses, and don't automatically send OPTIONS preflight requests. Cross-origin errors are a browser-specific security mechanism; only the browser JavaScript runtime enforces CORS checks. Postman working only proves the endpoint itself can return data, it doesn't prove CORS configuration is correct. You need to use a browser, or this tool (server-side simulates browser CORS flow) to detect, that's when problems surface.

Is CORS error a frontend issue or backend issue? Who should fix it?

99% of CORS errors are backend configuration issues (or Nginx/gateway layer configuration issues); frontend can do very little. At its core CORS is about the server 'authorizing' browsers to allow cross-origin access via response headers. Frontend can only set withCredentials, set request headers etc., cannot bypass browser security restrictions. Online suggestions like using frontend proxies (devServer proxy, Nginx reverse proxy to same origin) essentially 'trick' the browser into thinking it's same-origin request, not really solving CORS — in production if frontend and backend are different origins backend still needs correct CORS configuration.

Why doesn't my GET request cross-origin fail, but changing to POST/PUT immediately causes cross-origin errors?

Because GET usually satisfies simple request conditions, browser sends request directly; while POST if you send Content-Type: application/json (which 90% of POST endpoints do), that's not a simple request anymore and triggers OPTIONS preflight. Preflight requires server to return correct CORS headers. Many people configure CORS headers only for GET/POST but don't handle OPTIONS method, or OPTIONS response lacks headers, causing errors. PUT/DELETE/PATCH methods themselves are not simple methods and necessarily trigger preflight.

How to solve cross-origin in development environment? What about production?

Development environment options: ① Framework built-in proxy (Vue CLI devServer.proxy, Vite server.proxy, Create React App proxy): proxies endpoint requests to frontend dev server same origin, browser thinks same-origin no cross-origin; ② Disable browser security parameters (like launching Chrome with --disable-web-security flag), only for local temporary testing, absolutely never for normal browsing; ③ Backend configure CORS allowing localhost origin (recommended, consistent with production behavior). Production environment must have backend correctly configuring CORS: configure allowed origin whitelist, properly set Allow-Methods/Allow-Headers/Allow-Credentials, add Vary: Origin, or handle CORS uniformly at gateway/Nginx.

Can Access-Control-Allow-Origin be configured with multiple origins? How to configure multiple domains for cross-origin?

No, Access-Control-Allow-Origin response header can only have one value — either a specific origin (like https://a.com) or *. Browsers don't accept multiple origins (e.g., writing https://a.com,https://b.com is invalid, browsers consider it non-matching). The correct multi-origin configuration approach: server maintains an allowed origin whitelist, on each request read Origin value from request headers, check if that Origin is in whitelist, if yes set Access-Control-Allow-Origin to that specific Origin value, also return Vary: Origin header; if not, don't return CORS headers or return error. Don't try returning multiple Allow-Origin headers or comma-separating multiple values — browsers don't recognize either.

Does OPTIONS preflight request need to return business logic? Can it directly return 204?

OPTIONS preflight request doesn't need to return any business logic or response body — only needs to return correct CORS response headers and 200/204 status code. Browsers receiving correct CORS headers consider preflight passed, they don't read OPTIONS response body content. So best practice is: intercept OPTIONS requests directly at Nginx/gateway layer, return 204 No Content and correct CORS headers without forwarding to backend application server — this reduces backend load and also avoids 405 errors from backends not supporting OPTIONS. But ensure OPTIONS response CORS headers stay consistent with actual request CORS headers.

Why did I set withCredentials: true but cookies still aren't sent?

Credentialed cross-origin requests require three conditions simultaneously: ① Frontend XMLHttpRequest.withCredentials = true or fetch credentials: 'include'; ② Backend response header Access-Control-Allow-Credentials: true; ③ Access-Control-Allow-Origin cannot be *, must be specific origin. All three are required. Also note cookie attributes: cookies must have SameSite=None; Secure set (HTTPS environment) to be carried in cross-origin requests; if cookie is SameSite=Lax or Strict, cross-origin requests won't carry it; cookie Domain attribute must be correctly set; also note impact of third-party cookie policies (Chrome and other browsers have restrictions on third-party cookies).

What's the relationship between CORS and CSRF? Does configuring CORS cause CSRF vulnerabilities?

CORS is relaxing cross-origin access restrictions; CSRF is Cross-Site Request Forgery attack — they are different concepts. Correctly configured CORS doesn't directly cause CSRF vulnerabilities — because CORS only allows JS to read responses, while CSRF is about attackers inducing users to send requests unknowingly (like img tags, auto-submitted forms); these requests send with cookies even without CORS. Defending against CSRF requires CSRF Tokens, SameSite cookies, Origin/Referer validation etc., you can't prevent CSRF by disabling CORS. But if you configure CORS setting Allow-Origin to * and allow credentials, that does amplify CSRF risk — so credential scenarios absolutely cannot use *, must strictly restrict whitelist origins.

Do file downloads, redirects, image/script tag loading have CORS issues?

Normal <img>, <script>, <link> tags loading cross-origin resources (CDN images, JS scripts, CSS) don't have CORS issues by default — these are 'embedded resources' not 'AJAX requests', browsers allow loading but JS cannot read content. However if you want to manipulate cross-origin images in Canvas, or load these resources with fetch/XHR and read content, you need CORS and also add crossorigin attribute to tags. Cross-origin file downloads (a tag click download) also don't require CORS by default. Redirects affect CORS: if OPTIONS preflight request returns 3xx redirect, browsers directly reject (Preflight redirect is not allowed); actual request redirects if cross-origin require each hop to correctly return CORS headers.

How to correctly configure CORS in Nginx? Give a working config example?

Nginx recommended configuration key points: ① Use map directive matching Origin whitelist, dynamically set $cors_origin variable; ② OPTIONS requests directly return 204 without forwarding to backend; ③ add_header remember to add always parameter ensuring error responses also carry headers; ④ Add Vary: Origin; ⑤ Correctly configure Allow-Methods/Allow-Headers/Credentials. Example configurations can be found in this tool's inspection result fix suggestions — we provide validated config snippets for mainstream frameworks including Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin.

After configuring CORS how do I verify it works?

CORS verification steps: ① First use this tool for online inspection, enter URL, Origin, method, headers, credentials options, see if preflight and actual request checks pass; ② Open browser DevTools Network panel, check Disable cache (avoid stale cache interference), trigger cross-origin request, inspect OPTIONS preflight and actual request response headers for correctness; ③ Check Console for any CORS-related errors; ④ Test different scenarios: GET requests without custom headers, POST requests with application/json, PUT/DELETE methods, with/without cookies, with custom headers; ⑤ Simulate OPTIONS request with curl: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint, check response headers are correct.

Why does cross-origin request error in Chrome but work normally in Safari/Firefox? Or vice versa?

Different browsers have implementation detail differences in CORS spec: ① Safari has stricter limits on preflight cache Max-Age (early versions only 600 seconds), and stricter cookie policies (ITP Intelligent Tracking Prevention) potentially causing cross-origin cookie issues; ② Chrome is stricter on wildcard checks with credentials, disallowing * for Allow-Headers/Allow-Methods, while some Firefox versions may be more lenient; ③ Old IE (IE11) uses XDomainRequest instead of standard XMLHttpRequest, CORS implementation has many pitfalls (doesn't support custom headers, only supports GET/POST); ④ Different browsers have subtle differences in Vary header handling, redirect handling, security header processing. Solution is strictly configuring per CORS spec, not relying on any single browser's compatibility behavior.

What value is appropriate for Access-Control-Max-Age? What problems come with setting too long or too short?

Recommended setting between 3600 (1 hour) and 86400 (24 hours). Setting too short (like 60 seconds): preflight cache expires quickly, frequent OPTIONS requests increase latency and server load, impact noticeable on mobile weak networks. Setting too long (like 31536000 meaning one year): if you update CORS configuration (like adding new allowed methods or headers), users' browsers cached old preflight results may take long to expire, causing configuration not taking effect during that period. Also Chrome and Firefox automatically cap values exceeding 86400 seconds at 86400 seconds — setting longer than that has no effect. Development environments can set to -1 to disable preflight cache for easier debugging.

Do WebSocket connections have cross-origin issues? Does CORS apply to WebSocket?

WebSocket (ws:// and wss://) is not restricted by HTTP CORS mechanism because WebSocket is a separate protocol not HTTP AJAX requests. However WebSocket handshake phase is HTTP request, server can check Origin header to decide whether to allow connections — this is WebSocket-layer permission control, not standard CORS but principle is similar. If WebSocket connection is rejected you need to check WebSocket server-side Origin validation config rather than HTTP CORS headers. Libraries like Socket.IO may have their own cross-origin configuration similar but not identical to standard CORS. Additionally other browser APIs like HTTP/2 Server Push, WebRTC have their own permission controls not fully following HTTP CORS.

Are this tool's inspection results consistent with browser behavior? Why do tool checks pass but browser still errors?

This tool server-side strictly simulates browser preflight and actual request flow per W3C CORS specification; CORS header checking logic is basically consistent with modern browsers. If tool passes but browser still errors, possible reasons: ① Browser cached old preflight results or responses, Ctrl+F5 hard refresh or clear cache and retry; ② Browser extensions (ad blockers, privacy protection, security plugins) modified or intercepted requests; ③ Origin, request headers, method, credentials options you filled in the tool don't match actual frontend sends (like frontend actually sends some custom header you didn't add in tool); ④ CDN/proxy node cache inconsistency, tool requested node and browser requested node return different results; ⑤ Browser has special security policies (like HTTPS page requesting HTTP mixed content blocked, local file file:// protocol special restrictions).

Troubleshooting

Browser console reports No 'Access-Control-Allow-Origin' header error, but curl/postman requests show response headers

Server didn't configure CORS headers for OPTIONS method: curl sends GET/POST showing headers, but browser first sends OPTIONS preflight and OPTIONS response lacks headers Server doesn't include CORS headers when returning 4xx/5xx errors: Nginx add_header by default only applies to 2xx and some 3xx, error responses need always parameter Request blocked by WAF/firewall/security plugin intercepting OPTIONS method, blocking response has no CORS headers CDN cached old headerless response (cache pollution from missing Vary: Origin) Browser extensions (ad blockers, privacy protection plugins) modified or intercepted cross-origin request headers

Configured Access-Control-Allow-Origin: * but credentialed (Cookie) requests still error

This is a CORS spec mandatory restriction: as long as request carries credentials (withCredentials: true, cookies, HTTP auth), Allow-Origin absolutely cannot be wildcard * Even if frontend doesn't explicitly set withCredentials, if target domain shares cookies with current domain, browser may automatically include them Not only Allow-Origin cannot be *, Allow-Headers and Allow-Methods also cannot use * in some browsers with credentials Need to simultaneously set Access-Control-Allow-Credentials: true, and Allow-Origin returns specific request origin not *

Preflight OPTIONS request returns 405 Method Not Allowed or 404 Not Found

Backend framework routes only configured GET/POST business methods, no routes handling OPTIONS method Nginx configuration try_files directive intercepted OPTIONS requests returning 404 directly without forwarding to backend API gateway or security group configurations block OPTIONS method considering it 'useless' Frameworks like Spring Boot without CORS support enabled automatically reject OPTIONS requests returning 403 RESTful API design doesn't have separate handlers configured for OPTIONS requests

POST application/json requests keep reporting header not allowed, but Content-Type already added to Allow-Headers

Typo: Content-Type capitalization, hyphen errors (like ContentType or Content-type — though spec says case-insensitive, some strictly matching servers have issues) Only added headers to GET/POST responses but not to OPTIONS preflight responses; browsers look at OPTIONS headers Allow-Headers listing incomplete: e.g., frontend also sends X-Requested-With or other custom headers not listed Extra spaces in value: e.g., writing "Content-Type, Authorization" (space after comma is usually fine, but some older browsers have parsing issues) Access-Control-Allow-Headers only returns headers asked in preflight request, not all supported headers (while spec allows, this can cause issues in some scenarios)

Cross-origin configuration works locally, but after deploying to CDN/Nginx works intermittently with random errors

Missing Vary: Origin response header! CDN caches by URL, first request's CORS headers cached, subsequent different Origin requests get wrong cached response CDN configured cache rules that also cache OPTIONS preflight responses; after backend updates CORS config CDN still serves old cache Nginx configured multiple layers of add_header; lower layer CORS headers overridden by upper layer or merged incorrectly CDN HTTP header optimization feature automatically deletes or overrides Access-Control-* headers HTTPS/HTTP mixed content: page is HTTPS but endpoint is HTTP, browser blocks directly appearing as CORS error CDN node configuration inconsistent, some nodes have CORS headers some don't

Frontend can get response status code and data but cannot read custom response headers (like X-Total-Count)

Access-Control-Expose-Headers response header not configured! CORS spec by default only exposes a few basic response headers for JS reading Default accessible response headers are only: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified, Pragma Custom response headers (X-Request-Id, X-Total-Count, Authorization, Set-Cookie etc.) must be listed in Expose-Headers Set-Cookie and Set-Cookie2 are never exposed to frontend JS — this is browser security restriction, no matter the configuration Even if listed in Expose-Headers, Set-Cookie cannot be read via getResponseHeader; browser automatically filters it

Glossary

CORS (Cross-Origin Resource Sharing)
Cross-Origin Resource Sharing, a W3C standard that adds HTTP header fields allowing servers to declare which origins can access resources — the official modern browser solution to cross-origin issues.
Same-Origin Policy
Browser core security mechanism: only when protocol, domain, and port are all identical are origins considered same; different origin JavaScript by default cannot read each other's resources.
Preflight Request
OPTIONS method request automatically sent by browsers for non-simple cross-origin requests, asking the server whether the subsequent actual request is allowed; actual request sent only after preflight passes.
Simple Request
Cross-origin request meeting specific conditions (GET/HEAD/POST method, safelisted headers only, specific Content-Type) that doesn't trigger preflight — actual request sent directly.
Access-Control-Allow-Origin (ACAO)
Core CORS response header specifying allowed origins for resource access — can be specific origin URI or wildcard *; cannot use * with credentials.
Access-Control-Allow-Methods (ACAM)
Preflight response header listing all HTTP methods supported by the server, multiple methods comma-separated.
Access-Control-Allow-Headers (ACAH)
Preflight response header listing all request header fields allowed by the server; custom headers sent by frontend must be declared here.
Access-Control-Allow-Credentials (ACAC)
Response header, boolean true indicates cross-origin requests are allowed to carry cookies, Authorization and other credentials; when set Allow-Origin cannot be *.
Access-Control-Max-Age (ACMA)
Preflight response header specifying preflight result cache duration in seconds; reasonable setting reduces OPTIONS requests improving performance.
Vary: Origin
Response header telling CDN/proxies response content varies with Origin header — cache must include Origin as part of cache key to prevent cross-origin response cache corruption.
CORS-safelisted request headers
Request headers that can be sent without declaration in Allow-Headers, including Accept, Accept-Language, Content-Language, Content-Type (specific values) etc.
Forbidden header name
Request headers browsers prohibit JavaScript from setting programmatically, such as Host, Connection, Cookie, Origin etc. — these are automatically controlled by the browser.
Credentialed Request
Cross-origin request carrying identity credentials like cookies, HTTP authentication info, TLS client certificates — requires frontend-backend coordination setting withCredentials and Allow-Credentials.
Access-Control-Expose-Headers
Response header listing response headers accessible to frontend JavaScript; by default only a few basic headers are accessible, custom response headers must be declared here.
OPTIONS method
One of the HTTP methods used to retrieve communication options supported by the server; CORS uses it to send preflight requests asking about allowed methods, headers, credentials etc.
Origin request header
Request header automatically added by browsers indicating which origin (protocol+domain+port) the current request comes from; server determines cross-origin permission based on this header.
crossorigin attribute
Attribute on HTML elements (script, img, link etc.) specifying whether to load resources with CORS, values are anonymous (without credentials) and use-credentials (with credentials).
no-cors request mode
A fetch API mode allowing cross-origin requests but only simple requests can be sent and JavaScript cannot read response content — equivalent to sending an opaque response.

Complete CORS Response Headers Reference

HeaderPurposeExample ValueNotes
Access-Control-Allow-OriginSpecifies origins allowed cross-origin accesshttps://example.com or *Absolutely cannot use * with credentials, must return specific Origin; dynamic return must add Vary: Origin
Access-Control-Allow-MethodsLists all HTTP methods supported by serverGET, POST, PUT, DELETE, PATCH, OPTIONSRequired in preflight response; list all methods not just current request method
Access-Control-Allow-HeadersLists all allowed request header fieldsContent-Type, Authorization, X-TokenRequired when preflight request has Access-Control-Request-Headers; must include custom headers; some browsers disallow * with credentials
Access-Control-Allow-CredentialsWhether credentials (cookies etc.) are allowedtrueMust be lowercase true, cannot be 1 or True; when set Allow-Origin cannot be *
Access-Control-Expose-HeadersLists JS-readable response headersX-Request-Id, X-Total-CountBy default only Cache-Control/Content-Language/Content-Type/Expires/Last-Modified/Pragma are readable; custom headers must be listed here
Access-Control-Max-AgePreflight result cache time (seconds)3600Chrome/Firefox cap at 86400 seconds (2 hours), Safari shorter; value -1 disables caching sending preflight every time
VaryTells CDN/proxies which request headers affect responseOriginMust add Vary: Origin when dynamically returning Allow-Origin otherwise CDN caching causes intermittent cross-origin failures
Access-Control-Request-MethodPreflight request header telling server actual request methodPUTAutomatically sent by browser in OPTIONS requests, no need for frontend to set manually
Access-Control-Request-HeadersPreflight request header telling server which headers actual request will carrycontent-type, x-tokenAutomatically sent by browser in OPTIONS requests, multiple headers comma-separated

Which Requests Trigger Preflight Decision Table

Trigger ConditionTriggers Preflight?Details
Request method is outside GET/HEAD/POST (PUT/DELETE/PATCH/CONNECT/OPTIONS/TRACE)YesAs long as method isn't one of these three, preflight is always triggered even without custom headers
Content-Type not text/plain, multipart/form-data, application/x-www-form-urlencodedYesMost common: application/json always triggers preflight! Many developers hit this pitfall
Request includes custom headers (non-CORS-safelisted headers)YesFor example X-Token, X-Requested-With, Authorization, X-Custom-Header all trigger preflight
Request uses ReadableStream as body (stream upload)YesModern browser stream upload APIs trigger preflight
XMLHttpRequest.upload has event listeners registered (upload progress listeners)YesUsing xhr.upload.onprogress triggers preflight
Request method GET/HEAD/POST, Content-Type one of three simple types, no custom headersNoThis is a simple request, sent directly without OPTIONS
fetch set to mode: 'no-cors'No CORS preflight but response is opaqueIn this mode JS cannot read response, only simple requests can be sent
fetch set credentials: 'include' but all other conditions are simple requestNot necessarilycredentials alone doesn't directly trigger preflight, but combined with other triggers preflight occurs; note CORS validation is stricter with credentials
Same URL previously preflighted and within Max-Age cacheNo (cache hit)OPTIONS not resent during cache period unless cache disabled or expired

Common CORS Errors & Solutions Quick Reference

Console Error MessageRoot CauseSolution
No 'Access-Control-Allow-Origin' header is presentResponse has no CORS headers at all; server didn't configure CORS; gateway/proxy stripped headers; error responses like 500/404 lack headersCheck server CORS configuration; check Nginx add_header has always parameter; ensure OPTIONS request returns 2xx with CORS headers
Allow-Origin value 'XXX' doesn't match supplied OriginConfigured Allow-Origin source doesn't match actual request Origin; misconfiguration (extra slash/wrong port/http vs https)Check Origin whitelist includes request source; confirm no trailing slash; www vs non-www are different origins; dynamically return correct Origin
Preflight response doesn't pass access control check: HTTP status not okOPTIONS request returned non-2xx status like 404/405/500; server routes don't handle OPTIONS method; Nginx try_files intercepted OPTIONSEnsure OPTIONS requests return 200/204; configure OPTIONS response at server/gateway layer; verify Nginx correctly handles OPTIONS
Method XXX not allowed by Access-Control-Allow-MethodsPreflight response Allow-Methods doesn't include HTTP method you want to use (e.g., PUT not listed)List all methods needing support in Access-Control-Allow-Methods, comma-separated
Request header field XXX not allowed by Access-Control-Allow-HeadersSent custom header but Allow-Headers doesn't declare it; most commonly forgotten Content-Type: application/json, AuthorizationList all used request headers in Access-Control-Allow-Headers including Content-Type (when non-simple type)
When credentials flag is true, Allow-Origin cannot be wildcard *When credentialed request (withCredentials=true) server returned Allow-Origin: *, explicitly forbidden by specCannot use *, must return specific origin based on request Origin; also confirm Allow-Credentials: true
When credentials flag is true, Allow-Headers cannot be wildcard *Allow-Headers set to * with credentialed requests, disallowed by some browsers like ChromeList all actually used request headers, don't use *
Preflight redirect is not allowedOPTIONS request returned 3xx redirect; browsers don't follow preflight request redirectsEnsure OPTIONS requests directly return 200, don't redirect; fix server configuration to avoid OPTIONS jumps