CORS(Cross-origin resource sharing)는 무엇인가? | SOP (Same-origin policy) | 자세히 이해하기

😎 CORS를 알아보기 전에 먼저 알아야할 것

🤔 SOP (Same-origin policy) 이란?

The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one 
origin can interact with a resource from another origin.

 

MDN에 따르면 동일 출처 정책(same-origin policy)은 어떤 출처(origin)에서 불러온 문서나 스크립트가 다른 출처에서 가져온 리소스와 상호작용하는 것을 제한하는 중요한 보안 방식이다. 동일 출처 정책은 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여준다. 너무 길고 어렵다.

 

그래서 간단히 말하면, origin이 같을 때만 접근을 허용해주는 보안방식이다.

이때 Protocol, Host, Port가 같다면 origin이 같다고 할 수 있다.

🤓 Origin 예제

http://kworld.tistory.com와 같은 origin을 찾아보자!

 

1. https://kworld.tistory.com
2. http://kworld.tistory.com:443
3. http://kworld.tistory.com/10

 

정답은 2,3이다.

1번은 protocol이 https이므로 같은 origin이 아니다.

2번은 port 443이 붙어있지만, tistory.com의 기본 port가 443이기 때문에 같은 origin이다. 기본 port는 평소에 생략하고 쓸 수 있기 때문이다. 1번과 2번을 주소창에 치고 들어가면 같은 결과인 것을 확인할 수 있다.

3번은 path가 추가되어있지만, protocol, host, port(생략된 상태이기 때문에 같음)가 같기 때문에 같은 origin이라고 할 수 있다.

 

 

🤔 SOP (Same-origin policy) 를 왜 사용할까?

요즘 세상에는 스미싱 문자가 참 많다. 청첩장인 줄 알고 모르고 클릭했다고 해보자. 클릭했더니 hacker.com으로 들어가지고, 나도 모르게  내가 사용하는 SNS에 이상한 글이 써졌다. 하지만, SOP를 사용하면 이런 상황을 막을 수 있다. 만약 내가 사용하는 SNS가 https://www.instagram.com/이라면, https://www.hacker.com과 orgin이 다르다. 따라서 SOP 보안 정책에 어긋나기 때문에 글이 써지지 않을 것이다.

 

SOP 보안 정책에 따르면 다른 origin에는 접근이 불가능하다. 하지만, frontend와 backend의 상호작용을 위해서는 다른 orgin에 접근해야할 필요가 있다. 이를 해결하는 답이 바로 CORS(Cross-Origin Resource Sharing)이다.

 

🤔 CORS(Cross-Origin Resource Sharing)란?

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a "preflight" request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

 

MDN에 따르면 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다.

 

간단히 말하면, 다른 origin에 접근할 수 있도록 해주는 것이다. "브라우저야 나 다른 origin인데 접근 권한 좀 부여해주라!"

 

🤓 CORS 접근제어 시나리오 ( Examples of access control scenarios)

- 프리플라이트 요청(Preflighted requests)

Unlike simple requests, for "preflighted" requests the browser first sends an HTTP request using the 
OPTIONS method to the resource on the other origin, in order to determine if the actual request is safe to send. Such cross-origin requests are preflighted since they may have implications for user data.

 

MDN에 따르면 "preflighted" request는 “simple requests” 와는 달리, 먼저 OPTIONS 메서드를 통해 다른 도메인의 리소스로 HTTP 요청을 보내 실제 요청이 전송하기에 안전한지 확인합니다. cross-origin 요청은 유저 데이터에 영향을 줄 수 있기 때문에 이와같이 미리 전송(preflighted)합니다.

 

간단히 말하면, 진짜 요청을 하기 전에 "나 요청 보낼건데 보내도 돼?"라고 사전에 물어보는 것이다. 이때 OPTIONS 메소드를 보내 물어본다. 그리고 Preflight 사전 요청이 성공하면 진짜 요청을 보낸다. (당연히 반대로 Preflight 사전 요청이 실패하면 진짜 요청은 보내지 않는다.)

 

클라이언트가 preflighted 요청을 보낼 때는 다음과 같은 양식으로 보낸다. "나 진짜 요청 이렇게 보낼건데 진짜 요청 보낼건데 괜찮니?"

PREFLIGHT REQUEST
- Origin
- Access-Control-Request-Method : 진짜 요청할 method
- Access-Control-Request-Headers : 진짜 요청할 Headers에 추가할 것들

 

밑의 그림의 왼쪽 최상단의 내용을 참고하면 이 양식으로 보내고 있다.

 

그럼 서버는 이러한 양식으로 답장을 해준다. "네가 보낸 preflighted 요청에 대한 답장 보낼게. 허가 됐는지 살펴봐."

PREFLIGHT RESPONSE
- Access-Control-Allow-Orgin : 허가한 Origin
- Access-Control-Allow-Method : 허가한 Method
- Access-Control-Allow-Headers : 허가한 Headers
- Access-Control-Max-Age : Prelight 응답한 것이 캐시에 저장되는 데에 얼마나 걸리는지 시간
* Preflight 요청은 요청을 하고 성공을 해야만 진짜 요청을 보내게 된다. 그래서 Preflight 요청은 진짜 요청까지 두 번 한다고 볼 수 있다. 그렇기 때문에 처음 Preflight 요청을 할 때 캐시에 저장해놓고 진짜 요청을 하게 될 경우 캐시에 저장해놓은 것을 가져다 쓰면 된다. 

+ Access-Control-Max-Age에 대한 MDN 내용 : 다른 preflight request를 보내지 않고, preflight request에 대한 응답을 캐시할 수 있는 시간(초)을 제공합니다. 이미지의 코드는 86400 초(24시간) 입니다. 각 브라우저의 최대 캐싱 시간 은 Access-Control-Max-Age 가 클수록 우선순위가 높습니다.

 

PREFLIGHT RESPONSE의 특징
- Status code는 200대여야 한다.
- Response body(res.body)는 비어있는 것이 좋다.

 

 

 

- 단순 요청(Simple requests)

Preflight 요청없이 바로 진짜 요청을 보내는 것이다. Preflight 에서는 진짜 요청을 하기 전에 "나 요청 보낼건데 보내도 돼?"라고 사전에 물어봤다면, Simple request는 바로 "나 요청 보낸다"하고 요청을 보내도 되는 지 안 되는지 묻지 않고 보내버린다.

 

Simple request를 보낼 때는 다음과 같은 양식을 포함하여 보내야한다. 이 양식의 조건대로 보내야만 Preflight 요청 없이 Simple request로 보내진다.

 

- Method : GET, HEAD, POST 중 하나
- Heather : Accept, Accept-Language, Content-Language, *Content-type

* Content-Type 는 다음의 값만 허용됨
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

 

밑의 그림에서 *는 모든 origin을 허가해주겠다는 말이다. 즉, client에서 요청하는 origin인 foo.example도 당연히 허가되는 것이다.

 

 

 

🤔 Simple request로 한 번에 보낼 수 있는데 왜 Preflight가 필요할까?

 

다시 한 번 Simple request를 정리해보자. Preflight 에서는 진짜 요청을 하기 전에 "나 요청 보낼건데 보내도 돼?"라고 사전에 물어봤다면, Simple request는 바로 "나 요청 보낸다"하고 요청을 보내도 되는 지 안 되는지 묻지 않고 보내버린다.

 

만약 CORS에 대한 개념이 없는 서버에 진짜 요청을 바로 보내버린다고 해보자.

 

- 요청 : delete 진짜요청

- 서버 : CORS에 대한 개념이 없는 서버

 

일단 서버에서는 delete 진짜 요청이 들어왔으니 삭제를 해서 디비에서 삭제해버린다. 하지만 그 응답을 브라우저에 전달할 때가 문제이다. 서버는 일단 요청이 들어왔으니 처리하긴 했는데 이 서버는 클라이언트와는 다른 origin을 갖고 있는 서버이다. 여기서 allow-origin을 해주면 다른 origin이어도 괜찮겠지만, CORS를 모르기 때문에 allow-origin 설정을 해줄 수가 없다. 그래서 브라우저는 서버의 응답을 받으면 서버가 다른 origin이니까 CORS 에러라고 해준다. 이미 디비에서는 삭제해버렸는데 큰일이 나버린 것이다.

 

그래서 이렇게 CORS에 대한 개념이 없는 서버가 있기 때문에 Preflight는 꼭 필요한 요청이라고 할 수 있다.

 

+ 나봄님의 '나봄의 CORS' 유튜브 영상, 그리고 해당영상 'Justin Kim'님의 댓글 참고

 

- 인증정보를 포함한 요청(Requests with credentials)

인증관련 header를 포함할 때 사용하는 요청이다.

 

클라이언트 측
credenttials : include

서버측
Access-Control-Allow-Credentials : true
(Access-Control-Allow-Origin : *는 안 된다.)

 

쿠키, jwt 토큰을 클라이언트에서 자동으로 담아서 보내고 싶을 때 credentials(인증서)를 include하면 서버까지 전달해준다.

 

서버에서는 Access-Control-Allow-Credentials : true로 넣어줘야 클라이언트 측에서 보내는 것을 받을 수 있다. 그리고 당연히 credential이 있는 것만 허용해야하기 때문에 origin을 *로 모든 것을 허용해주면 error가 발생한다. 따라서 Access-Control-Allow-Origin : *는 안 된다. 허용하려고 하는 정확한 origin (예를 들어 https://kworld.tistory.com)을 명시해줘야한다.

 

 

👍CORS 코드 예시

// npm i cors 설치
// app.js에 require하기

const cors = require("cors");

 

경우에 따라 둘 중 하나를 사용

//app.js
// 모든 경우 다 허용
app.use(cors());

//app.js
// 인증이 필요한 경우 

const corsOption = {
  origin: "연결하고 싶은 주소",
  credentials: true,
};

app.use(cors(corsOption));

 

 

 

 

 

 

 

참고자료:

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

CORS https://ppojjakcoding.tistory.com/161

CORS https://firework-ham.tistory.com/70

CORS https://da-nyee.github.io/posts/web-cors/

MDN SOP https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

나봄의 CORS https://youtu.be/-2TgkKYmJt4