🤞 CORS란?

Cross-Origin Resource Sharing

추가 HTTP 헤더를 사용하여, 한 origin에서 실행 중인 웹 애플리케이션이 다른 origin의 리소스에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제

same origin 🆚 cross origin

✔ Origin을 구분하는 방법

1. Schema
2. Host
3. Port
   

• https://wonit.tistory:80/post
• https://wonit.tistory:80/post/id?page=10
• https://wonit.tistory:80/main/post/comment
  -> Origin이 동일한 상태

✨ SOP

Same Origin Policy

• 2011년 RFC 6454에서 등장한 보안 정책으로 동일한 출처의 Origin만 리소스를 공유할 수 있는 정책이다.
• 하지만, CORS 정책을 지킨 리소스 요청은 origin이 다르더라도 리소스 공유를 허용한다.

개발자 입장에서는 CORS와 SOP 정책 때문에 신경써야 하는 것들이 늘어나서 귀찮을 수 있다. 하지만, 이러한 정책이 존재하기 때문에 CSRF나 XSS와 같은 보안상의 issue를 막을 수 있다.

👀 CORS 동작 방법

Cross Origin에서 리소스를 요청하기 위해서 다음 과정을 거친다.

1. 클라이언트는 request header의 Origin 필드에 요청을 보내는 출처를 담아 서버로 요청을 보낸다.
2. 이후 서버는 Access-Control-Allow-Origin 헤더에 허용된 Origin이라는 정보를 담아 보낸다.
3. 응답을 받은 클라이언트는 자신이 보냈던 요청의 Origin과 서버가 보낸 응답의 Access-Control-Allow-Origin 값을 비교해 유효한 응답인지 아닌지를 결졍한다.

Access-Control-Allow-Origin

• 응답 헤더에 존재한다.
• 단일 출처를 지정하여, 해당 origin만 리소스에 접근하도록 허용할 수 있다.
• * 와일드 카드를 사용하여 브라우저의 origin에 상관없이 모든 리소스에 접근하도록 허용할 수 있다.

기본적인 흐름은 간단하지만, CORS가 동작하는 방법에는 여러가지 시나리오가 있다.

1. Preflight Request

요청을 한 번에 보내지 않고 예비 요청과 본 요청으로 나누는 방법이다.

1. 먼저, OPTIONS 메서드를 이용해 예비 요청을 보낸다. 이때 Origin에 대한 정보뿐만 아니라 본 요청에 대한 다른 정보들도 함께 담아 보낸다. (Http Method, Content-Type 등등)
2. 이후 서버는 Access-Control-Allow-Origin 헤더에 허용된 Origin에 대한 정보를 담아 응답을 보낸다.
3. 클라이언트 측은 자신이 보냈던 요청의 Origin과 서버가 보낸 응답의 Access-Control-Allow-Origin 값을 비교해 유효한 응답인지 아닌지를 결졍한다.
4. 만약 값이 같다면 본 요청을 보내고, 다르면 CORS 정책 위반이다. 🚨

2. Simple Request

Preflight Request에서는 본 요청을 보내기 전에 예비 요청을 보내고 그에 대한 응답을 통해 CORS 정책 위반 여부를 판단했다면, Simple Request는 예비 요청 없이 본 요청을 보내고 그에 대한 응답을 통해 CORS 정책 위반 여부를 검사한다.

전반적인 CORS 정책 위반 여부 판단 로직은 비슷하고, 예비 요청의 존재 유무만 다르다.

Simple Request가 이루어지기 위한 조건이 존재한다.

1. 요청 메서드는 GET, HEAD, POST 중 하나여야 한다.
2. Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
3. 만약 Content-Type를 사용하는 경우에 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용된다.

이러한 조건을 만족해야 Simple Request가 이루어지기 때문에 대부분의 경우 프리플라이트 방식을 이용하여 예비 요청을 보내 CORS 정책 위반 여부를 판단한다.

3. Credentialed Request

XMLHttpRequest, fetch API, axios를 사용할 때 별도의 옵션 없이 브라우저의 쿠키 정보나 인증 관련 헤더 (ex. Authorization 헤더) 를 함부로 요청에 담지 않는다.

이때 withCredentials 옵션을 true로 설정하면 cross origin으로 요청을 보낼 때 credential 정보를 담아서 보낸다. (fetch API에서는 credentials 옵션을 include로 설정)

응답 헤더에 Access-Control-Allow-Credentials : true가 존재해야 한다. 그렇지 않으면, 브라우저는 이 응답을 거부한다. 또한, Access-Control-Allow-Origin에 *를 사용할 수 없으며, 명시적인 URL이어야 한다.

🚨 CORS 정책 위반하지 않는 방법

서버에서 Access-Control-Allow-Origin 알맞게 설정하기

• *를 사용한다면 모든 출처에서 리소스에 접근하는 것을 허용하기 때문에 보안 측면에서 issue가 발생할 수 있다.
• 되도록 명시적인 URL로 설정해야 한다.

클라이언트 측에서 Proxy 서버 설정하기

• 프록시 서버를 설정하면 CORS 정책을 우회할 수 있다.
• 예를 들어, http://localhost:3000에서 http://localhost:8080로 요청을 보내고 싶다고 하자. (둘은 포트 번호가 다르므로 cross origin이다.)
• 이때 클라이언트 측에서 http://localhost:8080을 proxy 서버로 설정한다.
• 만약 클라이언트 측이 http://localhost:3000/api로 요청을 보내면 http://localhost:8080/api로 우회하여 요청을 보낸다.

마치며..
대부분의 개발 환경에서 백엔드와 프론트엔드의 origin은 다르기 때문에 개발자라면 CORS 정책이 무엇인지, 어떻게 동작하는지 잘 알아야 된다고 생각한다. 특히, CORS는 브라우저의 구현 스펙이기 때문에 CORS 정책 위반으로 문제를 많이 겪게 되는 것은 프론트엔드 개발자이다. 그래서 백엔드와 잘 의논하여 어떻게 CORS 정책을 위반하지 않고 통신할지 정해야 한다. 😁

참고

• 교차 출처 리소스 공유 (CORS)
• [HTTP] Cross Origin Resource Sharing, CORS란?