CORS(교차 출처 리소스 공유)란?

동일 출처 정책으로 제한되어 있는, 다른 출처로의 요청과 그 응답의 읽기를 서버가 허가한 범위에서 인정하기 위한 구조. 서버는 Access-Control-Allow-Origin 등의 응답 헤더로 어느 출처로부터의 읽기를 허용할지 나타낸다. Content-Type이 application/json인 POST처럼 단순한 폼 전송으로는 만들 수 없는 요청에서는, 브라우저가 먼저 OPTIONS 메서드로 사전 확인(프리플라이트)을 보낸다. 브라우저가 지키는 규칙이며, 서버를 공격으로부터 지키는 구조는 아니다.

일본어 명칭: CORS(オリジン間リソース共有)

CORS(교차 출처 리소스 공유)은(는) 웹 기술 기초 등 1개 분야의 연습 문제 1개에 나와요.

분야: 웹 기술 기초

단순 요청과 프리플라이트

GET이나 폼으로 보낼 수 있는 형식(application/x-www-form-urlencoded, multipart/form-data, text/plain)의 POST 등은 확인 없이 보내지며, 응답을 스크립트가 읽을 수 있는지만 Access-Control-Allow-Origin으로 정해집니다. 그 밖의 메서드나 Content-Type, 독자적인 헤더를 사용하는 요청에서는 브라우저가 먼저 OPTIONS로, 사용할 메서드와 헤더를 Access-Control-Request-Method 등으로 전합니다. 서버가 허가를 돌려주면 브라우저는 본래의 요청을 보냅니다.

Cookie를 붙일 때

다른 출처로 가는 요청에 Cookie를 붙여 보내려면, 스크립트 쪽에서 credentials를 지정하고 서버가 Access-Control-Allow-Credentials: true를 돌려주어야 합니다. 이때 Access-Control-Allow-Origin에는 모든 것을 나타내는 *를 사용할 수 없으며, 허가할 출처를 구체적으로 씁니다. 허가할 출처를 너무 넓히면 다른 사이트에서 이용자의 정보를 읽힐 우려가 있습니다.

흔한 오해

CORS 오류는 브라우저가 응답을 스크립트에 넘기지 않았다는 것을 나타내는 것으로, 요청 자체는 서버에 도달해 있는 경우가 있습니다. 또한 CORS는 브라우저가 지키는 규칙이므로 명령줄 도구나 다른 서버로부터의 요청은 막지 않습니다. 서버의 데이터를 지키려면 인증이나 권한 확인을 따로 수행합니다.

도전해 보기: CORS(교차 출처 리소스 공유) 관련 문제

https://app.example.com 페이지의 JavaScript가 fetch를 사용하여 https://api.example.net/orders로 Content-Type: application/json 본문을 붙인 POST 요청을 보내려 한다. 이때 CORS의 동작으로 올바른 것은?

ACORS는 브라우저 이외에서도 작동하므로, 서버의 허가가 없으면 명령줄 도구에서 보낸 POST도 네트워크 도중에서 차단된다
B브라우저는 먼저 OPTIONS 메서드로 사전 확인(프리플라이트)을 보내고, 서버가 헤더로 허가를 돌려준 경우에만 본래의 POST를 보낸다
C다른 출처로 가는 요청은 항상 확인 없이 보내지며, 서버가 응답에 아무것도 붙이지 않아도 페이지의 JavaScript는 응답을 읽을 수 있다

정답과 해설 보기

정답: B. 브라우저는 먼저 OPTIONS 메서드로 사전 확인(프리플라이트)을 보내고, 서버가 헤더로 허가를 돌려준 경우에만 본래의 POST를 보낸다

CORS는 동일 출처 정책으로 제한되어 있는, 다른 출처로의 요청과 그 응답의 읽기를 서버가 허가한 범위에서 인정하는 구조입니다. Content-Type이 application/json인 POST는 단순한 폼 전송으로는 만들 수 없는 종류의 요청이므로, 브라우저는 먼저 OPTIONS로 사용할 메서드와 헤더를 전하여 허가를 확인합니다. 서버의 응답에 Access-Control-Allow-Origin 등의 허가가 없으면 브라우저는 본래의 요청을 보내지 않습니다. CORS는 브라우저가 지키는 규칙이므로, 서버는 따로 인증이나 권한 확인으로 자신을 지켜야 합니다.

자주 묻는 질문

CORS 오류는 클라이언트 쪽에서 고칠 수 있나요?

아니요. 어느 출처로부터의 읽기를 허용할지는 서버가 정하므로, API 서버의 응답에 적절한 허가 헤더를 붙여야 합니다. 자신이 관리하지 않는 API라면 자신의 서버를 경유하여 호출하는 방법도 있습니다.

동일 출처 정책과 CORS는 어떤 관계인가요?

동일 출처 정책이 다른 출처의 응답 읽기를 원칙적으로 금지하고, CORS는 서버가 명시한 범위에서 그 예외를 인정하는 구조입니다. CORS 허가를 돌려주지 않으면 동일 출처 정책의 제한이 그대로 작동합니다.

해설 속 CORS(교차 출처 리소스 공유)

CORS는 동일 출처 정책으로 제한되어 있는, 다른 출처로의 요청과 그 응답의 읽기를 서버가 허가한 범위에서 인정하는 구조입니다.
https://app.example.com 페이지의 JavaScript가 fetch를 사용하여 https:…

CORS(교차 출처 리소스 공유)이(가) 나오는 문제 (1)

https://app.example.com 페이지의 JavaScript가 fetch를 사용하여 https://api.example.net/orders로 Content-Type: application/json 본문을 붙인 POST 요청을 보내려 한다. 이때 CORS의 동작으로 올바른 것은?