CORS는 교차 출처 리소스 공유라고 해석합니다.
웹 애플리케이션이 리소스가 자신의 출처와 다를때,
추가 HTTP 헤더를 사용해, 다른 출처의 선택한 자원에 접근할수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다.
CORS의 기본 동작 과정은
1. 클라이언트에서 요청 HTTP 헤더속 Origin 필드의(localhost:3000) 값에 요청을 보내는 Origin을 담아보내면
응답헤더 Access-Control-allow-origin에 Origin에 오리진정보(localhost:3000) 등을담아 클라이언트로 전달합니다.
여기서 중요한 점은 서버는 CORS정책 위반 여부에 관여하지 않으며
출처를 비교하는 로직은 클라이언트에 구현되어있다는점 입니다.
오늘은 CORS에 대해 간략히 적어보자.
우선 CORS를 인터넷에 쳐보면 교차 출처 리소스 공유라고 한단다.
그렇다면 교차 출처
(나는 다른 출처라고 하겠다) 가 뭔지에 대해 설명을 해야한다.
동일 출처란 URL에서 스킴(프로토콜) , 호스트(도메인), 포트 가 동일함을 의미한다.
다시말해 위 3가지 중 적어도 하나가 다를때 교차 출처 HTTP 요청을 실행하게 된다.
자 그럼 CORS의 뜻 교차 출처에 대한 개념은 어느 정도 인지를 하시고…
CORS가 작동하는 시나리오는 크게 세가지로
1 . 안전한 요청
안전하지 않은 요청
인증된 요청으로 구분하게 된다.
안전한 요청
이 될 조건은 다음과 같다.
안전한 요청에 대해서는 다음 절차를 따른다.
Origin
헤더와 함께 브라우저가 요청을 보낸다.Origin
값과 동일하거나 *인 Access-Control-Allow-Origin
다음 안전하지 않은 요청
에 대한 절차이다.
OPTIONS
메서드를 사용한 preflight 요청을 보내게 되는데,Access-Control-Request-Method
– 본 요청의 메서드 정보가 담김Access-Control-Request-Headers
– 본 요청의 헤더 정보가 담김Access-Control-Allow-Methods
– 허용되는 메서드 목록이 담김Access-Control-Allow-Headers
– 허용되는 헤더 목록이 담김Access-Control-Max-Age
– 몇 초간 preflight 요청 없이 크로스 오리진 요청을 바로 보낼지에 대한 정보가 담김안전하지 않은 요청에 대해서는 Prefligth Request (예비 요청)
이라는 것을 먼저 브라우저측에서 서버에 보내게 된다.
그러면 서버에서는 예비요청에 대한 응답으로 어떤 메소드를 허용하고 금지하는 지
OPTIONS 메소드와 응답 헤더(Access-Control-Allow-~)를 통해 클라이언트에 알린다.
이를 받은 클라이언트는 응답 헤더의 정책을 보고 안전한지 확인 후 본 요청을 보내면 끝!
마지막 인증된 요청
… 2번 보다 한층 더 강화된 방식이다.
프로젝트를 만들다 CORS 설정을 다 해주었지만
클라이언트와 서버가 서로 쿠키를 주고 받지 못하는 상황이 온 적이 있는가? 나는 있다.
쿠키정보나 인증과 같은 헤더는 함부로 담을 수 없기 떄문이다.
서버에서 이를 허용하기 위해서는
응답헤더 Access-Control-Allow-Origin에 와일드카드가 아닌 정확한 오리진 정보를 명시해 두고
credential 옵션을 허용해 주어야 한다.
참조
면접시 대답 :
https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏#CORS(Cross_Origin_Resource_Sharing)
CORS에 대한 나의 이야기 :