공부한 내용
SOP
Same Origin Policy의 약자로, '같은 출처의 리소스만 공유 가능하다' 는 것인데
출처란 다음과 같다.
https://www.codestates.com:443/course 👉 출처
출처는 프로토콜,호스트,포트의 조합으로 이루어져 있으며, 이 중 하나라도 다르면 동일한 출처로 보지 않는다.
CORS
CORS의 동작 방식
1. Preflight Request
이 상황일 때에 브라우저는 요청을 한 번에 보내지 않고 예비 요청과 본 요청을 나누어서 서버로 전송한다.
왜 필요한가?
- 본 요청을 보내기 전에 미리 권한 확인을 할 수 있기 때문에, 실제 요청을 처음부터 다 보내는 것보다 리소스 관점에서 효율적이다.
- CORS에 대비되어있지 않은 서버를 보호할 수 있는데, CORS 이전에 만들어진 서버들은 SOP 요청만 들어오는 상황을 고려하고 만들어졌기 때문에, 다른 출처에 대해 대비가 안되어있다.
2. Simple Request
단순 요청은 예비 요청을 보내지 않고 바로 서버에게 본 요청부터 때려박은 후, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식이다. 즉, 프리플라이트와 단순 요청 시나리오는 전반적인 로직 자체는 같되, 예비 요청의 존재 유무만 다르다.
하지만 아무 때나 단순 요청을 사용할 수 있는 건 아니고 다음과 같은 조건을 만족해야 한다.
-
요청의 메소드는
GET,HEAD,POST중 하나여야 한다. -
Accept,Accept-Language,Content-Language,Content-Type,DPR,Downlink,Save-Data,Viewport-Width,Width를 제외한 헤더를 사용하면 안된다. -
만약
Content-Type를 사용하는 경우에는application/x-www-form-urlencoded,multipart/form-data,text/plain만 허용된다.
3. Credentialed Request
이 방법은 CORS의 기본적인 방식이라기보다는 다른 출처 간 통신에서 보안을 강화하고 싶을 때 사용한다.
기본적으로 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는다. 이때 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션이다.
이 경우에는 프론트,서버 모두 CORS 설정이 필요하다.
프론트 측 - withCredentials:true
서버 측 - Access-Control-Allow-Credentials:true
(단 서버 측에서 설정 시 와일드카드(*)로 설정하면 에러가 나므로 출처를 정확하게 명시해줘야 한다.)
