Ajax에서 필요한 SOP(Same Origin Policy), CORS(Cross-Origin Resource Sharing) 정리

SOP, COP

1. Same Origin Policy

document 객체는 출신인 origin을 가지고 있고, 이는 js에서 `document.location.origin`으로 확인할 수 있다. document 내에서 리소스들과 상호작용할 때, origin이 다르다면 리소스를 사용하는 데에 있어서 제한을 두겠다는 것이 SOP(Same Origin Policy)이다.

 

1.1. Origin 판단

Origin이 같은 지는 Protocol, Host, Port로 판단하는데 url 구조를 보면 다음과 같다.

http://localhost:3000
Protocol://Host:Port

세 가지가 모두 같으면 같은 Origin이라고 판단되는 것이다.

IE는 양쪽 도메인 모두 높음 단계의 보안 수준일 경우 Same Origin Policy가 적용되지 않고, 포트가 다르더라도 Same Origin으로 간주된다.

IE...ㅂㄷㅂㄷ

 

1.2. SOP가 없다면?

SOP가 없다면 어떤 문제가 발생할 수 있을까?

예를 들어 Same origin이 아닐 때, 해커가 자신의 서버 url로 유저를 유도하면 해당 document가 유저의 브라우저에서 실행될 텐데, document에 해당 유저의 다른 페이지를 긁어올 수 있는 코드가 있으면 개인 정보를 가져올 수 있게 된다.

 

1.3. SOP 적용

하지만, 우리는 다른 사이트의 비디오를 삽입하기도 하고 다른 사이트로 link를 걸어 이동하기도 한다. 이러한 일들은 SOP에 영향을 안 미치는 것일까?

• Cross Origin Writes

  • 쓰기는 보통 허용된다. 위에서 설명한 링크나 redirect, form 제출 등에 있어서 자유롭지만 일부 사이드에서 preflight를 요청하기도 한다.

  • preflight란 실제 request를 보내도 괜찮은지 판단하기 위해, option method를 이용하여 테스트 request를 보내는 것이다.

• Cross Origin Inserts

  • 삽입은 보통 허용된다. iframe이나 video, img, embed 등의 태그로 외부 리소스를 삽입한다.

• Cross Origin Read

  • 읽기는 불허하지만 CORS(Cross Origin Resource Sharing)를 이용해 접근을 허용할 수 있다.

결국 SOP를 따르는 Web API들을 사용하면, api 호출 등 데이터를 요청할 때 같은 origin이거나 다른 origin일 경우 cors 옵션이 확인되어야한다. 이러한 API들에는 Fetch API, XMLHttpRequest, axios 등이 있다.

Ajax 보러가기

Ajax(Asynchronous Javascript And Xml)

CORS는 Cross-Origin Resource Sharing으로 origin이 다른 사이트의 리소스를 사용할 수 있도록 하는 정책이다. SOP에서는 원래 다른 origin의 사이트에 데이터를 요청할 수 없는데, CORS를 설정하면 가능하다.

 

1.4. Preflight

다른 origin에 데이터를 요청할 때는 서버 입장에서도 브라우저가 데이터를 변경할 수 있고, 브라우저 입장에서도 서버가 요청을 제대로 받을 수 없을 수 있으니 제대로 된 동작을 보장하기 위해서는 테스트를 먼저해야한다. 그리고 이러한 테스팅 과정이 바로 Preflight이다.

가끔 api 요청 시 get method만 제대로 동작하고 다른 메소드는 404 에러가 뜰 때가 있다. 그리고 Network를 살펴보면 내가 지정한 method가 아닌 OPTION method로 요청을 보낸 것이 보인다.

이는 Preflight를 이용하기 때문인데, 쉽게 예를 들어 클라이언트가 다음 요청에서 사용할 method를 서버에게 보내면 서버는 허용하는 method를 response로 보내서 클라이언트가 할 다음 요청이 유효한 지에 대한 응답을 해주는 식이다.

 

1.5. CORS 동작

CORS(Cross-Origin Resource Sharing)는 HTTP header를 추가함으로써 동작한다. 그렇다면 어떤 header를 추가해야할까?

서버에서 사용하는 HTTP response header의 옵션은 다음과 같다.

• Access-Control-Allow-Origin : 어떤 origin의 data 요청을 허용할지

• Access-Control-Expose-Headers : 브라우저가 허용하는 header 지정 가능

• Access-Control-Max-Age : preflight의 요청이 얼마나 오래 캐시되는지

• Access-Control-Allow-Credentials : 인증 정보 세팅 가능

  쿠키 세팅 포스팅

• Access-Control-Allow-Methods : 가능한 요청 method

• Access-Control-Allow-Headers : 허용하는 header 지정 가능

 

브라우저에서 사용하는 HTTP request header의 옵션은 다음과 같다.

• origin

• Access-Control-Request-Method : preflight에서 실제 요청에 어떤 method가 쓰일 것인지 예고

  • 서버에서는 Access-Control-Allow-Methods로 답변함

• Access-Control-Request-Headers : preflight에서 실제 요청에 어떤 header가 쓰일 것인지 예고

  • 서버에서는 Access-Control-Allow-Headers로 답변함

 

결론적으로 same origin이 아닌 cross origin에 데이터를 요청할 때, preflight로 먼저 테스팅을 하며 서버와 브라우저에서는 위와 같은 header를 통해 해당 origin의 요청이 올바르고 이행될 수 있는지 소통한다.