Published 2022. 11. 18. 17:56

CORS

웹

CORS 란?

CORS 는 Cross Origin Resource Sharing의 약자입니다.

Cross : 교차, Origin : 출처, Resource : 자원, Sharing : 공유

말 그대로 서로 다른 출처끼리 자원을 공유하겠다는 뜻입니다.

(출처: MDN 공식 문서)

좌측의 웹 페이지는 domain-a.com 에 접속하면 볼 수 있는 웹 페이지입니다.

domain-a.com 에 접속하면 웹 페이지를 렌더링하기 위해서 총 5개의 API 요청이 발생하고 있습니다.

이 중 셋은 Same Origin 이고 둘은 Cross Origin 입니다.

상단의 파란색 네모 박스 안에 있는 API 는 Same Origin 입니다.

domain-a.com 에서 웹 서버 domain-a.com 으로 요청을 보냈기 때문에 Same Origin 입니다.

반면 하단의 빨간색 네모 박스 안에 있는 API 는 Cross Origin 입니다.

domain-a.com 에서 웹서버 domain-b.com 으로 요청을 보냈기 때문입니다.

서버는 허용되지 않은 Origin 으로부터 요청을 받으면 요청을 거부하기 때문에 하단의 빨간색 네모 박스에 있는 컨텐츠는 서버로부터 제공받지 못지 못합니다.

정리하면,

요청을 보내는 Client 와 요청을 받는 Server 의 도메인이 다르면 Cross Origin 이라 부르고 Client 의 요청은 거부됩니다.

CORS 는 언제 발생하는가?

CORS 는 Cross(서로 다른) Origin 끼리 통신할 때 발생합니다.

참고) Origin 이란?

예시 URL 을 보며 Origin 에 대해 알아보겠습니다.

https://developer.mozilla.org:443/ko/docs/Web/HTTP/CORS

- https : 프로토콜

- developer.mozilla.org : 호스트

- :443 : 포트

Origin 은 프로토콜, 호스트, 포트를 포함하는 개념입니다.

Origin 은 셋 중 하나만 달라져도 CORS 가 발생합니다.

몇 가지 예시를 통해 CORS 여부를 확인해보겠습니다.

예시	CORS 여부
http://google.com -> https://google.com	O, 프로토콜이 다르기 때문
https://api.google.com -> https://google.com	O, 호스트가 다르기 때문
https://google.com:8080 -> https://google.com	O, 포트가 다르기 때문
https://google.com/console -> https://google.com	X
https://google.com/console?id=1 -> https://google.com	X

그렇다면 Cross(서로 다른) Origin 간의 통신은 절대 불가능한 걸까요?

=> Cross(서로 다른) Origin 간의 통신 가능합니다!

서로 다른 Origin 간의 통신이 필요할 수도 있는데, 그땐 어떻게 해야 할까요?

=> HTTP Header 를 조작하면 됩니다. 구체적으로는 HTTP Header 에 요청을 보내는 Origin 에 대한 정보를 추가하면 됩니다.

CORS 를 허용하는 방법

CORS 를 허용하는 방법은 Preflight, Simple Request 가 있습니다.

Preflight 란?

Preflight 는 브라우저가 main(본) 요청을 보내기 전에 보내는 사전 요청입니다.

사전 요청은 API 요청을 보낼 때마다 매번 보내는 걸까요?

=> 그렇지 않습니다.

Simple Request

main(본) 요청이 Simple Request 의 조건을 만족한다면 Preflight 를 보낼 필요가 없습니다.

Simple Request 의 조건은 다음과 같습니다.

- HTTP METHOD 가 GET, HEAD, POST 중 하나일 때

- Request 객체 생성 시 자동으로 생성되는 헤더들(Accept, Accept-Language, Content-Language, Content-Type) 외의 다른 HTTP Header 가 조작되지 않은 요청

- Content-Type 의 값이 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나일 때

- XHR 객체로 API 요청을 보낼 때 xhr.upload.addEventListener() 를 호출하지 않은 요청

- API 요청을 보낼 때 ReadableStream 객체가 사용되지 않은 요청

Preflight 의 역할

Preflight 는 실제 요청을 보내기 전, 실제 요청이 안전한지 판단하기 위해 보내는 사전 요청입니다.

Preflight 는 어떻게 실제 요청의 안전 여부를 판단한다는 걸까요?

=> Preflight 의 Request, Response 객체를 보면 알 수 있습니다.

Preflight Request

Preflight 의 Request 객체에서는 main(본) 요청의 정보들을 Access-Control-Request- 헤더들에 저장합니다.

Preflight Request 의 HTTP METHOD 는 OPTIONS 입니다.

만약 main(본) 요청에서 HTTP 헤더를 조작해 다른 헤더를 추가한다면 Access-Control-Request-Headers에 [추가된 Header 이름] 이 저장됩니다. 이는 새로 추가된 헤더도 허용해 달라는 의미입니다.

Preflight Response

서버에서는 Preflight Request 의 헤더를 기반으로 Preflight Response 를 응답합니다. 구체적으로 말하자면 Access-Controller-Allow- 로 시작하는 헤더를 추가해서 응답합니다.

그런데 이 과정은 서버가 자동으로 해주지 않고 개발자가 직접 설정해줘야 하는 부분입니다.

// 모듈 import
const express = require('express');
const cors = require('cors');

const app = express();
app.use(cors({
  origin: 'http://example.com', // 허용하는 Origin 추가
  methods: ['GET', 'PUT', 'POST'], // 허용하는 Method 추가
  allowedHeaders: "Something", // 허용하는 Header 추가
  credentials: true, // Access-Control-Allow-Credentials CORS header 설정
});