웹 보안이 점점 중요해지는 시대, 다양한 출처에서 자원을 로드하고 API를 호출하는 환경에서 CORS는 반드시 이해하고 정확히 구현해야 할 핵심 개념입니다. 본 글에서는 CORS의 기본 개념부터 요청 유형, 요청/응답 헤더 구성, 그리고 실제 구현 시 주의사항까지 상세하게 설명드립니다.
CORS(Cross-Origin Resource Sharing)란?
CORS(Cross-Origin Resource Sharing)는 교차 출처 자원 공유를 의미하며, 브라우저가 보안을 위해 기본적으로 적용하는 “동일 출처 정책(Same-Origin Policy)”을 제어하기 위한 HTTP 기반의 메커니즘입니다.
다른 출처(origin)란, 프로토콜(http/https), 도메인, 포트 중 하나라도 다른 경우를 의미합니다. 예를 들어 https://a.example.com과 http://a.example.com, 또는 https://api.example.com은 서로 다른 출처입니다.
기본적으로 브라우저는 보안상의 이유로 교차 출처 요청을 차단하지만, CORS를 통해 특정 조건하에 타 출처의 요청을 허용할 수 있습니다.
왜 CORS가 필요한가?
초기 웹 환경에서는 모든 리소스가 같은 출처에서 제공되었지만, 현대 웹은 다음과 같은 구조로 진화했습니다:
- 이미지, 스타일시트, JS 파일 등을 CDN 등 외부 출처에서 로딩
- 백엔드 API 서버와 프론트엔드 서버가 분리된 구조
- 제3자 도메인(Analytics, 광고 등)과의 연동
이러한 환경에서 리소스를 안전하게 공유하기 위해 CORS가 도입되었으며, 보안을 해치지 않으면서도 유연한 통신이 가능하도록 지원합니다.
CORS 요청의 유형
CORS 요청은 크게 Simple 요청과 Preflight 요청으로 구분됩니다.
1. Simple Request (단순 요청)
브라우저가 Preflight(사전 요청) 없이 서버에 직접 요청을 보내려면, 다음 조건을 모두 만족해야 합니다.
- HTTP 메서드는 반드시 GET, HEAD, 또는 POST 중 하나여야 합니다.
- Content-Type은 아래 세 가지 중 하나만 사용할 수 있습니다.
- application/x-www-form-urlencoded, multipart/form-data, text/plain
- 커스텀 헤더를 포함하면 안 됩니다.
- 예: X-Custom-Header와 같은 사용자 정의 헤더는 사용 불가
이 조건을 만족하면 브라우저는 사전 요청 없이 바로 API 요청을 보냅니다.
예시 요청 헤더 :
Origin: http://xyz.com예시 서버 응답 헤더 :
Access-Control-Allow-Origin: http://xyz.com또는
Access-Control-Allow-Origin: *⚠️ 단, Access-Control-Allow-Origin: *은 credentials(쿠키, 인증토큰 등)을 포함한 요청에는 사용할 수 없습니다.
2. Preflight Request (사전 요청)
보다 복잡한 요청은 사전 요청(preflight)을 통해 서버에 질의 후 응답에 따라 실제 요청을 보냅니다. 아래 조건 중 하나라도 해당하면 Preflight 요청이 발생합니다:
- GET 또는 POST 외의 HTTP 메서드 사용 (예: PUT, DELETE)
- Content-Type이 기본 유형이 아님 (예: application/json)
- 사용자 정의 헤더 포함 (예: X-Requested-With 등)
예시 요청 :
Origin: http://xyz.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-Custom-Header서버 응답 :
Access-Control-Allow-Origin: http://xyz.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: X-Custom-Header응답이 허용되면 브라우저는 실제 요청을 전송합니다.
요청/응답 헤더 이해하기
요청 및 응답 헤더의 구성요소를 이해하면 리소스 액세스를 허용하거나 제한하기 전에 두 대상 간에 어떤 정보가 공유되는지 더 잘 이해할 수 있습니다.
요청 헤더 (Client → Server)
- Origin: 요청을 보낸 출처를 나타냅니다.
- Access-Control-Request-Method: 요청을 보내는 데 사용할 HTTP 메서드를 나타내며, 사전 요청에서 사용됩니다.
- Access-Control-Request-Headers: 요청에 포함된 사용자 정의 헤더를 나타내며, 사전 요청에서 사용됩니다.
응답 헤더 (Server → Client)
- Access-Control-Allow-Origin: 서버의 리소스에 접근할 수 있는 출처를 지정합니다. 모든 출처를 허용하려면
*또는 특정 출처 URL을 사용합니다. - Access-Control-Expose-Headers: 클라이언트가 액세스할 수 있는 응답 헤더를 나열합니다.
- Access-Control-Max-Age: 사전 요청(preflight)의 응답을 캐시할 수 있는 시간을 초 단위로 지정합니다.
- Access-Control-Allow-Methods: 요청이 허용되는 HTTP 메서드 목록을 나타냅니다.
- Access-Control-Allow-Headers: 요청 시 사용할 수 있는 HTTP 헤더 목록을 나타냅니다.
오류 사례 및 해결 방안
CORS 오류는 실무 환경에서 자주 발생하며, 대부분 아래와 같은 원인으로 발생합니다:
CORS를 활성화하면 서버가 브라우저에 추가적인 출처를 사용할 수 있다는 것을 알려줄 수 있습니다. HTML5 플레이어에서 백엔드 API와 프록시를 호출할 때 이러한 설정이 필요합니다.
- 서버에 CORS 관련 응답 헤더가 누락된 경우
- 요청의 출처(origin)가 서버의 허용 목록에 포함되지 않은 경우
- 인증 정보(credentials)가 포함된 요청인데도 Access-Control-Allow-Origin이 와일드카드(*)로 설정된 경우
📌 오류 사례: AWS S3에서 콘텐츠 로딩 시 예를 들어, 도브러너 DRM 플레이어에서 mpd 파일을 로딩하려 할 때 S3 버킷에 CORS 정책이 설정되지 않았다면 다음과 같은 오류가 발생할 수 있습니다.
Access to fetch at 'https://bucket.s3.amazonaws.com/xxx.mpd' from origin 'https://player.doverunner.com' has been blocked by CORS policy.🔧 해결 방안: AWS S3 버킷의 “권한” 탭에서 아래와 같은 CORS 정책을 JSON 형식으로 추가합니다.
[
{
"AllowedHeaders": ["*"],
"AllowedMethods": ["GET"],
"AllowedOrigins": ["*"],
"ExposeHeaders": []
}
]※ 보안을 강화하려면 AllowedOrigins에 * 대신 실제 origin을 명시하는 것을 권장합니다.
올바른 CORS 구현을 위한 체크리스트
- Access-Control-Allow-Origin 설정 시 와일드카드(*) 사용은 편리하지만, 인증 정보가 포함된 요청에는 보안상 위험할 수 있습니다. 민감한 API에는 반드시 명확한 출처(origin)를 지정하세요.
- Preflight 요청(OPTIONS)이 실패하는 경우, 서버 응답에서 허용 메서드와 헤더를 정확히 명시했는지 확인해야 합니다.
- 클라우드 환경(S3, CloudFront 등)에서는 서비스별 CORS 정책을 별도로 설정해야 하며, 캐시 정책으로 인해 적용 지연이 발생할 수 있습니다.
- Content-Type이 기본 MIME 유형이 아닌 경우(예: application/json), 브라우저는 Preflight 요청을 전송하므로 서버 설정이 이에 대응되어야 합니다.
- 설정 후에는 반드시 브라우저 개발자 도구(F12)의 네트워크 탭을 통해 CORS 응답 헤더가 정확히 적용되었는지 확인하세요.
CORS는 단순한 설정 문제로 보일 수 있지만, 잘못 구현할 경우 데이터 유출 및 보안 취약점으로 이어질 수 있는 민감한 항목입니다. Doverunner는 다양한 플랫폼 환경에서 발생하는 콘텐츠 보안 위협에 대응해 온 경험을 바탕으로, CORS 설정을 포함한 안전한 콘텐츠 접근 정책 수립을 지원합니다.
본 가이드를 참고하여 교차 출처 환경에서도 안전하고 유연한 웹 서비스를 구현해보시기 바랍니다.
