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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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).
