Complete Guide to CORS (Cross-Origin Resource Sharing)

Complete Guide to CORS (Cross-Origin Resource Sharing)

~Why errors occur and what they mean~

Introduction

Have you ever been frustrated by "CORS errors" while doing frontend development? Even though you created your own API, when you try to access it with XMLHttpRequest (XHR) or fetch, you get an error saying "Access-Control-Allow-Origin is not set." Many developers have experienced this.

💡 Common scenario: During local development, trying to access an API at http://localhost:5000 from http://localhost:3000 suddenly triggers a CORS error.

Today, let's learn about CORS (Cross-Origin Resource Sharing) step by step.

What you'll learn in this article

• What CORS actually is
• Why it's necessary
• How it works
• Historical background
• Important points for API design

1. What is an "Origin"?

First, before understanding CORS, let's grasp the concept of "origin." Origin refers to the "source (combination of protocol, domain, and port)" on the web.

Components of an Origin

An origin consists of the following three elements:

1. Protocol (http/https)
2. Domain (example.com)
3. Port number (:80, :443, :3000, etc.)

Understanding through examples

• https://example.com:443
• http://example.com:80
• https://api.example.com:443

For example:

Even if they share the same "example.com," different protocols or ports make them different origins.

🎯 Important: Browsers only consider them "same origin" when all three components match exactly.

2. Why is the CORS mechanism necessary?

Here's a question. What would happen if browsers could make requests to any website's resources without restrictions?

Potential dangerous scenarios

1. A user's browser accessing a malicious site automatically sends requests to the user's bank website.

Scenario 1: Attacks from malicious sites → If the user is logged in, their cookie information is sent without permission.

1. Personal information and payment details leak to external parties without the user's knowledge.

• Unauthorized access to social media posts
• Reading email contents
• Stealing online shopping history

Scenario 2: Unauthorized data access

Role of Same-Origin Policy

To prevent such Cross-Site Request Forgery (CSRF) attacks, browsers follow a rule called "Same-Origin Policy".

🛡️ Same-Origin Policy: Don't communicate with origins other than your own without permission

But this causes problems too

However, in reality, frontend (https://myapp.com) and API servers (https://api.myapp.com) often have different origins.

This would block even legitimate communication... That's where CORS comes in.

💡 CORS's role: A mechanism for servers to tell browsers "access from this origin is safe"

3. How CORS works

CORS is a mechanism for servers to tell browsers "access from this origin is OK."

Basic flow

1. Frontend sends a request to an API of a different origin
2. Browser asks the server "is this communication safe?"
3. Server responds "I allow this origin"
4. Browser permits the communication

Important HTTP headers

Here's the representative HTTP header for this:

Access-Control-Allow-Origin: https://myapp.com

If this is returned, the browser permits communication. If it's not included, you get a "CORS error."

Other important headers

Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

✅ Success condition: Browsers permit communication when servers return appropriate CORS headers.

4. What is a preflight request?

Here's something that often causes confusion: "preflight requests." This refers to preliminary confirmation requests.

When preflight is needed

• GET method
• HEAD method
• POST method (under specific conditions only)
• Using only standard headers

No preflight required (simple requests)

• Methods with "side effects" like PUT DELETE
• When sending custom headers
• Content-Type: application/json etc.

Preflight required (complex requests)

Preflight flow

In this case, the browser first sends an OPTIONS request like this to the server:

OPTIONS /api/data HTTP/1.1
Origin: https://myapp.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Content-Type

The server responds with:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type

If this is returned, the actual request is executed.

🔄 Purpose of preflight: For the browser to ask "can this request be executed safely?" in advance

5. History and standardization

CORS was standardized by W3C (World Wide Web Consortium) and became a recommendation in 2014.

The Ajax revolution era

The background includes the spread of Ajax (asynchronous communication). In the mid-2000s, Google Maps and Gmail appeared, rapidly increasing the need to call APIs from browsers.

However, due to "Same-Origin Policy," it was initially difficult to integrate with external APIs, and developers used workarounds like:

Workarounds of that era

• Data retrieval via script tags
• High security risk
• Difficult error handling

JSONP (JSON with Padding)

• Routing through your own server
• Consumes server resources
• Complex configuration

Reverse proxy

Birth of CORS

CORS was introduced to eliminate the inconvenience of these workarounds.

📅 Historical significance: CORS greatly expanded the possibilities of web applications.

6. Common stumbling blocks in development

Case 1: Local environment testing

Problem: http://localhost:3000 → http://api.localhost:5000 This is also treated as a different origin, causing CORS errors.

• Temporarily allow Access-Control-Allow-Origin: * on the API side during development
• Set up a reverse proxy
• Configure proxy in Next.js next.config.js

Solutions:

// next.config.js
module.exports = {
  async rewrites() {
    return [
      {
        source: '/api/:path*',
        destination: 'http://localhost:5000/api/:path*'
      }
    ]
  }
}

Case 2: Missing configuration in production

Problem: If CORS headers are not set on the API server, the frontend will always get errors.

• Nginx: nginx.conf configuration
• Express: CORS middleware configuration
• Django: django-cors-headers configuration
• CloudFront: Response header configuration

Places to check:

Case 3: Problems with authenticated APIs

Problem: When using cookies or Authorization headers, additional configuration is needed

Required configuration:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://myapp.com  // * cannot be used

⚠️ Note: When Access-Control-Allow-Credentials: true, you cannot use * for Access-Control-Allow-Origin.

7. CORS advantages and disadvantages

Advantages

• Prevents unauthorized cross-site communication and protects users
• Protection from threats like CSRF attacks
• Server-side access control is possible

Enhanced security

• Safe external API integration
• Communication between microservices
• Easy separation of frontend and backend

Development flexibility

Disadvantages

• Complex configuration that beginners struggle with
• Requires server-side knowledge
• Can be difficult to debug

Configuration complexity

• Increased communication count due to preflight
• Slight increase in response time
• Network bandwidth consumption

Performance impact

⚖️ Balance: It's designed as a mechanism to balance security and convenience.

8. Current status and browser support

Browser support status

As of 2025, all major browsers (Chrome, Firefox, Safari, Edge) implement CORS. While there are some differences in specification interpretation, basic behavior is standardized, so developers can use it with confidence.

Security enhancement trends

Particularly in security enhancement trends:

Combined use with SameSite Cookie attributes

Set-Cookie: sessionId=abc123; SameSite=Strict; Secure

• Restrict origins with CORS
• Verify request legitimacy with CSRF tokens
• Double security measures

Combination of CORS and CSRF tokens

Future prospects

• Enhanced integration with WebAssembly
• CORS control in Service Workers
• HTTP/3 optimization

🔮 Future: CORS will continue to play an important role as a foundation of web security.

9. Important points for API design

When designing and developing APIs, please pay attention to the following:

Security principles

1. Minimize allowed origins

// ❌ Dangerous
Access-Control-Allow-Origin: *

// ✅ Safe
Access-Control-Allow-Origin: https://myapp.com

2. Allow only necessary HTTP methods and headers

// ❌ Overly broad permission
Access-Control-Allow-Methods: *

// ✅ Minimum necessary
Access-Control-Allow-Methods: GET, POST

3. Be especially careful with authentication

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://myapp.com  // * cannot be used

Implementation checklist

• [ ] Not using * in production environment
• [ ] Only allowing necessary methods
• [ ] Setting credentials: true when authentication is required
• [ ] Supporting preflight requests
• [ ] Implementing appropriate error handling

🛡️ Security first: It's important to prioritize safety over convenience.

Summary

To summarize what CORS is in one sentence: "A mechanism for servers to permit the 'communication rules' that browsers establish to protect users."

What we learned in this article

• What an origin is (combination of protocol, domain, and port)
• Why Same-Origin Policy is necessary (security protection)
• How CORS controls this (server-side permission)
• The meaning of preflight requests (preliminary confirmation)
• Historical background and current status (from Ajax revolution to present)

Practical understanding

With this understanding, when you encounter CORS errors, you can calmly judge "I see, the server isn't returning this."

Important points

CORS is basically irrelevant for native apps and server-side applications. This is purely a "browser specification."

When you see CORS errors next time, remember "the browser is doing a safety check for me."

Finally

CORS may seem complex, but it has an important purpose: "protecting user safety." By understanding and implementing it properly, you can create safe and user-friendly web applications.

💡 Remember: CORS errors are not "problems" but "evidence that the browser is working normally."