CORS (Cross-Origin Resource Sharing)와 JSONP (JSON With Padding)

CORS (Cross-Origin Resource Sharing)와 JSONP (JSON With Padding)는 웹 브라우저에서 적용되는 Same Origin Policy를 우회하는 데 사용되는 기술들입니다. 처음 개발을 하다 보면 Same Origin Policy에 의한 에러를 종종 경험하곤 합니다.

 

그런 의미에서 이번 포스팅에서는 Same Origin Policy 및 CORS와 JSONP의 개념, 둘의 차이점, 그리고 각각의 기술이 언제 사용될 수 있는지에 대해서 한 번 소개해보려고 합니다.

Same Origin Policy란?

개발자라면 한 번쯤은 위와 같은 에러를 경험해 봤을 것입니다. 위의 에러는 Same Origin Policy에 의해 발생하는 에러입니다. Same Origin Policy는 한 도메인에서 다른 도메인으로 리소스에 대한 접근을 제한하는 웹 브라우저의 기본적인 보안 정책입니다.

 

이를 통해 한 도메인의 웹 페이지가 다른 도메인의 데이터에 액세스 하거나 수정할 수 없도록 하여 중요한 정보를 안전하게 보호할 수 있습니다. 다만, 현대의 웹 개발 방식, 예를 들자면 SPA 방식의 개발에서는 Ajax나 XHR을 사용하여 개발을 주로 하게 되는데 이때 이 정책을 깨고 리소스를 사용해야만 하는 경우가 많이 생기게 됩니다.

 

이를 위해 사용되는 기술이 CORS와 JSONP입니다.

CORS (Cross-Origin Resource Sharing)

CORS는 사실상 위에서 소개한 Same Origin Policy를 우회하여 크로스 도메인 이슈를 해결하기 위해 가장 많이 사용되는 방법입니다. 클라이언트 측에서 특별히 뭔가 설정할 필요는 없고 서버 측에서 HTTP 응답 헤더를 추가함으로써 구현할 수 있습니다.

 

서버에서 HTTP 응답 헤더에 리소스에 접근 가능한 도메인을 설정해 주면 해당 도메인에 대해서는 Same Origin Policy를 적용하지 않고 우회할 수 있습니다. 이는 Preflight Request라는 기술을 통해 가능합니다.

Preflight Request

CORS를 적용하면 Preflight 요청과 실제 리소스에 접근하기 위한 요청으로 나뉘어 HTTP 요청이 발생하게 됩니다.

1. 클라이언트 측에서 서버로 본인의 도메인이 접근 가능한 도메인인지, 가능하다면 어떤 리소스에 접근 가능한지 물어보는 Preflight 요청을 보내게 됩니다. (이때 HTTP 메서드는 OPTIONS 메서드를 사용하게 됩니다.)
2. 서버는 클라이언트 측에서 물어본 것들과 관련된 정보를 HTTP 응답 헤더에 담아 응답하게 됩니다.
3. 그 이후, 클라이언트 측은 이 정보들에 맞춰 실제 요청을 보냄으로써 서버의 리소스에 접근할 수 있습니다.

JSONP (JSON With Padding)

JSONP의 경우, html의 script 태그에서 다른 도메인에 접근하는 것이 가능한 점을 이용해 Same Origin Policy를 우회하는 기술입니다. 스크립트 태그의 접근할 도메인의 url에 클라이언트 측에서 실행할 콜백 함수명을 같이 보냄으로써 이 콜백함수를 통해 리소스에 접근하는 방식입니다.

 

말로 설명하기보단 코드로 보여주는 것이 이해가 쉬울 것 같아 코드를 통해 설명하도록 하겠습니다.

// Client
function callback(resData) {
  console.log(resData);
  //...
}

const script = document.createElement('script');
script.src = 'http://test-server.com/jsonp?callbackFunc=callback&data=hello';
document.getElementsByTagName('head')[0].appendChild(script);

 

// Server
const {callbackFunc, data} = request.params;
const resData = model.find(data);
res.send(`${callbackFunc}(${resData})`);

1. 클라이언트 측에서 정의한 콜백 함수명을 script의 url에 담아서 같이 보냅니다.
2. 서버 측에서는 콜백 함수와 클라이언트로부터 받은 데이터를 이용해 서버에서 필요한 리소스를 찾습니다.
3. 찾은 리소스(resData)를 "콜백 함수 명(resData)"와 같이 함수를 실행하는 형태로 string 값을 클라이언트 측으로 보내면 클라이언트 측에서는 이를 받는 순간 실행하게 됩니다.

사실 JSONP의 경우, CORS 등장 이전에 사용되던 방식이다 보니 현대에는 많이 사용하진 않습니다만 알아둘 필요가 있다고 생각합니다. 왜냐하면 가끔씩 사용되는 서비스가 있고 이를 알고 쓰는 것이 맞다고 생각하기 때문입니다.

 

예를 들어, 최근에는 사용해 본 적이 없어서 잘 모르겠지만 이전 프로젝트에서 Google Map을 사용할 때 Google Map에서 API를 제공하는 방식이 JSONP 방식이었던 것으로 기억합니다.

JSONP의 장점과 단점

JSONP의 경우, 서버가 CORS를 지원하지 않을 때 혹은 지원하기 힘들 때 유용하게 사용될 수 있습니다.

 

예를 들어, 불특정 다수의 클라이언트를 서버에서 대응해야 할 때(도메인을 특정 지을 수 없을 때) 라이선스 키를 활용하여 이를 JSONP의 형태로 전달하는 등의 방식으로 활용할 수 있습니다.

 

다만, 제가 생각했을 때 단점은 JSONP를 데이터가 함수 호출의 형태로 반환되기 때문에 클라이언트 측에서 코드를 디버깅하는 것이 좀 더 힘들어질 수 있을 것 같습니다.

결론

정리하자면 CORS와 JSONP는 모두 Same Origin Policy로 발생하는 문제를 해결하기 위해 모색된 기술들입니다. JSONP는 script 태그를 사용하는 반면, CORS는 크로스 오리진 요청을 허용하는 도메인을 HTTP 헤더에 지정하는 방식입니다.

 

두 기술 모두 장점과 단점이 있는 만큼 무조건 CORS가 최근 기술이기 때문에 CORS를 사용하기보단 JSONP 방식도 상황에 맞게 잘 선택할 수 있으면 이 또한 좋은 기술이 될 수 있을 거라 생각합니다.