CORS의 정의와 문제 해결 방법: 로드밸런서와 OPTIONS 메서드 활용

웹 개발자들은 종종 CORS(Cross-Origin Resource Sharing) 문제를 겪곤 합니다. 이는 동일 출처 정책(Same-Origin Policy)에 의해 브라우저가 다른 출처의 리소스에 접근하는 것을 제한할 때 발생하는 문제입니다. 이 글에서는 CORS가 무엇인지, 왜 문제가 발생하는지, 그리고 로드밸런서에서 OPTIONS 메서드를 활용해 이를 어떻게 해결할 수 있는지에 대해 알아봅니다..

1. CORS란 무엇인가?

1.1 CORS의 정의

CORS는 웹 애플리케이션이 다른 도메인에서 호스팅된 리소스에 접근할 수 있도록 허용하는 메커니즘입니다. 보안상의 이유로, 웹 브라우저는 기본적으로 동일 출처 정책을 따르며, 다른 출처에서의 리소스 요청을 차단합니다.

CORS는 이 제약을 완화해 특정 도메인에서 리소스 요청을 허용할 수 있도록 서버가 클라이언트에게 허가를 부여하는 방식입니다. 이를 위해 서버는 응답 헤더에 Access-Control-Allow-Origin 등의 헤더를 추가하여 클라이언트가 요청을 할 수 있도록 합니다.

1.2 CORS 문제의 원인

CORS 문제는 클라이언트가 다른 도메인에 있는 리소스를 요청할 때 서버가 이에 대해 적절한 CORS 헤더를 제공하지 않을 경우 발생합니다. 브라우저는 보안상의 이유로 이러한 요청을 차단하며, 개발자 도구의 콘솔에는 CORS 오류가 나타납니다.

1.3 CORS 헤더의 주요 요소

• Access-Control-Allow-Origin: 요청을 허용할 출처
• Access-Control-Allow-Methods: 허용할 HTTP 메서드 (GET, POST, OPTIONS 등)
• Access-Control-Allow-Headers: 허용할 커스텀 헤더
• Access-Control-Allow-Credentials: 인증 정보(쿠키 등)의 전송 허용 여부

2. OPTIONS 메서드와 Preflight 요청

2.1 OPTIONS 메서드란?

OPTIONS 메서드는 서버가 클라이언트의 요청을 처리하기 전에 해당 요청을 허용할 수 있는지 확인하는 용도로 사용됩니다. 이 메서드는 CORS 사전 요청(Preflight Request)에서 사용됩니다. 클라이언트가 POST, PUT, DELETE와 같은 비표준 메서드를 사용하거나, 커스텀 헤더를 포함한 요청을 보내려 할 때, 브라우저는 먼저 OPTIONS 메서드를 통해 서버에 사전 요청을 보냅니다.

2.2 Preflight 요청의 동작 원리

클라이언트는 OPTIONS 메서드로 서버에 요청을 보내며, 서버는 응답으로 허용할 메서드와 헤더를 명시한 CORS 헤더를 반환합니다. 이 응답에 따라 브라우저는 실제 요청을 서버로 전송할지 결정합니다.

Preflight 요청 예시는 다음과 같습니다:

Preflight 요청 (OPTIONS 요청):

OPTIONS /api/resource HTTP/1.1
Host: api.example.com
Origin: https://www.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-Custom-Header, Content-Type

서버 응답:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Allow-Credentials: true

3. 로드밸런서에서 CORS 문제 해결

로드밸런서는 클라이언트와 백엔드 서버 사이에 위치하여 트래픽을 관리하고 분배합니다. 로드밸런서가 CORS 문제를 해결하는 방법 중 하나는 클라이언트의 요청에 대해 적절한 CORS 헤더를 추가하거나 수정하는 것입니다.

3.1 NGINX에서의 OPTIONS 메서드 처리

NGINX와 같은 로드밸런서에서 CORS 문제를 해결하기 위해서는 OPTIONS 메서드를 처리하고, 서버로부터 적절한 CORS 헤더를 응답하도록 설정할 수 있습니다.

NGINX 설정 예시는 다음과 같습니다:

server {
    location /api/ {
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
            add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
            return 204;
        }
        # 다른 요청 처리
    }
}

이 설정은 클라이언트가 OPTIONS 메서드를 보낼 때, 서버가 CORS 관련 헤더를 응답하도록 하고 204 No Content 상태 코드를 반환합니다. 이는 Preflight 요청에 대한 적절한 응답을 제공하여 클라이언트가 실제 요청을 보낼 수 있도록 합니다.

3.2 AWS ALB에서의 CORS 처리

AWS Application Load Balancer(ALB)를 사용하는 경우, ALB는 직접적으로 CORS 헤더를 관리하지 않지만, AWS API Gateway나 Lambda@Edge와 같은 서비스를 통해 CORS 헤더를 처리할 수 있습니다. API Gateway에서는 손쉽게 CORS 설정을 추가할 수 있으며, Preflight 요청에 대한 응답도 자동으로 처리됩니다.

3.3 Apache에서의 OPTIONS 메서드 처리

Apache 로드밸런서에서는 mod_headers 모듈을 사용하여 CORS 헤더를 설정할 수 있습니다. 다음은 Apache에서 OPTIONS 메서드를 처리하는 예시입니다:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
    Header set Access-Control-Allow-Methods "POST, GET, OPTIONS"
    Header set Access-Control-Allow-Headers "Authorization, Content-Type"
</IfModule>

<Limit OPTIONS>
    Order allow,deny
    Allow from all
</Limit>

이 설정을 통해 Apache는 모든 출처에서의 요청을 허용하고, OPTIONS 메서드에 대해 적절한 응답을 할 수 있습니다.

4. 결론

CORS 문제는 웹 애플리케이션이 다른 도메인에서 리소스를 요청할 때 발생하는 일반적인 문제입니다. OPTIONS 메서드를 활용한 Preflight 요청 처리와 함께, 로드밸런서에서 적절한 CORS 헤더를 설정함으로써 이러한 문제를 효과적으로 해결할 수 있습니다.

로드밸런서를 사용하면 백엔드 서버 코드를 수정하지 않고도 CORS 문제를 해결할 수 있기 때문에, 로드밸런서의 역할이 매우 중요합니다. 특히 NGINX, AWS ALB, Apache와 같은 로드밸런서에서 CORS 문제를 해결하는 다양한 방법을 사용해볼 수 있습니다.