SOP와 CORS

📌 SOP와 CORS에 대해서 설명해주세요

웹페이지를 만들다보면 다른 페이지의 리소스를 가져올 때 CORS 에러라는 것을 볼 수 있다.
이는 브라우저의 SOP에 의해서 발생하는 현상이다.

SOP

동일 출처 정책(SOP: Same-origin policy) 때문에 브라우저들은 스크립트 내에서 초기화되는 cross-origin HTTP 요청을 제한한다.

다른 출처에서 가져온 리소스(문서, 스크립트 등)와 상호작용하는 것을 제한하여 잠재적 악성 문서를 격리한다.

⚠️ SOP를 위반했는지는 서버가 아닌 브라우저에서 확인한다.

동일 출처

동일 출처란 두 URL의 프로토콜, 포트(명시한 경우), 호스트가 모두 같은 출처이다.

예를 들어 http://store.company.com/dir/page.html와 동일 출저인 것은 아래와 같다.

URL	동일 출처	이유
http://store.company.com/dir2/other.html	✅
http://store.company.com/dir/inner/another.html	✅
https://store.company.com/secure.html	❌	프로토콜(https)이 다름
http://store.company.com:81/dir/etc.html	❌	포트(:81)가 다름
http://news.company.com/dir/other.html	❌	호스트(news)가 다름

교차 삽입의 경우 SOP 영향 ❌

아래와 같은 교차 삽입의 경우 SOP에 상관없이 허용된다.

• <link> 태그로 다른 도메인의 CSS를 가져오기
• <script> 태그로 다른 도메인의 JavaScript 가져오기
  • 단, 특정 API에는 차단될 수 있음
• <img>, <video>, <audio>, <embed>, <object>
• <iframe>으로 삽입되는 모든 것
  • <iframe> 은 Clickjacking 공격을 당할 수 있다.
  • Clickjacking 공격(UI 교정 공격) : 페이지 클릭시 다른 페이지의 버튼이나 링크를 클릭하도록 속이는 공격
• CSS, @font-face (일부 브러우저마다 다를 수 있음)
  • @font-face: 웹 브라우저에게 해당 서체를 다운로드함

⚠️ 교차 읽기(JS로 접근한 경우)는 허용되지 않는다.

⚠️ IE 의 경우 SOP에 두가지 중요 예외사항이 있다.

• 신뢰가능한 사이트: 양쪽 도메인 모두가 높음 단계의 보안 수준을 가지고 있는 경우 동일 출처 제약을 적용하지 않는다.
• 포트 무시 : 포트가 다르더라도 동일 출처로 여김

CORS

SOP(Same Origin Policy) 때문에 다른 출처의 자원을 쓸 수 없다.
그러나 CORS를 사용하여 해결할 수 있다.

CORS(Cross-Origin Resource Sharing)는 도메인 또는 포트가 다른 서버의 자원을 요청하는 매커니즘을 말한다.
즉, 다른 출저의 서택한 자원에 접근할 수 있는 권한을 부여한다.
이때 요청은 cross-origin HTTP 에 의해 요청된다.

💡 출처를 비교하는 로직은 서버가 아닌 브라우저에 구현되어 있다.
따라서, SOP를 위반하는 리소스 요청을 해도 서버에서는 정상 응답을 한 로그로 남을 수 있다.

💡 SOP 를 위반하는 경우 브라우저는 요청의 헤더에 Origin, referer 를 추가한다.

• Origin: 요청이 시작된 서버를 나타내는 url
• referer: 현재 요청된 페이지의 링크 이전의 웹 페이지 주소

CORS 사용 예시

다음과 같은 요청에 CORS가 사용된다.

• XMLHttpRequest, Fetch 호출
• CSS, @font-face (일부 브러우저마다 다를 수 있음)
• WebGL 텍스쳐
• drawImage()를 사용해 캔버스에 그린 이미지/비디오 프레임
• 이미지로부터 추출하는 CSS Shapes

  img {
  float: left;
  		/* 여백을 해당 모양으로 둘러싸게 함 */
  shape-outside: url(../images/star-shape1.png);
  }

JavaScript, CSS 같은 리소스들은 Cross-Origin 정책을 따르기 때문에 외부 요청이 가능하다.(위의 동일 출처 허용 참조)

COR 동작

1. 클라이언트에서 HTTP 프로토콜을 사용하여 요청을 보내게 되는데 이때 Origin 필드에 요청을 보내는 출처 를 함께 담아서 보냄
2. 서버에서 Accewss-Control-Allow-Origin에 리소스 출처를 주고 클라이언트에 응답한다.
3. 클라이언트에서 응답을 받으면, 브라우저가 Origin과 Access-Control-Allow-Origin을 비교하여 SOP를 위반했는지 확인한다.

이러한 동작은 아래의 3가지 시나리오에 의해 다시 달라진다.

• Preflight Request
• Simple Request
• Credentialed Request

Preflight Request

브라우저가 예비요청과 본 요청으로 나누어 서버로 전송하게 되는데, 이 예비요청을 Preflight 라고 한다.

• 실제 요청이 전송하기 안전한지 확인함
• 일반적으로 CORS가 발생하는 요청이다.
• OPTIONS 메서드를 사용하여 Preflight Request을 보낸다.
  • OPTIONS 메서드는 목표 리소스와의 통신 옵션을 설명하기 위해 사용됨

💡 Preflight Request로 아래의 정보를 넣어 서버에게 보낸다.

• Access-Control-Request-Method: 클라이언트가 사용할 메서드
• Access-Control-Request-Headers: 클라이언트가 보낼 HTTP headers

Simple Request

명확한 명칭은 없지만 Prefilght Request를 보내지 않고 서버에게 요청을 하는 것을 단순 요청(Simple Request)이라고 한다.

• Preflight Request 보내지 않고 바로 서버에 요청
• 서버는 응답의 헤더에 Access-Control-Allow-Origin과 같은 값을 주어 브라우저가 SOP 위반 여부를 판단하게 함
  • Access-Control-Allow-Origin: * | <origin> | null
  • Access-Control-Allow-Origin: <origin> 인 경우 Vary 속성도 같이 제공해야한다. (MDN 참고)

📖 Vary 헤더 속성은 응답 시간을 줄이기 위해 캐시 응답을 제공할지 또는 원본 서버에 새로운 응답을 요청할지 여부를 결정하는 데 필요한 값이다.

⚠️ Simple Request를 하기 위해 아래의 조건을 전부 만족해야한다.

• GET, HEAD, POST 메소드 중 하나를 사용
• Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안된다.
• Content-Type 사용시 application/x-www-from-urlencoded, multipart/form-data, text/plain 만이 허용

Credentialed Request

Credentialed Request(인증된 요청)은 보안을 강화하고 싶을 때 사용하는 방법이다.
일반적으로 XMLHttpRequest, fetch는 별도 옵션 없이 브라우저의 쿠키 정보, 인증과 관련된 헤더를 요청에 넣지 않는다.

인증 관련 정보를 보내는 경우 JS가 사용자를 대신해 민감한 정보에 접근할 수 있기 때문이다.

요청 헤더에 credentials 옵션을 사용하게 되면 인증 관련된 헤더를 넣을 수 있으며 3가지 값을 사용할 수 있다.

• same-origin: 기본값이며, 같은 출처 간 요청에만 인증 정보를 담게 함
• include: 모든 요청에 인증 정보를 담음
• omit: 모든 요청에 인증 정보를 담지 않음

요청에 인증 정보가 담긴 상태 에서 다른 출처의 리소스를 요청하면 브라우저는 SOP 위반 여부를 검사하는 규칙에 다음 두가지를 추가한다.

• Access-Control-Allow-Origin에는 *를 사용할 수 없음
• 응답 헤더에는 반드시 Allow-Control-Allow-Credentials: true 가 존재해야함

정리

• SOP(Same Orgin Policy)는 같은 origin을 가진 리소스만 접근이 가능하도록 제한하는 브라우저의 정책이다.
• CORS(Cross Orgin Resource Sharing)는 도메인 또는 포트가 서로 다른 origin 간에 리소스를 전달하는 방식을 제어하는 매커니즘이다.
  • CORS 이슈는 SOP에 의해 발생한다.
• 서버에서 SOP를 관리하지는 않고 브라우저에 의해 관리된다.
  • 단 서버에서 origin이나 referer를 확인해서 추가적인 처리를 할수는 있다. (CORS 라이브러리들은 내부적으로 이를 확인한다.)
• 브라우저는 내가 아무것도 하지 않아도 cross origin request 라면 origin헤더와 referer헤더를 자동으로 붙혀준다.

---

참조

• SOP
  • https://developer.mozilla.org/ko/docs/Web/Security/Same-origin_policy
  • https://web.dev/same-origin-policy/
• CORS
  • https://developer.mozilla.org/ko/docs/Web/HTTP/CORS
  • https://evan-moon.github.io/2020/05/21/about-cors/#같은-출처와-다른-출처의-구분
  • https://whywhyy.me/blog/2020/07/18/CORS-와-SOP-란-무엇인가/#응답헤더
  • https://ko.javascript.info/fetch-crossorigin#tasks