SOP(동일 출처 정책)과 CORS(교차 출처 리소스 공유)란 무엇일까?

SOP (Same Origin Policy) - 동일 출처 정책

🐳 Origin이 다르다면 리소스 요청이랑 응답 안보내줄거야!

 

웹 페이지가 자신이 로드된 출처와 다른 출처의 리소스를 임의로 요청하는 것을 엄격하게 제한하여 보안을 지키는 정책이다.

출처가 동일하기 위해서는 Origin(프로토콜, 도메인, 포트)이 모두 같아야 한다. SOP가 없다면, CSRF 문제가 발생할 수 있다.

출처 : TOSS Payments 개발자센터 - CORS

 

 

CORS (Cross Origin Resource Sharing) - 교차 출처 리소스 공유 

🐳 SOP를 위반하더라도, CORS 정책에 맞다면 허용해줄게~

 

브라우저가 자신의 출처가 아닌 다른 출처(도메인, 스킴 혹은 포트)로부터

자원을 로딩하는 것을 허용하도록 서버가 허가 해주는 HTTP 헤더 기반 메커니즘이다.

다시 말해, 출처가 다른 서버 간의 리소스 공유를 허용해준다는 것이다.

 

CORS의 등장 이유는?

웹이 발달했기 때문이다.

이전에는 프론트와 백엔드를 따로 구성하지 않았다.

그렇기에 한 번에 구성해서 모든 처리가 같은 도메인 안에서 가능했다.

(-> Python의 Django 웹 프레임워크의 MVT 패턴을 생각해도 좋을 것 같다.)

 

하지만 웹이 발전하면서 클라이언트에서 직접 API를 호출하는 방식이 당연해지게 된 것이고,

클라이언트와 API가 다른 도메인에 있는 경우가 많아서 CORS 정책이 생기게 된 것이다.

 

그러면 CORS 정책은 어떻게 SOP를 지키지 않는 다른 출처가 리소스 호출을 할 수 있게 했을까?

>> 출처가 다르더라도, 요청과 응답을 주고받을 수 있도록 서버에 리소스 호출이 허용된 출처를 명시하는 방식을 이용한다.

 

CORS 에러 대응하는 방법

🐳 CORS 에러는 클라이언트가 아니라 서버에서 해결하는 것이다!!
      CORS 에러를 일으키는 곳은 브라우저이다!!

Access-Control-Allow-Origin 응답 헤더 세팅하기

서버에서 Access-Control-Allow-Origin 헤더 설정을 통해서, 내가 수락할 요청의 출처를 지정할 수 있다.

예를 들어 :

Access-Control-Allow-Origin: http://example:1109

 

위와 같이 서버에서 Access-Control-Allow-Origin 헤더 세팅을 해놓는다면,

 http://example:1109  로부터 오는 요청을 브라우저가 승인하고, 응답할 수 있게 해준다.

다른 출처에서 온 요청은 응답을 받더라도 브라우저에서 차단된다.

 

와일드카드 사용 하는 경우 :

Access-Control-Allow-Origin: *

 

위와 같이 * (와일드카드)를 이용하면, 모든 도메인의 접근을 허용하게 되므로 보안은 취약해진다.

 

 

CORS 에러의 동작 방식

🐳 요청에 따라 요청이 전달되고 응답도 잘 됐으나, 응답이 전달되지 않는 경우도 있고,
      요청 자체가 전달이 되지 않는 경우도 있다~!

(1) 단순 요청 (Simple Request)

메서드: GET, POST, HEAD
Content-Type: application/x-www-form-urlencoded, multipart/form-data, text/plain
커스텀 헤더 없음

 

동작방식

1. 브라우저가 서버에 바로 요청을 전송한다.
2. 서버가 응답을 돌려준다.
3. 브라우저가 응답의 Access-Control-Allow-Origin 헤더를 확인한다.
4. 헤더 값이 현재 페이지의 origin과 다르면 응답을 스크립트에 전달하지 않고 차단한다.

 

이와 같은 단순 요청은 서버까지 도착하고 처리되지만,

브라우저가 결과를 숨기기 때문에 개발자 콘솔에 “CORS error”가 뜬다.

 

서버는 정상적으로 응답할 수 있지만, 브라우저가 보안을 위해 응답을 프론트로 전달하지 않는 것이다.

(이래서 CSRF문제가 발생할 수 있다)

 

(2) 사전 요청(Preflight Request)

메서드: PUT, DELETE, PATCH 등 단순 요청이 아닌 경우
Content-Type이 application/json 등 복잡한 타입인 경우
커스텀 헤더가 포함된 경우

 

동작방식

1. 브라우저가 먼저 OPTIONS 메서드로 사전 요청을 보낸다.
   → 이 origin에서 이 메서드로 요청 보내도 되는지 확인하는 것이다. 
2. 서버는 Access-Control-Allow-Origin, Access-Control-Allow-Methods 등으로
   허용 여부를 설정 해서 브라우저로 전달한다.
3. 브라우저가 검사한다.
4. 만약 서버 응답에 허용 헤더가 없거나 불일치하면,
   요청 자체를 차단한다. (데이터 전송이 아예 일어나지 않게 된다.)

이와 같은 경우에는 서버가 아예 클라이언트로부터 요청을 받지 못하며, 브라우저 콘솔에는 CORS 에러가 출력되게 된다.