교차 출처 리소스를 안전하게 공유
브라우저의 동일 출처 정책이 다른 출처의 리소스 읽기를 차단합니다. 이 메커니즘은 악성 사이트가 다른 사이트의 데이터를 읽는 것을 막지만 합법적인 사용도 차단합니다.
최신 웹 앱은 다른 출처에서 리소스를 가져오려고 하는 경우가 많습니다. 예를 들어 다른 도메인에서 JSON 데이터를 검색하거나 다른 사이트의 이미지를 <canvas>
요소로 로드하려고 합니다. 누구나 읽을 수 있는 공개 리소스일 수 있지만 동일 출처 정책으로 인해 사용이 차단됩니다. 개발자는 지금까지 JSONP와 같은 해결 방법을 사용했습니다.
교차 출처 리소스 공유 (CORS)는 이 문제를 표준화된 방식으로 해결합니다. CORS를 사용 설정하면 서버가 브라우저에 추가 출처를 사용할 수 있음을 알립니다.
리소스 요청은 웹에서 어떻게 작동하나요?
브라우저와 서버는 하이퍼텍스트 전송 프로토콜 (HTTP)을 사용하여 네트워크를 통해 데이터를 교환할 수 있습니다. HTTP는 리소스를 가져오는 데 필요한 정보를 포함하여 요청자와 응답자 간의 통신 규칙을 정의합니다.
HTTP 헤더는 클라이언트와 서버 간의 메시지 교환을 협상하며 액세스를 결정하는 데 사용됩니다. 브라우저의 요청과 서버의 응답 메시지는 모두 헤더와 본문으로 나뉩니다.
헤더
메시지 유형 또는 메시지 인코딩과 같은 메시지 관련 정보입니다. 헤더에는 키-값 쌍으로 표현되는 다양한 정보가 포함될 수 있습니다. 요청 헤더와 응답 헤더는 서로 다른 정보를 포함합니다.
샘플 요청 헤더
Accept: text/html
Cookie: Version=1
이 헤더는 "응답으로 HTML을 받고 싶습니다. 여기 쿠키가 있어요."
샘플 응답 헤더
Content-Encoding: gzip
Cache-Control: no-store
이 헤더는 '이 응답의 데이터는 gzip으로 인코딩되어 있습니다. 캐시하지 마세요.'
본체
메시지 자체입니다. 일반 텍스트, 이미지 바이너리, JSON, HTML 또는 기타 여러 형식일 수 있습니다.
CORS 작동 방식
동일 출처 정책은 교차 출처 요청을 차단하도록 브라우저에 지시합니다. 다른 출처의 공개 리소스가 필요한 경우 리소스 제공 서버는 요청을 전송하는 출처에서 리소스에 액세스할 수 있다고 브라우저에 알립니다. 브라우저가 이 정보를 기억하여 해당 리소스에 대해 교차 출처 리소스 공유를 허용합니다.
1단계: 클라이언트 (브라우저) 요청
브라우저가 교차 출처 요청을 하면 브라우저는 현재 출처 (스키마, 호스트, 포트)가 있는 Origin
헤더를 추가합니다.
2단계: 서버 응답
서버는 이 헤더를 보고 액세스를 허용하려고 할 때 요청 출처를 지정하는 Access-Control-Allow-Origin
헤더를 응답에 추가합니다 (모든 출처를 허용하려면 *
).
3단계: 브라우저에서 응답 수신
브라우저는 적절한 Access-Control-Allow-Origin
헤더와 함께 이 응답을 확인하면 응답 데이터를 클라이언트 사이트와 공유합니다.
CORS와 사용자 인증 정보 공유
개인 정보 보호를 위해 CORS는 일반적으로 요청자가 식별되지 않는 익명 요청에 사용됩니다. 발신자를 식별할 수 있는 CORS를 사용할 때 쿠키를 전송하려면 요청과 응답에 헤더를 추가해야 합니다.
요청
다음 예시와 같이 가져오기 옵션에 credentials: 'include'
를 추가합니다.
여기에는 다음과 같이 요청과 함께 쿠키가 포함됩니다.
fetch('https://example.com', {
mode: 'cors',
credentials: 'include'
})
응답
Access-Control-Allow-Origin
는 특정 출처 (*
를 사용한 와일드 카드 없음)로 설정해야 하고 Access-Control-Allow-Credentials
는 true
로 설정해야 합니다.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
복잡한 HTTP 호출을 위한 프리플라이트 요청
웹 앱에서 복잡한 HTTP 요청을 수행하면 브라우저는 요청 체인 시작 부분에 실행 전 요청을 추가합니다.
CORS 사양은 다음과 같이 복잡한 요청을 정의합니다.
- GET, POST, HEAD 이외의 메서드를 사용하는 요청입니다.
Accept
,Accept-Language
,Content-Language
이외의 헤더가 포함된 요청.application/x-www-form-urlencoded
,multipart/form-data
,text/plain
이외의Content-Type
헤더가 있는 요청
브라우저는 필요한 프리플라이트 요청을 자동으로 만들고 실제 요청 메시지 전에 전송합니다. 실행 전 요청은 다음 예시와 같이 OPTIONS
요청입니다.
OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: DELETE
서버 측에서 요청을 수신하는 앱은 애플리케이션이 이 출처에서 허용하는 메서드에 관한 정보로 프리플라이트 요청에 응답합니다.
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS
서버 응답에는 실행 전 결과를 캐시하는 기간(초)을 지정하는 Access-Control-Max-Age
헤더가 포함될 수도 있습니다. 이렇게 하면 클라이언트가 프리플라이트 요청을 반복하지 않고도 복잡한 요청을 여러 개 보낼 수 있습니다.