Saturday, November 1, 2025

웹 개발의 보이지 않는 장벽 CORS 제대로 이해하기
  /   No comments   

웹 개발자라면 누구나 한 번쯤은 붉은색 에러 메시지와 함께 등장하는 'CORS'라는 단어에 골머리를 앓아본 경험이 있을 것입니다. 콘솔 창을 가득 메운 'Access to XMLHttpRequest at '...' from origin '...' has been blocked by CORS policy' 메시지는 단순히 코드 한두 줄을 수정해서 해결될 문제가 아닐 때가 많습니다. 이 에러는 단순한 버그가 아니라, 현대 웹을 지탱하는 아주 중요한 보안 원칙과 깊숙이 연관되어 있기 때문입니다. 많은 개발자들이 급한 마음에 'Access-Control-Allow-Origin: *'와 같은 해결책을 검색해 적용하고 넘어가지만, 이는 잠재적으로 심각한 보안 문제를 야기할 수 있는 위험한 접근 방식입니다.

CORS, 즉 교차 출처 리소스 공유(Cross-Origin Resource Sharing)는 왜 존재하는 것일까요? 이 질문에 답하기 위해서는 먼저 웹의 근간을 이루는 '동일 출처 정책(Same-Origin Policy, SOP)'을 이해해야 합니다. CORS는 이 견고한 보안 장벽에 구멍을 내는 것이 아니라, 신뢰할 수 있는 통신을 위해 안전하게 문을 열어주는 정교한 메커니즘입니다. 이 글에서는 CORS 에러의 본질적인 원인인 SOP부터 시작하여, CORS가 어떻게 작동하는지 그 내부 메커니즘을 상세히 분석할 것입니다. 또한, 다양한 백엔드 환경에서 CORS를 올바르게 설정하는 구체적인 방법을 코드 예제와 함께 살펴보고, 인증 정보(credentials)를 다루거나 복잡한 요청을 처리하는 고급 시나리오까지 깊이 있게 다룰 것입니다. 이 글을 끝까지 읽고 나면, 당신은 더 이상 CORS 에러 앞에서 당황하지 않고, 그 원인을 정확히 진단하며 웹 애플리케이션의 보안과 기능을 모두 만족시키는 현명한 해결책을 스스로 찾아낼 수 있는 개발자로 거듭나게 될 것입니다.

모든 것의 시작: 동일 출처 정책 (Same-Origin Policy)

CORS를 이해하기 위한 첫걸음은 동일 출처 정책(SOP)을 이해하는 것입니다. SOP는 웹 보안의 가장 기본적인 초석으로, 한 출처(origin)에서 로드된 문서나 스크립트가 다른 출처의 리소스와 상호작용하는 것을 제한하는 브라우저의 보안 정책입니다. 여기서 '출처'란 프로토콜(protocol), 호스트(host), 그리고 포트(port)의 조합으로 정의됩니다. 예를 들어, `https://www.my-service.com` 이라는 주소가 있다면, 프로토콜은 `https`, 호스트는 `www.my-service.com`, 포트는 기본값인 `443`이 됩니다. 이 세 가지 요소 중 하나라도 다르면 브라우저는 이를 '다른 출처'로 간주합니다.

다음은 출처 비교의 몇 가지 예시입니다.

기준 URL 비교 URL 결과 이유
http://example.com/app/index.html http://example.com/app/main.html 성공 경로(Path)는 출처 판단에 영향을 주지 않음
http://example.com/app/index.html https://example.com/app/main.html 실패 프로토콜이 다름 (http vs https)
http://example.com/app/index.html http://www.example.com/app/main.html 실패 호스트(서브도메인)가 다름
http://example.com:80/app/index.html http://example.com:8080/app/main.html 실패 포트가 다름 (80 vs 8080)

SOP가 왜 필요할까요? 만약 이 정책이 없다면, 악의적인 웹사이트가 사용자의 브라우저를 통해 다른 웹사이트의 정보를 탈취하는 것이 너무나 쉬워집니다. 예를 들어, 당신이 은행 웹사이트에 로그인한 상태에서 다른 탭에서 악성 스크립트가 포함된 이메일 링크를 클릭했다고 상상해보세요. SOP가 없다면 이 악성 스크립트는 당신의 은행 계좌 정보를 읽고, 자금을 이체하는 등의 끔찍한 일을 사용자의 인증 정보를 이용해 몰래 수행할 수 있습니다. SOP는 이처럼 다른 출처의 데이터에 대한 읽기 접근을 기본적으로 차단함으로써 이러한 유형의 공격(Cross-Site Request Forgery, CSRF 등)을 방지하는 중요한 방어선 역할을 합니다.

하지만 현대 웹 애플리케이션은 점점 더 복잡해지고 분산되고 있습니다. 프론트엔드와 백엔드 서버를 분리(e.g., Single Page Application)하거나, 여러 외부 서비스의 API를 호출하여 데이터를 조합하는 매시업(Mashup) 서비스가 일반화되면서 다른 출처의 리소스를 합법적으로 요청해야 할 필요성이 폭발적으로 증가했습니다. SOP의 엄격한 제한은 이러한 현대적인 웹 아키텍처를 구현하는 데 큰 걸림돌이 되었습니다. 바로 이 지점에서 CORS가 등장합니다. CORS는 SOP의 보안 원칙을 훼손하지 않으면서, 서버와 클라이언트 간의 신뢰 기반 협의를 통해 선택적으로 다른 출처 간의 리소스 공유를 허용하는 표준 메커니즘입니다.

CORS의 작동 원리: 보이지 않는 협상 과정

CORS는 HTTP 헤더를 기반으로 작동합니다. 클라이언트(브라우저)가 다른 출처로 리소스를 요청할 때, 요청 헤더에 자신의 출처를 나타내는 `Origin` 헤더를 포함하여 보냅니다. 그러면 서버는 이 `Origin` 헤더 값을 확인하고, 이 출처에서의 요청을 허용할지 여부를 결정합니다. 만약 허용하기로 결정했다면, 서버는 응답 헤더에 `Access-Control-Allow-Origin` 헤더를 포함하여 응답합니다. 브라우저는 서버로부터 받은 응답에 이 헤더가 포함되어 있는지, 그리고 그 값이 요청을 보낸 `Origin`과 일치하는지(또는 와일드카드 `*`인지)를 확인합니다. 만약 조건이 충족되면 브라우저는 응답 데이터를 자바스크립트 코드가 접근할 수 있도록 허용하고, 그렇지 않다면 CORS 에러를 발생시키고 데이터를 차단합니다. 이 모든 과정은 브라우저 수준에서 자동으로 이루어지며, 개발자가 자바스크립트 코드로 직접 제어하는 것이 아닙니다.

CORS 요청은 크게 '단순 요청(Simple Request)'과 '프리플라이트 요청(Preflighted Request)' 두 가지로 나뉩니다.

1. 단순 요청 (Simple Request)

특정 조건을 모두 만족하는 요청은 '단순 요청'으로 분류되며, 브라우저는 별도의 확인 절차 없이 바로 본 요청을 서버로 보냅니다. 이 조건들은 서버에 큰 부작용을 일으키지 않을 것으로 간주되는 안전한 요청들의 기준입니다.

  • 메서드(Method): GET, HEAD, POST 중 하나여야 합니다.
  • 헤더(Headers): 다음의 헤더들만 사용할 수 있습니다:
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type
  • Content-Type 헤더: application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나여야 합니다.

예를 들어, `https://client.com`에서 `https://api.server.com/data`로 간단한 GET 요청을 보내는 상황을 가정해봅시다.

[클라이언트 요청]
GET /data HTTP/1.1
Host: api.server.com
Origin: https://client.com  <-- 브라우저가 자동으로 추가
...

서버가 이 요청을 받고 `https://client.com`からの 요청을 허용한다면, 다음과 같이 응답합니다.

[서버 응답]
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.com  <-- 이 출처를 허용함
Content-Type: application/json
...

{"message": "success"}

브라우저는 응답 헤더에서 `Access-Control-Allow-Origin`을 확인하고, 값이 `https://client.com`이므로 정상적으로 요청을 처리하고 자바스크립트가 응답 데이터에 접근하도록 허용합니다. 만약 서버가 이 헤더를 보내지 않거나 `Access-Control-Allow-Origin: https://another-client.com` 과 같이 다른 값을 보낸다면, 브라우저는 CORS 에러를 발생시킵니다.

2. 프리플라이트 요청 (Preflighted Request)

단순 요청의 조건을 벗어나는 요청은 잠재적으로 서버의 상태를 변경할 수 있는 '위험한' 요청으로 간주됩니다. 예를 들어, HTTP 메서드로 `PUT`, `DELETE`, `PATCH`를 사용하거나, `Content-Type`이 `application/json`이거나, 커스텀 헤더(e.g., `X-Custom-Header: ...`)를 포함하는 경우입니다. 이러한 요청에 대해 브라우저는 본 요청을 보내기 전에, 먼저 `OPTIONS` 메서드를 사용하여 '프리플라이트(preflight)', 즉 예비 요청을 서버에 보냅니다. 이 예비 요청의 목적은 본 요청을 보내도 안전한지 서버에 미리 확인하고 허락을 구하는 것입니다.

프리플라이트 요청은 다음과 같은 헤더를 포함합니다.

  • Access-Control-Request-Method: 본 요청에서 사용될 HTTP 메서드를 명시합니다.
  • Access-Control-Request-Headers: 본 요청에서 사용될 커스텀 헤더들을 명시합니다.
  • Origin: 본 요청의 출처를 명시합니다.

이 과정을 텍스트로 시각화하면 다음과 같습니다.

  클라이언트 (브라우저)                                     서버
       |                                                    |
       |  1. 본 요청(PUT /data)을 보내기 전                     |
       |  OPTIONS /data (프리플라이트 요청)                  |
       |  Origin: https://client.com                         |
       |  Access-Control-Request-Method: PUT                 |
       |  Access-Control-Request-Headers: Content-Type       |
       |---------------------------------------------------->|
       |                                                    |
       |                                        2. 서버는 이 예비 요청을 검토하고,
       |                                           본 요청을 허용할지 결정함.
       |                                                    |
       |  HTTP/1.1 204 No Content                            |
       |  Access-Control-Allow-Origin: https://client.com    |
       |  Access-Control-Allow-Methods: GET, POST, PUT       |
       |  Access-Control-Allow-Headers: Content-Type         |
       |  Access-Control-Max-Age: 86400 (옵션)                |
       |<----------------------------------------------------|
       |                                                    |
       |  3. 브라우저는 응답 헤더를 확인하고,                 |
       |     본 요청이 허용됨을 인지함.                      |
       |                                                    |
       |  4. 본 요청 (PUT /data)                             |
       |  Origin: https://client.com                         |
       |  Content-Type: application/json                     |
       |---------------------------------------------------->|
       |                                                    |
       |                                         5. 서버는 본 요청을 처리하고 응답.
       |                                                    |
       |  HTTP/1.1 200 OK                                    |
       |  Access-Control-Allow-Origin: https://client.com    |  <-- 본 응답에도 필요
       |<----------------------------------------------------|
       |                                                    |

서버는 프리플라이트 요청에 대한 응답으로 `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` 등의 헤더를 통해 어떤 출처, 메서드, 헤더를 허용하는지 명확히 알려줘야 합니다. 브라우저는 이 응답을 보고 본 요청이 허용되는 조건인지 판단한 후, 조건이 맞으면 비로소 실제 요청(PUT /data)을 보냅니다. 만약 프리플라이트 응답에 필요한 헤더가 없거나 값이 일치하지 않으면, 브라우저는 본 요청을 보내지 않고 CORS 에러를 발생시킵니다. `Access-Control-Max-Age` 헤더는 프리플라이트 응답을 캐시할 시간을 초 단위로 지정하여, 동일한 요청에 대해 반복적인 프리플라이트 요청을 생략하여 성능을 최적화하는 데 사용됩니다.

백엔드별 CORS 설정 실전 가이드

CORS 에러의 해결은 근본적으로 서버 측에서 이루어져야 합니다. 클라이언트(브라우저)는 정책을 강제할 뿐, 정책을 결정하는 주체는 리소스를 제공하는 서버이기 때문입니다. 이제 주요 백엔드 프레임워크에서 CORS를 어떻게 설정하는지 구체적인 코드 예제와 함께 알아보겠습니다.

1. Node.js (Express)

Node.js 환경에서 가장 널리 사용되는 Express 프레임워크는 `cors`라는 매우 편리한 미들웨어 패키지를 제공합니다. 먼저 패키지를 설치합니다.

npm install cors

가장 기본적인 사용법은 모든 출처의 요청을 허용하는 것입니다. 하지만 이는 보안상 권장되지 않습니다.


const express = require('express');
const cors = require('cors');
const app = express();

// 모든 출처에서의 요청을 허용 (주의: 프로덕션 환경에서는 사용하지 마세요)
app.use(cors());

app.get('/data', (req, res) => {
  res.json({ message: 'This is CORS-enabled for all origins!' });
});

app.listen(3001, () => {
  console.log('CORS-enabled web server listening on port 3001');
});

프로덕션 환경에서는 허용할 출처를 명시적으로 지정하는 것이 안전합니다. `cors` 미들웨어에 옵션 객체를 전달하여 이를 설정할 수 있습니다.


const express = require('express');
const cors = require('cors');
const app = express();

const whitelist = ['http://localhost:3000', 'https://my-trusted-client.com'];
const corsOptions = {
  origin: function (origin, callback) {
    // origin이 undefined인 경우 (예: Postman 등 서버 간 요청) 허용
    if (!origin || whitelist.indexOf(origin) !== -1) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true, // 쿠키 등 인증 정보 포함 허용
  optionsSuccessStatus: 200 // 일부 구형 브라우저(IE11) 호환성
};

app.use(cors(corsOptions));

app.get('/data', (req, res) => {
  res.json({ message: 'CORS configuration is working!' });
});

app.listen(3001, () => {
  console.log('Server is running on port 3001 with specific CORS options');
});

위 예제에서는 `whitelist` 배열에 허용할 출처 목록을 정의하고, `origin` 함수를 통해 요청의 `Origin` 헤더가 이 목록에 있는지 동적으로 확인합니다. 또한 `credentials: true` 옵션을 통해 쿠키나 인증 헤더가 포함된 요청을 처리할 수 있도록 설정했습니다. 이 부분은 뒤에서 더 자세히 다루겠습니다.

2. Python (Django & Flask)

Django

Django에서는 `django-cors-headers`라는 패키지를 사용하는 것이 표준적인 방법입니다.

pip install django-cors-headers

설치 후, `settings.py` 파일에 몇 가지 설정을 추가해야 합니다.


# settings.py

# 1. INSTALLED_APPS에 추가
INSTALLED_APPS = [
    # ...
    'corsheaders',
    # ...
]

# 2. MIDDLEWARE에 추가 (가급적 상단에, 특히 CommonMiddleware보다 위에 위치시키는 것을 권장)
MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    # ...
]

# 3. 허용할 출처 목록 설정
CORS_ALLOWED_ORIGINS = [
    "https://my-trusted-client.com",
    "http://localhost:3000",
    "http://127.0.0.1:8000",
]

# 또는 정규 표현식을 사용할 수도 있습니다.
# CORS_ALLOWED_ORIGIN_REGEXES = [
#     r"^https://\w+\.my-trusted-client\.com$",
# ]

# 4. 쿠키를 포함한 요청을 허용하려면
CORS_ALLOW_CREDENTIALS = True

# 5. 허용할 HTTP 메서드 (기본값은 GET, HEAD, OPTIONS, POST, PUT, PATCH, DELETE)
# CORS_ALLOW_METHODS = [
#     'DELETE',
#     'GET',
#     'OPTIONS',
#     'PATCH',
...
# ]

# 6. 허용할 커스텀 헤더
# CORS_ALLOW_HEADERS = [
#     'authorization',
#     'content-type',
#     'x-csrftoken',
# ]

이처럼 `django-cors-headers`는 `settings.py`를 통해 매우 직관적이고 상세한 CORS 정책을 설정할 수 있도록 지원합니다.

Flask

Flask에서는 `Flask-Cors` 확장을 사용합니다. 

pip install -U flask-cors

사용법은 매우 간단합니다. `CORS` 객체를 생성하고 Flask 앱 인스턴스에 적용하면 됩니다.


from flask import Flask, jsonify
from flask_cors import CORS

app = Flask(__name__)

# 특정 출처, 메서드, 헤더를 허용하는 상세 설정
# resources 옵션을 사용하여 각 라우트별로 다른 CORS 정책을 적용할 수도 있음
cors_config = {
  "origins": ["http://localhost:3000", "https://my-trusted-client.com"],
  "methods": ["GET", "POST", "PUT"],
  "allow_headers": ["Content-Type", "Authorization"],
  "supports_credentials": True
}
CORS(app, **cors_config)

# 또는 간단하게 특정 라우트에만 데코레이터를 사용하여 적용
# from flask_cors import cross_origin

@app.route("/")
def hello_world():
    return jsonify({"message": "Hello, World!"})

@app.route("/api/data")
# @cross_origin(origins=["http://localhost:3000"]) # 이렇게 라우트별로도 가능
def get_data():
    return jsonify({"data": "This is protected data"})

if __name__ == '__main__':
    app.run(debug=True)

3. Java (Spring Boot)

Spring 프레임워크, 특히 Spring Boot에서는 CORS 설정을 위한 다양한 방법을 제공하며, 전역 설정과 지역 설정 모두 가능합니다.

전역 설정 (Global Configuration)

애플리케이션 전체에 동일한 CORS 정책을 적용하는 가장 일반적인 방법입니다. `WebMvcConfigurer`를 구현하는 설정 클래스를 만듭니다.


import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**") // API 경로 패턴에만 CORS 적용
            .allowedOrigins("http://localhost:3000", "https://my-trusted-client.com")
            .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
            .allowedHeaders("*") // 모든 헤더 허용
            .allowCredentials(true) // 쿠키 등 자격 증명 허용
            .maxAge(3600); // 프리플라이트 요청 캐시 시간 (초)
    }
}

이 방식은 중앙에서 모든 CORS 정책을 관리할 수 있어 일관성을 유지하기에 좋습니다.

지역 설정 (Controller-level Configuration)

특정 컨트롤러나 메서드에만 다른 CORS 정책을 적용하고 싶을 때는 `@CrossOrigin` 어노테이션을 사용합니다.


import org.springframework.web.bind.annotation.CrossOrigin;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    // 이 컨트롤러의 모든 메서드에 적용
    @CrossOrigin(origins = "http://localhost:3000")
    @GetMapping("/data1")
    public String getData1() {
        return "Data for localhost:3000";
    }
    
    // 이 특정 메서드에만 더 상세한 규칙 적용
    @CrossOrigin(
        origins = "https://my-trusted-client.com", 
        methods = {RequestMethod.GET, RequestMethod.POST},
        allowCredentials = "true"
    )
    @GetMapping("/api/v2/data")
    public String getSensitiveData() {
        return "Sensitive data for trusted client";
    }

    // 전역 설정이 적용되는 엔드포인트
    @GetMapping("/api/common")
    public String getCommonData() {
        return "This data uses global CORS config";
    }
}

지역 설정은 전역 설정을 덮어쓰므로, 유연한 정책 관리가 가능합니다. 하지만 남용할 경우 정책이 분산되어 관리가 어려워질 수 있으니 주의해야 합니다.

고급 CORS 시나리오와 주의사항

단순히 `Access-Control-Allow-Origin` 헤더를 설정하는 것만으로는 해결되지 않는 복잡한 CORS 시나리오들이 존재합니다. 특히 보안과 관련된 설정들은 신중한 접근이 필요합니다.

1. 인증 정보(Credentials) 포함 요청

쿠키, HTTP 인증 헤더, TLS 클라이언트 인증서 등 인증 정보를 포함하는 교차 출처 요청은 특별한 처리가 필요합니다. 기본적으로 브라우저는 보안상의 이유로 교차 출처 요청에 인증 정보를 포함시키지 않습니다. 이를 가능하게 하려면 클라이언트와 서버 양쪽 모두에서 명시적인 설정이 필요합니다.

  • 클라이언트 측 설정: `fetch` API를 사용한다면 `credentials: 'include'` 옵션을, `XMLHttpRequest`를 사용한다면 `withCredentials = true` 속성을 설정해야 합니다. 
    
// fetch API 예시
fetch('https://api.server.com/user/profile', {
  credentials: 'include' // 'same-origin'(기본값), 'include', 'omit'
})
.then(response => response.json())
.then(data => console.log(data));
  • 서버 측 설정: 서버는 응답 헤더에 `Access-Control-Allow-Credentials: true`를 반드시 포함해야 합니다.

여기서 매우 중요한 보안 제약사항이 있습니다. `Access-Control-Allow-Credentials: true`를 사용하는 경우, `Access-Control-Allow-Origin` 헤더의 값으로 와일드카드(`*`)를 사용할 수 없습니다. 반드시 `https://my-trusted-client.com`과 같이 명시적인 출처를 지정해야 합니다. 이는 무분별한 출처에 사용자의 민감한 정보(쿠키 등)가 노출되는 것을 방지하기 위한 브라우저의 강력한 보안 조치입니다.

2. `Access-Control-Allow-Origin: *` 의 함정

개발 중에 CORS 에러를 가장 빠르고 쉽게 해결하는 방법은 서버 응답 헤더에 `Access-Control-Allow-Origin: *`를 추가하는 것입니다. 이는 말 그대로 '모든' 출처에서의 요청을 허용하겠다는 의미입니다. 내부 개발용 API나 인증이 필요 없는 공개 API의 경우 이 설정이 유용할 수 있습니다. 하지만 사용자의 인증 정보가 필요한 서비스에 이 설정을 적용하는 것은 매우 위험합니다.

만약 악의적인 웹사이트(`https://evil-site.com`)가 당신의 서비스(`https://my-service.com`)에 `*`로 CORS가 설정된 것을 알고 있다면, 그들은 CSRF(Cross-Site Request Forgery) 공격을 시도할 수 있습니다. 사용자가 `my-service.com`에 로그인한 상태에서 `evil-site.com`을 방문하면, 악성 스크립트가 `my-service.com`의 API로 요청을 보낼 수 있습니다. `*` 설정 때문에 이 요청은 CORS 정책을 통과하고, 브라우저는 사용자의 로그인 쿠키를 함께 실어 보내게 됩니다. 결국, 악성 사이트는 사용자의 권한으로 민감한 정보를 조회하거나 데이터를 수정하는 등의 작업을 수행할 수 있게 됩니다.

따라서 프로덕션 환경에서는 `*` 사용을 최대한 지양하고, 반드시 허용해야 하는 출처들을 화이트리스트 방식으로 명확하게 관리하는 것이 보안의 기본 원칙입니다.

3. Vary: Origin 응답 헤더

서버가 요청의 `Origin` 헤더 값에 따라 동적으로 `Access-Control-Allow-Origin` 응답 헤더 값을 변경하는 경우(예: 화이트리스트 기반 동적 설정), 캐시와 관련된 문제가 발생할 수 있습니다. CDN이나 프록시 서버, 심지어 브라우저 자체도 응답을 캐싱할 때 `Origin` 헤더를 고려하지 않고 URL만으로 캐시 키를 생성할 수 있습니다. 이로 인해 `https://client-A.com`이 요청한 응답(`Access-Control-Allow-Origin: https://client-A.com`)이 캐시되었다가, 이후 `https://client-B.com`이 동일한 URL로 요청했을 때 캐시된 응답이 반환되어 CORS 에러가 발생하는 상황이 생길 수 있습니다.

이 문제를 해결하기 위해 서버는 `Vary: Origin` 헤더를 응답에 포함해야 합니다. 이 헤더는 캐시 서버에게 '이 응답은 `Origin` 요청 헤더 값에 따라 달라질 수 있으니, URL뿐만 아니라 `Origin` 헤더 값까지 고려하여 캐시를 관리하라'고 알려주는 역할을 합니다. 이를 통해 각 출처별로 올바른 CORS 응답이 캐시되고 제공될 수 있습니다.

클라이언트에서의 CORS 에러 디버깅

CORS 에러는 서버 측 설정 문제이지만, 에러를 처음 마주하고 원인을 분석하는 것은 클라이언트 개발자의 몫일 때가 많습니다. 브라우저 개발자 도구는 CORS 문제를 진단하는 데 매우 강력한 도구를 제공합니다.

  1. 콘솔(Console) 확인: 가장 먼저 할 일입니다. 콘솔에 출력되는 CORS 에러 메시지는 문제의 원인에 대한 핵심적인 단서를 담고 있습니다. "No 'Access-Control-Allow-Origin' header is present on the requested resource", "The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin", "Method ... is not allowed by Access-Control-Allow-Methods in preflight response" 등 메시지를 통해 서버 응답에 어떤 헤더가 누락되었거나 값이 잘못되었는지 파악할 수 있습니다.
  2. 네트워크(Network) 탭 확인: CORS 에러가 발생한 요청을 네트워크 탭에서 선택하여 상세 정보를 확인하는 것이 가장 중요합니다.
    • 프리플라이트 요청이 있었다면, `OPTIONS` 메서드로 보낸 요청을 먼저 확인해야 합니다. 이 요청의 응답 헤더(Response Headers)에 `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` 등이 올바르게 포함되어 있는지 검사합니다.
    • 본 요청(GET, POST 등)의 요청 헤더(Request Headers)에 `Origin` 헤더가 올바르게 포함되었는지 확인하고, 서버의 응답 헤더에 `Access-Control-Allow-Origin`이 기대한 값으로 왔는지 확인합니다.
  3. cURL 또는 Postman으로 직접 요청 보내보기: 브라우저를 통하지 않고 cURL이나 Postman 같은 도구를 사용하여 API 서버에 직접 요청을 보내보는 것도 좋은 방법입니다. 만약 이 도구들로 요청했을 때 정상적으로 응답이 온다면, 문제는 서버 자체의 로직보다는 서버의 CORS 설정에 국한된 것임을 확신할 수 있습니다. 직접 `Origin` 헤더를 추가하여 요청을 보내며 서버의 반응을 테스트할 수도 있습니다. 
    
# cURL을 사용한 프리플라이트 요청 시뮬레이션
curl -i -X OPTIONS https://api.server.com/data \
-H "Origin: http://localhost:3000" \
-H "Access-Control-Request-Method: PUT" \
-H "Access-Control-Request-Headers: Content-Type"

# cURL을 사용한 본 요청 시뮬레이션
curl -i -X PUT https://api.server.com/data \
-H "Origin: http://localhost:3000" \
-H "Content-Type: application/json" \
-d '{"key":"value"}'

이러한 디버깅 과정을 통해 "서버가 `Access-Control-Allow-Methods` 헤더에 `PUT`을 포함하여 응답하지 않았습니다" 와 같이 백엔드 개발자에게 전달할 수 있는 구체적이고 명확한 문제 리포트를 작성할 수 있게 됩니다.

결론: CORS는 장벽이 아닌 소통의 규칙이다

CORS 에러는 웹 개발 과정에서 만나는 귀찮은 장애물처럼 느껴질 수 있습니다. 하지만 그 본질을 이해하고 나면, CORS는 무질서한 인터넷 환경에서 애플리케이션을 보호하고, 신뢰할 수 있는 주체 간의 데이터 교환을 위한 잘 설계된 '소통의 규칙'임을 알 수 있습니다. 동일 출처 정책(SOP)이라는 강력한 보안 기반 위에서, CORS는 필요한 만큼만, 그리고 필요한 대상에게만 선택적으로 문을 열어주는 현대 웹의 필수적인 메커니즘입니다.

무조건 `Access-Control-Allow-Origin: *`를 사용하는 임시방편적인 해결책은 당장의 에러는 없애줄지 몰라도, 장기적으로는 애플리케이션의 보안을 심각하게 위협할 수 있습니다. 대신, 이 글에서 다룬 내용들을 바탕으로 당신의 애플리케이션에 필요한 출처, 메서드, 헤더가 무엇인지 명확히 정의하고, 사용하는 백엔드 기술에 맞는 올바른 방법으로 CORS 정책을 설정하는 것이 중요합니다. CORS를 제대로 이해하고 다룰 수 있다는 것은, 단순히 에러를 해결하는 능력을 넘어 웹 보안의 기본 원칙을 이해하고 안전한 웹 애플리케이션을 구축할 수 있는 역량을 갖춘 개발자라는 증거가 될 것입니다. 이제 더 이상 콘솔의 붉은 CORS 에러 메시지 앞에서 좌절하지 말고, 자신감을 가지고 문제의 근원을 분석하고 해결해 나가길 바랍니다.


0 개의 댓글:

Post a Comment