본문 바로가기

javascript ajax 크로스 도메인 요청 하기 (CORS)

web/javascript by 낼스 2015. 10. 8.
원본 : http://adrenal.tistory.com/16

javascript ajax 크로스 도메인 요청 하기 (CORS)

웹앱개발 2015/03/22 16:55
개요
웹 개발시 자바스크립트로 외부 서버의 경로로 ajax요청을 날리면 에러가 나면서 요청이 실패한다.

웹 브라우저의 콘솔창에 아래와 같은 메시지를 보게 된다.

크롬
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin ‘[요청한 도메인]' is therefore not allowed access.


파이어폭스
교차 원본 요청 차단: 동일 출처 정책으로 인해 [요청한 도메인]에 있는 원격 자원을 읽을 수 없습니다. 자원을 같은 도메인으로 이동시키거나 CORS를 활성화하여 해결할 수 있습니다.


외부로 요청이 안되는것은 자바스크립트 엔진 표준 스팩에 동일 출처 정책(same-origin policy)이라는 보안 규칙이 있기 때문이다. 



동일 출처 정책(Same-Origin Policy)
웹어플리케이션 보안 모델에서 중요한 개념중 하나가 동일 출처 정책(Same-Origin Policy)이다.


이 정책에 의해서 자바스크립트(XMLHttpRequest)로 다른 웹페이지에 접근할때는 같은 출처(same origin)의 페이지에만 접근이 가능하다. 같은 출처라는 것은 프로토콜, 호스트명, 포트가 같다는 것을 의미한다. 즉 쉽게 말하면 웹페이지의 스크립트는 그 페이지와 같은 서버에 있는 주소로만 ajax 요청을 할 수 있다는 것이다.


이정책이 초기에는 웹 사이트의 보안을 위한 좋은 방법으로 생각되었으나 요즘은 여러 도메인에 걸처서 구성되는 대규모 웹 프로젝트가 늘어나고, REST API 등을 이용한 외부 호출이 많아지는 상황에서는 거추장 스러운 기술이 되기도 하고 있다.

그래서 만들어진 추가 정책이 CORS(Cross-Origon Resource Sharing) 이다. 이 정책의 특징은 서버에서 외부 요청을 허용할 경우 ajax요청이 가능해지는 방식이다. CORS에 대해서 설명하기전에 서버의 도움없이 동일 출처 정책(same-origin policy)을 회피하여 외부 서버로 요청을 날릴 수 있는 방법을 몇가지 소개 한다.



1. 웹 브라우저 실행시 외부 요청을 허용하는 옵션을 사용
아래에서 자세하게 설명하겠지만 same origin policy는 결국 클라이언트인 웹 브라우저가 요청을 해도 되는지 판단해서 결정하는 것으로 이 과정만 무시한다면 어디든 요청을 못할 이유는 없다. 크롬같은 웹 브라우저들은 실행시 커맨드라인 옵셥을 통해서 외부 도메인 요청가능 여부를 확인하는 동작을 무시하게 할 수 있다.

크롬의 경우: --disable-web-security 옵션을 추가하여 크롬 실행




2. 외부 요청을 가능하게 해주는 플러그인 설치
이 부분도 아래에서 설명하겠지만 서버에서 받은 요청의 응답에 특정 header(Access-Control-Allow-Origin: *)만 추가하면 웹 브라우저가 요청이 가능한 사이트로 인식해서 요청이 가능하다. 크롬의 경우 웹스토어에 요청을 가로채서 응답에 위 header를 추가해주는 플러그인이 있다. 웹스토어에서 cors로 검색하면 확장 프로그램 검색결과에서 찾을 수 있다. 





1. 2. 번 방식은 웹 브라우저 사용자가 사용하는 브라우저를 직접 셋팅하는 방식으로 개발자라면 활용해 볼 수 있겠지만 일반 사용자가 사용해야 하는 웹페이지라면 적용이 불가능하다고 보면된다.


3. JSONP방식으로 요청
웹 브라우저에서 css나 js 같은 리소스 파일들은 동일출처 정책에 영향을 받지 않고 로딩이 가능하다. 이런점을 응용해서 외부 서버서버에서 읽어온 js 파일을 json으로 바꿔주는 일종의 편법적인 방법이다. 단점은 리소스파일을 GET 메서드로 읽어오기 때문에 GET 방식의 API만 요청이 가능하다. 자세한  사용법은 이 글의 범위를 벋어나므로 생략한다.




CORS (Cross-Origin Resource Sharing)
웹 브라우저에서 외부 도메인 서버와 통신하기 위한 방식을 표준화한 스팩이다. 서버와 클라이언트가 정해진 해더를 통해 서로 요청이나 응답에 반응할지 결정하는 방식으로 교차 출처 자원 공유(cross-origin resource sharing)라는 이름으로 표준화가 되었다. 


교차 출처 자원 공유(cross-origin resource sharing) 방식은 요청을 받은 웹서버가 허용 할 경우에는 다른 도메인의 웹 페이지 스크립트에서도 자원을 주고 받을 수 있게 해준다.


CORS 작동 방식




preflight request (사전요청)
요청하려는 URL이 외부 도메인일 경우 웹 브라우저는 preflight요청을 먼저 날리게 된다.
preflight 요청은 실제로 요청하려는 경로와 같은 URL에 대해 OPTIONS 메서드로 요청을 미리 날려보고 요청을 할 수 있는 권한이 있는지 확인한다.

위와 같이 CORS 요청을 편법없이 하기 위해서는 클라이언트의 처리만으로는 안되고 해당 서버측에서의 추가 처리 사항이 필요하다. 





서버에서 CORS (Cross-Origin Resource Sharing) 요청 핸들링하기
서버로 날라온 preflight 요청을 처리하여 웹 브라우저에서 실제 요청을 날릴 수 있도록 해준다.

모든 외부 도메인에서 모든 요청을 허용할 경우 처리
가장 쉬운 방법으로 모든 요청을 허용하는 방식이다.

1. preflight 요청을 받기 위해 OPTIONS 메서드의 요청을 받아서 컨트롤 해야 한다.
2. 모든 요청의 응답에 아래 header를 추가 한다.
  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
  • Access-Control-Max-Age: 3600
  • Access-Control-Allow-Headers: Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization

웹 브라우저의 스크립트 엔진에서 preflight 요청 응답으로 Access-Control-Allow-Origin header에 “*" 값이 있으면 모든 도메인에서의 요청을 허용하는 것으로 판단한다.  ajax 요청이 실패하면서 발생하는 메시지는 바로 preflight요청을  날린 응답 메시지에 Access-Control-Allow-Origin 해더가 없어서 요청이 허용되지 않는 다는 뜻이다.

spring-mvc 로 개발할시 처리법: https://spring.io/guides/gs/rest-service-cors/




외부 도메인 요청을 선별적으로 허용할 경우
먼저 cros 스팩과 관련된  header의 규격을 확인해보자.
  • Request headers (클라이언트의 요청 해더)
    • Origin: 요청을 보내는 페이지의 출처(도메인)
    • Access-Control-Request-Method: 실제 요청하려는 메서드
    • Access-Control-Request-Headers: 실제 요청에 포함되어 있는  해더 이름

  • Response headers (서버에서의 응답 해더)
    • Access-Control-Allow-Origin: 요청을 허용하는 출처. * 이면 모든곳에 공개되어 있음을 의미한다.
    • Access-Control-Allow-Credentials: 클라이언트 요청이 쿠키를 통해서 자격 증명을 해야 하는 경우에 true. true를 응답 받은 클라이언트는 실제요청시 서버에서 정의된 규격의 인증값이 담긴 쿠키를 같이 보내야 한다.
    • Access-Control-Expose-Headers: 클라이언트 요청에 포함되어도 되는 사용자 정의 해더.
    • Access-Control-Max-Age: 클라이언트에서 preflight 의 요청 결과를 저장할 기간을 지정. 클라이언트에서 preflight 요청의 결과를 저장하고 있을 시간이다. 해당 시간동안은 preflight요청을 다시 하지 않게 된다.
    • Access-Control-Allow-Methods: 요청을 허용하는 메서드. 기본값은 GET,POST 라고 보면된다. 이 해더가 없으면 GET과 POST요청만 가능하다. 만약 이해더가 지정이 되어 있으면, 클라이언트에서는 해더 값에 해당하는 메서드일 경우에만 실제 요청을 시도하게 된다.
    • Access-Control-Allow-Headers: 요청을 허용하는 해더. 

위의 request header 값을 보고 response header에 해당 출처(origin)에 허용하는 요청 스팩을 알려주는 구현을 하면 된다. 이런 처리를 미리 구현해놓은 라이브러리등은 찾아볼 수 없었다. Filter나 Interceptor등을 직접 구현해야 할것으로 보인다.



결론
server side
위에서 언급한것 처럼 이 정책을 회피하기 위한 다양한 방법이 있으므로 서버가 이 스팩을 지원한다고 해서 다른 보안정책을 마련하지 않으면 안된다. 일반적인 웹 브라우저에서 스크립트에 의한 Ajax 요청만 적용을 받을 수 있다고 생각해야 할 것이다. 그럼에도 불구하고 불특정 다수의 외부 클라이언트에서 요청을 받을 수 있는 open API 같은 것을 개발 중이라면 클라이어트가 각종 편법들을 동원해서 서버에 접근하지 않아도 되도록 cors요청을 핸들링해줄 필요가 있다.

client side
ajax요청시 에러가 날때 구글링을 통해서 단편적인 처방으로 문제를 해결하려고 하는 경우를 종종 봤는데 이번 기회에 javascript의 스팩을 이해하고 개발상황에 맞는 적절한 해결 방식을 선택할 수 있기를 바란다. 외부 서버로 ajax요청이 안될 경우 아래와 같은 단계로 처리를 생각해 볼 수 있다.

1. 개발자가 테스트 혹은 개발단계에서 쉽계 요청하기: 웹 브라우저 실행옵션이나 플러그인을 통한 동일출저 정책 회피
2. cors구현이 안되어 있는 서버로 ajax요청을 해야하지만 서버쪽 컨트롤이 불가능할 경우: jsonp방식으로 요청
3. ajax요청을 해야하는 다른 도메인의 서버를  클라이언트와 같이 개발하거나 서버개발쪽 수정요청이 가능한 경우: 서버에서 CORS 요청이 허용되도록 구현






참고할 페이지 링크



저작자표시 비영리

'web > javascript' 카테고리의 다른 글

Javascript Promise(프로미스)  (0) 2019.01.30
"use strict"  (0) 2015.10.12
press [key enter] to event trigger & work template  (0) 2015.08.21
reset form element for jquery  (0) 2015.08.18
월더하기  (0) 2015.08.18

관련글

댓글

티스토리툴바