CORS - 개념편

“blocked by CORS policy”는 요즘같이 MSA(Micro Service Architecture)를 지향하는 서버 구조를 바탕으로 구축하였을 때 브라우저에서 무조건 볼 수 있는 에러이다.

이는 CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유)를 지키지 않았기 때문에 해당 에러가 브라우저에서 발생을 하게 된다.

자. 그러면 이제부터 CORS가 무엇이고, 어떻게 해결 할 수 있는지 알아보자.

 

---

 

CORS 간략한 설명

CORS는 다른 Origin으로 Request를 보낼 때 preflight를 OPTIONS메서드를 이용해 먼저 request를 보내게 된다.

여기서 다른 Origin이 어떤것인지 이야기하자면 동일한 도메인, 동일한 포트가 아닐 경우 무조건적으로 발생한다.

즉 WAS서버 이면서 WEB서버인 서버를 동작하였을 때에는 CORS를 확인하지 않는다. 하지만, localhost:8080에서 WEB 서버를 실행하고, localhost:8081에서 WAS 서버를 실행하였을 때 CORS가 발생하게 된다.

요청 성공과 실패 예제

 

혹시나 아래의 링크에 있는 포트는 bad port라고 정의되며, 같은 도메인 및 포트라도 CORS를 검사하게 된다.

Fetch Standard

 

CORS는 모든 브라우저에서 동작하고 CORS를 위한 헤더는 아래의 세가지와 같다.

• Access-Control-Request-Method
  • 요청을 보낼 때 사용할 Method
  • ex) GET, POST, PUT, DELETE ...
• Access-Control-Request-Headers
  • 요청을 보낼 때 사용할 Header
  • ex) Content-Type, Authorization ...
• Access-Control-Allow-Origin
  • 요청을 보내는 도메인의 허용 정보
  • ex) *, a.com, a:8080.com, b.com ...

이외에 인증 같은 것을 보낼 때에는 Access-Control-Allow-Credentials를 사용하기도 한다.

 

---

Preflight부터 Main까지 흐름

Preflight request부터 Main Request까지의 Request, Repsonse흐름을 아래의 그림으로 표현할 수 있다.

Request의 흐름

여기서 Preflight Reqeust은 브라우저에서 Main Request의 정보를 바탕으로 알아서 보내어 확인한다.

 

---

 

CORS를 확인하는 방법

그렇다면 CORS가 허용이 되는지, 허용이 되지 않았는지에 대해서 확인은 OPTIONS메서드로 요청을 보내보는 것이다. 그렇다면 보편화된 아래의 두 가지를 이용하여 확인하는 방법에 대해서 설명하려고 한다.

• Curl을 이용한 방법
• Postman을 이용한 방법

 

Curl을 이용한 방법

curl -v -X OPTIONS 주소

정말 간단하게도 위에 주소를 입력하고 요청을 보내게 되면 CORS를 허용하는지 하지 않는지에 대한 정보를 확인할 수가 있다.

 

실패한 Curl 예시 1

Node서버에 CORS관련 설정이 없을 경우 OPTIONS로 요청을 보내었을 때 아래와 같이 응답이 온다. Response는 200 OK가 오지만, Access-Control-Allow-Origin와 같은 헤더가 포함되어 있지 않아 CORS정책에 위배된다.

 

 

실패한 Curl 예시 2

AWS의 API Gateway에서 CORS 관련된 설정은 기본적으로 응답으로 날아온다. 하지만 헤더가 포함되어있음에도 응답이 403으로 왔기 때문에 CORS정책에 위배된다.

 

 

성공한 Curl 예시

위의 이미지도 AWS에서 API Gateway에서 CORS를 정상적으로 설정하였을 때 받는 응답이다. 응답이 200을 받았으며, 필요한 헤더가 전부 충족이 된다면 요청은 성공적으로 응답 값을 처리한다.

 

---

 

Postman을 이용한 방법

요청을 보낼 때 OPTIONS로 Method를 설정 해 준 다음 요청을 보내면 된다. 그 뒤 Headers를 눌러 어떤 헤더 값이 오는지 확인할 수 있다.

 

실패한 Postman 예시 1

Curl의 첫 번째 이미지와 같은 주소로 요청을 보내었다. 역시나 CORS관련 헤더가 없기 때문에 CORS정책에 위배된다.

 

 

실패한 Postman 예시 2

Curl의 두 번째 이미지의 주소로 요청을 보내었다. 역시나 403으로 응답이 왔기 때문에 CORS를 허용하지 않는다.

 

 

성공한 Postman 예시 1

Curl의 세 번째 이미지의 주소로 요청을 보내었으며, 응답 값은 200과 Origin이 “*”이며 나머지 헤더와 메서드들도 허용하는 것을 알 수 있다.

 

---

 

다음 포스팅을 통해 AWS의 API Gateway와 Node, Spring boot에서 CORS와 관련한 허용을 어떻게 진행하는지 순차적으로 업로드할 예정입니다.

 

참고한 사이트

Fetch Standard

교차 출처 리소스 공유 (CORS) - HTTP | MDN