CORS
기술노트
🌐 CORS (Cross-Origin Resource Sharing)
CORS는 '교차 출처 리소스 공유'라는 뜻으로, 웹 브라우저에서 실행되는 스크립트가 자신이 속하지 않은 다른 출처(Origin)의 리소스를 요청할 수 있도록 허용하는 정책입니다. 현대 웹 애플리케이션에서 매우 중요한 보안 메커니즘입니다.
🤔 출처(Origin)란?
웹에서 '출처'는 URL의 프로토콜(Protocol), 호스트(Host), 포트(Port) 세 가지 조합으로 결정됩니다. 이 중 하나라도 다르면 다른 출처로 간주됩니다.
- `https://example.com:80` 와 `http://example.com:80` → 프로토콜이 달라 '다른 출처'
- `https://example.com` 와 `https://api.example.com` → 호스트(도메인)가 달라 '다른 출처'
- `https://example.com` 와 `https://example.com:8080` → 포트가 달라 '다른 출처'
기본적으로 웹 브라우저는 동일 출처 정책(Same-Origin Policy, SOP)에 따라 다른 출처의 리소스를 요청하는 것을 차단합니다. CORS는 이 제한을 안전하게 해제하기 위한 방법입니다.
⚙️ CORS의 동작 방식
1. 웹 브라우저(클라이언트)가 다른 출처의 API(`https://api.example.com/data`)를 요청합니다. 2. 브라우저는 요청 헤더에 `Origin: https://example.com` 정보를 담아 보냅니다. 3. 서버는 이 요청을 받고, 응답 헤더에 `Access-Control-Allow-Origin: https://example.com` (또는 `*` ) 정보를 포함하여 응답합니다. 4. 브라우저는 응답 헤더를 보고, 서버가 자신의 출처를 허용했는지 확인합니다. 허용되었다면 리소스를 정상적으로 처리하고, 그렇지 않다면 CORS 오류를 발생시키며 응답을 거부합니다.
- Preflight Request : `PUT`, `DELETE` 등 특정 메서드나 커스텀 헤더가 포함된 요청의 경우, 브라우저는 실제 요청을 보내기 전에 `OPTIONS` 메서드를 사용해 서버가 해당 요청을 허용하는지 미리 확인하는 '예비 요청'을 보냅니다.
💡 개발자 핵심 Point
- 프론트엔드 개발 시, API 서버와 프론트엔드 서버의 출처가 다를 때 거의 반드시 CORS 오류를 마주하게 됩니다.
- CORS 오류는 프론트엔드(브라우저)의 보안 정책 때문에 발생하는 문제이며, 해결은 백엔드(서버)에서 해야 합니다.
- 백엔드 개발자는 응답 헤더에 `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods` 등을 정확히 설정하여, 허용된 출처와 메서드의 요청만 처리하도록 구현해야 합니다.
