[스터디] CORS(Cross-Origin Resource Sharing)

hyojeong·2021년 9월 17일

데브코스 스터디

데브코스

목록 보기

36/50

CORS 에러는 왜 발생하는 것일까? 이 에러는 CORS 정책을 위반할 때 발생 하는 에러로 서버쪽에서 발생한 문제이다. CORS를 이해하기 위해 SOP를 먼저 살펴보자.

📍우선 URL 구조를 알아보자!

[이미지 출처]

url 구조에서 우리가 봐야할 부분은 protocol, host, port이다. 이 세가지의 부분을 합쳐서 출처(Origin)이라고 한다. 이 중 하나라도 다를 시에는 다른 출처로 판단되어지며 다른 출처로 판단된 리소스를 사용하는 것을 제안하는 방식을 SOP라고 한다.

🔎SOP(Same Origin Policy)

SOP는 다른 출처의 리소스를 사용하는 것을 제안하는 보안 방식이다. 하지만 웹을 사용할 때 다른 출처의 리소스를 비교적 자유롭게 사용할 수 있다. 다른 출처의 리소스를 자유롭게 사용할 수 있도록 하는것에 SOP의 예외조항인 CORS가 있다.

브라우저에서 다른 출처의 리소스를 공유하는 방법이다. CORS는 3가지의 동작 방식을 가진다.

Preflight Request

options 메서드를 통해 다른 도메인의 리소스에 요청이 가능한지 먼저 확인 후에 요청이 가능할 경우 실제 요청(Actual Request)을 보내는 방식
한번 요청을 보낼 경우 두번의 요청이 보내짐
Preflight Request
- origin :요청 출처
- Access-Control-Reqeust-Method : 실제 요청을 보낼 매서드
- Access-control-request-headers :실제 요청의 추가 헤더
Preflight Response :
- Access-Control-Allow-Origin : 서버측 허가 출처
- Access-Control-Allow-Methods : 서버측 허기 메서드
- Access-Control-Allow-Headers : 서버측 허가 헤더
- Access-Control-Max-Age : preflight 응답 캐시시간
Response Cache - preflight 응답을 브라우저에 캐싱해두고 요청을 보낼 때 캐싱된 내용을 먼저 확인한 후에 내용이 있다면 사전요청을 보내지 않고 실제 요청을 바로 보냄

[이미지 출처]

Simple Request

preflight 요청 없이 바로 실제 요청을 날림
Simple Request의 조건
- GET, POST, HEAD 메서드 중 한가지여야 함
- Content-Type :
  - Application/x-www-form-unlencoded
  - Multipart/form-data
  - Text/Plain
- 헤더는 Accept, Accept-Language, Content-Language, Content-Type만 허용

[이미지 출처]

Credentialed Request

HTTP Coockie나 HTTP Authentication 등을 Client에서 Request에 담아 서버로 보내고 싶을 때 사용하는 요청
기본적으로 브라우저는 Non credential로 설정되어 있기 때문에 재설정 필요
서버에서 Response Header에 Access-Control-Allow-Credentials :true를 포함해야 함
서버에서 응답 시에 Access-Control-Allow-Origin 헤더의 값으로 정확한 출처를 명시

🔑Preflight가 필요한 이유는 뭘까?

서버가 CORS를 모르고 있는 상태인 경우 발생할 에러를 방지하기 위해서이다. 서버가 CORS를 모르는 상태에서 실제 요청이 들어왔을 경우 에러가 발생하면 이미 서버에서 요청 처리를 해버렸기 때문에 큰 문제가 발생할 수 있다. 이를 방지하기 위해 미리 요청을 보내 CORS에러가 발생하는지를 확인하는 것이다.

[이미지 출처]
이를 통해 CORS 에러가 먼저 터진다면 서버에선 아무 문제를 일으키지 않고 이 에러를 해결할 수 있다.