CORS - 다른 출처에서 요청이 왔을 때

∎  개요

프로젝트를 하던 중, 프론트와 백엔드를 서로 다른 프레임워크로 구현하였다.

이 두 프레임워크 간의 데이터 통신을 해야하는데 CORS 정책을 지켜줘야 한다고 한다.

이 CORS 정책이 뭔지 알아보자~!

 

∎  CORS (Cross Origin Resource Sharing)

• 브라우저(클라이언트)에서 설정한다.
• 자신과 origin이 다른 곳으로 요청을 못하게 막는다.
• origin이란, "프로토콜+도메인+포트번호"의 조합으로 각자의 '출처'를 의미한다.

 

∎  CORS를 하는 이유, 브라우저에서 해야하는 이유

CSRF 같은 해킹을 막을 수 있게 도와주는데, 예를 들어 내 이메일로 온 하나의 url을 나도 모르게 클릭했을 때, 나와 출처가 다른 url로 아무 제지 없이 접속이 된다면 내 정보가 바로 흘러들어갈 수 있다.

1. 단순 요청

1. 브라우저가 요청을 보낼 때, 헤더의 Origin에 자신의 출처를 적어 보낸다.
2. 서버는 응답 헤더의 Access-Control-Allow-Origin에 자신이 허용할 url들을 담아 보낸다.
3. 브라우저 측에서 자신의 origin과 Access-Control-Allow-Origin이 같다면 접속을 허용한다.

• 단순 요청은 프로세스는 단순하지만, 요청의 메소드, 헤더, Content-Type 헤더에 넣을 수 있는 항목들이 까다롭다.
• 이 중 Content-Type 헤더는 text/xml, application/json을 허용하지 않는다. 하지만 대부분의 HTTP API 요청의 content-type은 위와 같으므로 우리는 단순 요청보다 아래에 있는 Preflight 요청을 주로 사용한다.

2. 프리플라이트(preflight) 요청

• 본격적인 요청을 보내기 전에 안전한 요청인지 한번 더 확인하는 절차가 있다.
• 이 요청은 HTTP OPTIONS 메소드로 요청한다.
• 하지만 이 방법은 한번의 요청을 더 하는 것이기 때문에 자원을 더 사용하게 되고, 속도도 느려지는 단점이 있다.
• 이를 해결하기 위하여 한번의 통신이 있었으면 그 정보를 캐시에 저장해두고 유효한 기간 동안에는 다시 예비 요청을 하지 않게 만들 수 있다.

3. 인증정보를 보내는 요청

• '인증 정보'를 담고 요청을 보낼 때는 조금 다른 방법을 사용한다.
• 이 요청에는 'Credentials' 옵션이 추가된다.
• 그리고 응답 헤더는 Origin, Methods, Headers에 * 를 사용해 전체를 허용할 수 없다.
• 그리고 이것도 preflight로 예비 요청을 먼저 해야한다.