CORS (Cross-Origin Resource Sharing)

**CORS(Cross-Origin Resource Sharing)**는 HTTP 헤더 기반 메커니즘으로, 서버가 자신의 출처(origin)와 다른 출처에서 리소스 접근을 허용할지 명시적으로 지정할 수 있도록 합니다. 브라우저는 기본적으로 Same-Origin Policy(동일 출처 정책)를 적용하여 다른 출처로의 HTTP 요청을 차단하는데, CORS는 이를 안전하게 완화하는 표준화된 방법을 제공합니다.

**출처(Origin)**는 프로토콜 + 도메인 + 포트의 조합입니다:

• https://example.com:443 → 하나의 출처
• http://example.com:80 → 다른 출처 (프로토콜 다름)
• https://api.example.com:443 → 다른 출처 (도메인 다름)

해당 개념이 필요한 이유

• Same-Origin Policy의 제약 극복: 브라우저는 보안을 위해 다른 출처의 리소스 접근을 기본적으로 차단합니다. CORS를 통해 신뢰할 수 있는 출처에 한해 접근을 허용할 수 있습니다
• API 서버와 클라이언트 분리: 최근 웹 애플리케이션은 프론트엔드(https://app.example.com)와 백엔드 API(https://api.example.com)를 별도 도메인에서 운영하는 경우가 많습니다. CORS 없이는 이러한 구조가 불가능합니다
• 써드파티 API 통합: 외부 API를 브라우저에서 직접 호출할 때 CORS 설정이 필요합니다 (Google Maps API, 결제 API 등)

AS-IS: Same-Origin Policy로 인한 차단

sequenceDiagram
    autonumber
    participant Browser
    participant Frontend as Frontend<br/>(https://app.example.com)
    participant API as API Server<br/>(https://api.example.com)

    Browser->>Frontend: 페이지 로드
    Frontend->>Browser: fetch('https://api.example.com/data')
    Browser->>API: GET /data<br/>Origin: https://app.example.com
    API->>Browser: 200 OK (CORS 헤더 없음)
    Browser->>Frontend: ❌ CORS 에러<br/>"Access-Control-Allow-Origin header missing"

    Note over Browser,API: Same-Origin Policy로 인해 응답 차단

TO-BE: CORS 헤더로 접근 허용

sequenceDiagram
    autonumber
    participant Browser
    participant Frontend as Frontend<br/>(https://app.example.com)
    participant API as API Server<br/>(https://api.example.com)

    Browser->>Frontend: 페이지 로드
    Frontend->>Browser: fetch('https://api.example.com/data')
    Browser->>API: GET /data<br/>Origin: https://app.example.com
    API->>Browser: 200 OK<br/>Access-Control-Allow-Origin: https://app.example.com
    Browser->>Frontend: ✅ 응답 전달 성공

    Note over Browser,API: CORS 헤더로 접근 허용

CORS 동작 원리

CORS는 다음과 같이 작동합니다:

1. 브라우저가 cross-origin 요청에 Origin 헤더를 포함하여 전송
2. 서버가 Access-Control-* 헤더로 허용 여부를 응답
3. 브라우저가 응답 헤더를 확인하여 접근 허용 또는 차단
4. 특정 요청의 경우 실제 요청 전에 **Preflight(사전 요청)**을 먼저 전송

Simple Request vs Preflighted Request

CORS 요청은 두 가지 유형으로 나뉩니다.

Simple Request (단순 요청)

Preflight 없이 바로 실제 요청을 보냅니다. 다음 조건을 모두 만족해야 합니다:

조건 1: 허용된 HTTP 메서드만 사용

• GET
• HEAD
• POST

조건 2: 허용된 헤더만 사용 (CORS-safelisted headers)

• Accept
• Accept-Language
• Content-Language
• Content-Type (특정 값만 허용)
• Range (단일 범위만)

조건 3: Content-Type이 다음 중 하나

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Simple Request 예시

// 클라이언트
fetch("https://api.example.com/public-data")
  .then(response => response.json())
  .then(data => console.log(data));

// 브라우저가 전송
GET /public-data HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Accept: application/json
 
// 서버 응답
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json
 
{"message": "Hello"}

Preflighted Request (사전 요청)

실제 요청 전에 OPTIONS 메서드로 사전 요청을 보내 서버가 허용하는지 먼저 확인합니다.

Preflight가 발생하는 경우

• GET, HEAD, POST 외의 HTTP 메서드 사용 (PUT, DELETE, PATCH 등)
• 커스텀 헤더 포함 (예: X-Custom-Header, Authorization)
• Content-Type이 허용된 3가지 외의 값 (예: application/json)
• XMLHttpRequest.upload에 이벤트 리스너 등록
• ReadableStream 사용

Preflighted Request 예시

// 클라이언트
fetch("https://api.example.com/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",  // preflight 트리거
    "X-Custom-Header": "value"           // preflight 트리거
  },
  body: JSON.stringify({ name: "Alice" })
});

// Step 1: Preflight 요청 (OPTIONS)
OPTIONS /users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type,x-custom-header
 
// Step 2: Preflight 응답
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Custom-Header
Access-Control-Max-Age: 86400  // 24시간 동안 preflight 결과 캐싱
 
// Step 3: 실제 요청 (preflight 성공 시에만)
POST /users HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Content-Type: application/json
X-Custom-Header: value
 
{"name": "Alice"}
 
// Step 4: 실제 응답
HTTP/1.1 201 Created
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json
 
{"id": 123, "name": "Alice"}

sequenceDiagram
    autonumber
    participant Browser
    participant Server

    Note over Browser,Server: Preflight 단계
    Browser->>Server: OPTIONS /users<br/>Access-Control-Request-Method: POST<br/>Access-Control-Request-Headers: content-type
    Server->>Browser: 204 No Content<br/>Access-Control-Allow-Methods: POST<br/>Access-Control-Allow-Headers: content-type

    Note over Browser,Server: 실제 요청 단계
    Browser->>Server: POST /users<br/>Content-Type: application/json
    Server->>Browser: 200 OK<br/>Access-Control-Allow-Origin: https://app.example.com

CORS 주요 헤더

서버 → 브라우저 응답 헤더

헤더	설명	예시
Access-Control-Allow-Origin	허용할 출처 지정	https://app.example.com 또는 *
Access-Control-Allow-Methods	허용할 HTTP 메서드	POST, GET, OPTIONS
Access-Control-Allow-Headers	허용할 요청 헤더	Content-Type, Authorization
Access-Control-Allow-Credentials	인증 정보(쿠키) 허용 여부	true
Access-Control-Max-Age	Preflight 결과 캐싱 시간 (초)	86400 (24시간)
Access-Control-Expose-Headers	JS에서 접근 가능한 응답 헤더	X-Custom-Header

Access-Control-Allow-Origin

가장 중요한 헤더로, 어떤 출처의 요청을 허용할지 명시합니다.

# 특정 출처만 허용
Access-Control-Allow-Origin: https://app.example.com
 
# 모든 출처 허용 (인증 정보 사용 불가)
Access-Control-Allow-Origin: *

중요한 제약:

• 인증 정보(쿠키, Authorization 헤더)를 포함하는 요청의 경우 반드시 정확한 출처를 명시해야 하며, *는 사용할 수 없습니다

# ❌ 인증 정보 포함 요청에서 와일드카드 사용 - 브라우저가 차단
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
 
# ✅ 정확한 출처 명시 필요
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true

Access-Control-Allow-Credentials

인증 정보(쿠키, HTTP 인증, TLS 클라이언트 인증서)를 요청에 포함할 수 있는지 지정합니다.

Access-Control-Allow-Credentials: true

이 헤더가 true로 설정되면:

• 클라이언트는 credentials: 'include' 옵션을 사용해야 함
• Access-Control-Allow-Origin은 반드시 정확한 출처를 명시해야 함 (* 불가)

Access-Control-Max-Age

Preflight 요청의 결과를 캐싱할 시간(초)을 지정합니다. 캐싱 기간 동안은 동일한 요청에 대해 preflight를 생략합니다.

Access-Control-Max-Age: 86400  # 24시간 (86400초)

브라우저 → 서버 요청 헤더

헤더	설명	예시
Origin	요청의 출처	https://app.example.com
Access-Control-Request-Method	실제 요청에서 사용할 HTTP 메서드 (Preflight에서만)	POST
Access-Control-Request-Headers	실제 요청에서 포함할 헤더 목록 (Preflight에서만)	Content-Type, X-Custom-Header

인증 정보(Credentials) 포함 요청

기본적으로 cross-origin 요청은 쿠키나 Authorization 헤더를 포함하지 않습니다. 인증 정보를 포함하려면 클라이언트와 서버 모두 설정이 필요합니다.

클라이언트 설정

Fetch API

fetch("https://api.example.com/user-data", {
  credentials: "include"  // 쿠키 및 인증 정보 포함
})
  .then(response => response.json())
  .then(data => console.log(data));

credentials 옵션 값:

• "omit": 인증 정보 포함 안 함 (기본값)
• "same-origin": 동일 출처 요청에만 인증 정보 포함
• "include": 항상 인증 정보 포함

XMLHttpRequest

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;  // 인증 정보 포함
xhr.open("GET", "https://api.example.com/user-data");
xhr.send();

서버 설정

인증 정보를 포함한 요청에 대해 서버는 다음을 반드시 설정해야 합니다:

Access-Control-Allow-Origin: https://app.example.com  # 정확한 출처 명시 (* 불가)
Access-Control-Allow-Credentials: true

인증 정보 포함 요청 전체 흐름

// 클라이언트
fetch("https://api.example.com/protected-data", {
  method: "POST",
  credentials: "include",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ id: 123 })
});

// Preflight 요청
OPTIONS /protected-data HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
 
// Preflight 응답
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com  # * 불가
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Credentials: true  # 필수
 
// 실제 요청
POST /protected-data HTTP/1.1
Origin: https://app.example.com
Cookie: sessionId=abc123  # 쿠키 포함
Content-Type: application/json
 
{"id": 123}
 
// 실제 응답
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com  # * 불가
Access-Control-Allow-Credentials: true  # 필수
Set-Cookie: sessionId=xyz789
 
{"status": "success"}

서버 측 CORS 구현 예시

Node.js/Express

const express = require('express');
const app = express();
 
// 모든 요청에 CORS 허용 (공개 API)
app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});
 
// 특정 출처만 허용하고 인증 정보 포함
app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', 'https://app.example.com');
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
 
  // Preflight 요청 처리
  if (req.method === 'OPTIONS') {
    return res.sendStatus(204);
  }
  next();
});
 
app.get('/api/data', (req, res) => {
  res.json({ message: 'Hello CORS' });
});
 
app.listen(3000);

Spring Boot (Java)

@Configuration
public class CorsConfig {
 
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/api/**")
                    .allowedOrigins("https://app.example.com")
                    .allowedMethods("GET", "POST", "PUT", "DELETE")
                    .allowedHeaders("Content-Type", "Authorization")
                    .allowCredentials(true)
                    .maxAge(3600);
            }
        };
    }
}

CORS 에러 해결

에러 메시지	원인	해결 방법
Access-Control-Allow-Origin header missing	서버가 CORS 헤더를 보내지 않음	서버에서 Access-Control-Allow-Origin 헤더 추가
Access-Control-Allow-Origin does not match	출처가 허용 목록에 없음	서버에서 해당 출처를 허용 목록에 추가
Credentials mode is ‘include’ but Access-Control-Allow-Credentials is missing	인증 정보 포함 요청에 credentials 헤더 없음	서버에서 Access-Control-Allow-Credentials: true 추가
Method not found in Access-Control-Allow-Methods	HTTP 메서드가 허용되지 않음	서버에서 해당 메서드를 Access-Control-Allow-Methods에 추가
Header not found in Access-Control-Allow-Headers	커스텀 헤더가 허용되지 않음	서버에서 해당 헤더를 Access-Control-Allow-Headers에 추가

CORS가 보호하는 것 vs 보호하지 않는 것

✅ CORS가 보호하는 것

• 무단 데이터 접근 방지: 악의적인 웹사이트가 사용자의 브라우저를 통해 다른 사이트의 데이터를 자동으로 읽는 것을 차단
• 명시적 권한 부여: 서버가 허용한 출처만 리소스에 접근 가능
• 민감한 작업 보호: GET 외의 요청은 preflight를 통해 서버가 명시적으로 허용해야 함

❌ CORS가 보호하지 않는 것

• CSRF(Cross-Site Request Forgery) 공격: CORS는 CSRF를 방지하지 않습니다. 별도의 CSRF 토큰이 필요합니다
• 중간자 공격(Man-in-the-Middle): CORS는 전송 계층 보안과 무관합니다. HTTPS/TLS를 사용해야 합니다
• 서버 측 취약점: CORS는 클라이언트 측 보안만 다룹니다. 서버 측 보안은 별도로 구현해야 합니다

보안 Best Practices

# ❌ 나쁜 예: 인증 정보와 와일드카드 함께 사용 불가
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
 
# ✅ 좋은 예: 특정 출처만 허용
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
 
# ✅ 좋은 예: Preflight 캐싱 적절히 설정
Access-Control-Max-Age: 3600  # 1시간
 
# ✅ 좋은 예: 필요한 메서드만 허용
Access-Control-Allow-Methods: GET, POST  # PUT, DELETE는 필요할 때만

참고 문서

• MDN - CORS
• MDN - CORS Errors
• Enable CORS - Server Implementation Guide
• MDN - Fetch API