CORS Header Checker

Understand Cross-Origin Resource Sharing (CORS), build CORS policies interactively, and generate server configurations. Learn how preflight requests work and debug common CORS errors with the reference guide below.

What Is CORS?

Cross-Origin Resource Sharing (CORS) is a security mechanism that allows or restricts web pages from making requests to a different domain than the one that served the page. By default, browsers block cross-origin requests (the Same-Origin Policy). CORS headers tell the browser which cross-origin requests are permitted.

CORS is fundamental to modern web development, where frontends and APIs often live on different domains. It is also relevant for network tools — if you are building a dashboard that queries your router's API from a different origin, or using a DNS lookup service, CORS policies determine whether those requests succeed.

CORS Headers Reference

Here is a complete reference of all CORS-related HTTP headers:

Pro Tip: Never use Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true — browsers reject this combination for security reasons. If you need credentials, you must specify the exact origin. Use dynamic origin checking on the server to support multiple origins with credentials. For APIs behind your port-forwarded server, always use specific origins.

How Preflight Requests Work

When a cross-origin request uses methods other than GET/POST or includes custom headers, the browser sends a preflight OPTIONS request first. Understanding this flow is critical for debugging CORS issues:

Common CORS Errors and Fixes

CORS errors are among the most confusing issues in web development. Here are the most common ones and how to fix them:

Error: No Access-Control-Allow-Origin header

# Error message:
# "has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header
# is present on the requested resource."

# Fix: Add the header to your server response
# Nginx:
add_header 'Access-Control-Allow-Origin' 'https://yourapp.com' always;

Error: Wildcard origin with credentials

# Error message:
# "The value of the 'Access-Control-Allow-Origin' header must not be '*'
# when the request's credentials mode is 'include'."

# Fix: Use specific origin instead of wildcard
add_header 'Access-Control-Allow-Origin' $http_origin always;
add_header 'Access-Control-Allow-Credentials' 'true' always;

Error: Method not allowed

# Error message:
# "Method DELETE is not allowed by Access-Control-Allow-Methods"

# Fix: Include the method in allowed methods
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;

For a comprehensive security setup, combine proper CORS with other security headers like CSP and HSTS. Also ensure your API authentication is properly configured.

CORS Security Best Practices

Misconfigured CORS can expose your API to cross-origin attacks. Follow these guidelines to balance functionality with security, much like how you balance convenience and security on your home network:

1. Never use wildcard (*) with credentials — Specify exact origins when authentication is involved.
2. Validate origins server-side — Do not simply reflect the Origin header. Maintain a whitelist of allowed origins.
3. Minimize allowed methods — Only allow the HTTP methods your API actually uses.
4. Restrict allowed headers — Only permit headers your API expects.
5. Use long max-age for caching — Reduce preflight request overhead by caching results (86400 seconds is standard).
6. Combine with authentication — CORS alone does not replace proper authentication. Use strong API keys or OAuth tokens.
7. Monitor CORS errors — Log blocked CORS requests to detect misconfigurations or attack attempts.

CORS vs CSP: Understanding the Difference

CORS and Content Security Policy (CSP) are often confused, but they serve different purposes. Understanding both is essential for web security:

For complete web security, configure both CORS and CSP. See our HTTP Headers Checker and Mixed Content Checker for complementary security tools.

Video: CORS Explained

Related Guides

• HTTP Security Headers Checker
• Mixed Content Checker
• DNS Lookup Tool
• Port Checker
• Password Generator
• What Is Port Forwarding?
• Secure Your Home WiFi Network
• WPA2 vs WPA3 Security
• Set Up DNS over HTTPS
• Hide Browsing From Your ISP

Frequently Asked Questions

Why do I get CORS errors only in the browser?

CORS is a browser security mechanism. When you make the same request from Postman, curl, or a server-side script, there is no CORS check because there is no browser to enforce it. The browser adds the Origin header and enforces the Same-Origin Policy; other HTTP clients do not.

Can I disable CORS in the browser?

You can disable CORS for development using browser flags or extensions, but this is dangerous for security and should never be done in production. The proper fix is always to configure correct CORS headers on your server.

Why does my preflight request fail?

The most common cause is the server not handling OPTIONS requests. Many frameworks route OPTIONS to a 404 by default. Ensure your server returns a 204 response to OPTIONS requests with the correct CORS headers. Check that your server is not requiring authentication for OPTIONS requests.

What is a "simple request" in CORS?

A simple request uses only GET, HEAD, or POST methods with standard headers (Accept, Content-Type with form values, Content-Language). Simple requests do not trigger a preflight — the browser sends them directly and checks CORS headers on the response. Any other combination triggers a preflight.

Should I use Access-Control-Allow-Origin: * for my public API?

For truly public APIs that do not use cookies or authentication, wildcard (*) is acceptable. However, if your API uses any form of authentication (API keys in headers, session cookies), you must use specific origins. Even for public APIs, consider using specific origins for better security.

How do I handle CORS with a reverse proxy?

If your reverse proxy (Nginx, Apache) sits in front of your application, you can add CORS headers at the proxy level instead of in your application code. This centralizes CORS configuration. However, ensure you are not duplicating headers — having the same header set twice can cause issues.

Does CORS protect my API from abuse?

No. CORS only prevents browser-based cross-origin requests. Attackers can bypass CORS entirely using curl, Postman, or any non-browser HTTP client. Always implement proper authentication, rate limiting, and input validation regardless of CORS settings. Use strong API credentials for all protected endpoints.

About Tommy N.

Tommy is the founder of RouterHax and a network engineer with 10+ years of experience in home and enterprise networking. He specializes in router configuration, WiFi optimization, and network security. When not writing guides, he's testing the latest mesh WiFi systems and helping readers troubleshoot their home networks.