infra & network

SOP & CORS란?

devJK93 2024. 7. 31.

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

브라우저는 기본적으로 SOP 정책을 따르고 있다.

SOP는 2011년 RFC 6454에서 등장한 보안 정책으로 "같은 출처에서만 리소스를 공유할 수 있다"라는 규칙을 가진 정책.

SOP의 등장배경은 다음과 같다.

1. 보안 강화:

XSS (Cross-Site Scripting) 방지: 동일 출처 정책은 악성 스크립트가 사용자 브라우저에서 실행되어 다른 사이트의 데이터를 훔치거나 조작하는 것을 방지.
CSRF (Cross-Site Request Forgery) 방지: 동일 출처 정책은 공격자가 사용자의 인증 정보를 이용해 다른 사이트에 무단으로 요청을 보내는 것을 막는다.

2. 데이터 보호:

웹 애플리케이션은 종종 민감한 데이터를 다룬다. 동일 출처 정책은 한 사이트의 스크립트가 다른 사이트의 데이터를 읽는 것을 제한함으로써 사용자 데이터를 보호한다.

3. 신뢰할 수 있는 통신:

동일 출처 정책은 웹 브라우저가 특정 출처에서만 자원을 요청하고 응답을 받을 수 있도록 함으로써, 통신의 신뢰성을 높인다. 이는 특히 AJAX 요청에서 중요.

4. 표준화:

웹 보안 표준화의 일환으로, 동일 출처 정책은 브라우저와 웹 개발자 간의 공통된 보안 프레임워크를 제공한다. 이를 통해 보안 관련 혼란을 줄이고, 일관된 보안 정책을 유지할 수 있다.

주된 이유는 웹 보안이며 XSS, CRSF 공격에 대해서는 다음 글에서 설명 예정.

📘 출처 (Origin)

SOP에서 말하는 '같은 출처'란 무엇을 의미할까?

웹에서 말하는 출처 (Origin)는 URL의 스키마(프로토콜), 호스트(도메인), 포트 이 3가지로 정의된다.

동일 출처 예시

http://example.com/hello 와 http://example.com/bye → 프로토콜, 도메인, 포트가 모두 같으므로 동일 출처이다.
http://example.com 와 https://example.com → 같은 리소스를 가리키고 있지만, 프로토콜이 다르므로 동일 출처가 아니다.
http://example.com 와 http://example.com:80 → 얼핏보면 다른 출처같지만, 전자의 경우 http 의 기본 포트인 80이 생략된 형태이므로 이는 같은 출처.

동일 출처끼리 요청을 주고 받아야지만 SOP를 지키는 것이다.

예전에는 출처가 다른 곳으로 요청하는 것 자체를 악의적 행위로 간주했다(CSRF, XSS 등).

왜냐하면 예전의 웹은 프론트엔드 레이어와 백엔드 레이어를 별도로 구성하지 않고 서버가 직접 요청 처리의 결과를 HTML 문서로 만들어 클라이언트에 응답하는 형식이었기 때문.

<html>
  <head>
    <title> PHP example </title>
  </head>
  <body>
    <?php
      $i = 1;

      while($i<=10)
      {
        echo $i."번째<br />";
        $i++;
      }
    ?>
  </body>
</html>

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

서비스중인 어플리케이션의 프론트단에서 제 3자가 제공하는 API를 직접 호출해야하는 등(결제 API, 지도 API, SNS API, 날씨 API, 번역 API, 검색 엔진, 데이터 시각화 API, 머신 러닝 및 AI API, 인증 및 사용자 관리 API 등..) 점점 웹 서비스에서 요구되는 기능들이 늘어났다. 하지만 SOP라는 브라우저 정책 때문에 기본적으로 이는 악의적인 행위로 간주되었다. 따라서 호출하고 싶은 API를 우리의 백엔드 서버를 한번 거쳐서 호출하거나, JSONP 라는 기술도 등장했지만 근본적인 해결 방법이 필요했다.

이런 배경으로 CORS가 등장하게 되었다. 리소스 호출이 허용된 출처를 서버가 명시해놓으면, 출처가 다르더라도 요청과 응답을 주고 받을 수 있도록 만들어놓은 정책이 바로 CORS이다.

📙 CORS 접근 제어 시나리오

📝 1. 단순 요청 (Simple Requests)

https://www.baeldung.com/cs/cors-preflight-requests

브라우저는 다른 출처로의 요청을 보낼 때 자동으로 HTTP 헤더에 Origin 을 추가하여 보낸다.

Origin: https://foo.example

이 응답을 받은 서버는 응답 헤더에 Access-Control-Allow-Origin 을 실어 보낸다. 이 헤더에는 허가된 출처 정보가 담겨있다. 와일드카드를 사용해서 모든 출처를 허용할 수도 있다.

Access-Control-Allow-Origin: *

브라우저는 요청의 Origin 헤더에 담긴 출처 정보가 응답의 Access-Control-Allow-Origin 헤더에 담겨있으면 해당 요청을 안전하다고 간주하고 응답을 가져온다. 만약 그렇지 않다면, 브라우저가 해당 응답을 임의로 파기하고 자바스크립트로 응답의 내용을 전달하지 않는다.

❓ 단순 요청의 조건

하지만 요청이 단순 요청으로 취급되기 위해서는 아래의 조건을 만족해야한다.

GET, POST, HEAD 메서드만 허용된다.
Accept, Accept-Language, Content-Language, Content-Type 헤더만 허용된다.
Content-Type 는 application/x-www-form-urlencoded, multipart/form-data, text/plain 이 세가지 값만 허용된다.
요청에 사용된 XMLHttpRequestUpload 객체에는 이벤트 리스너가 등록되어 있지 않다. 이들은 XMLHttpRequest.upload 프로퍼티를 사용하여 접근한다.
요청에 ReadableStream 객체가 사용되지 않는다.

단순 요청은 흔하지 않다.

하지만, 일반적으로 Content-Type 이 text/xml이나 application/json 컨텐츠 타입인 경우가 굉장히 많으며, 사용자 인증을 위해서 Cookie 혹은 Autorization 와 같은 추가 헤더를 사용하기 때문에 단순 요청의 조건을 맞추기는 쉽지 않다.

또한 애초에 저 조건에 명시된 헤더들은 진짜 기본적인 헤더들이기 때문에, 복잡한 상용 웹 어플리케이션에서 이 헤더들 외에 추가적인 헤더를 사용하지 않는 경우는 드물며 당장 사용자 인증에 사용되는 Authorization 헤더조차 위의 조건에는 포함되지 않는다.
(= Authorization 헤더를 사용하면 Simple Request에 해당되지 않음!)
(= 이외에 다른 커스텀 헤더, 권한과 관련된 헤더가 있으면 Simeple Request에 해당되지 않음! )

추가적으로 HTTP 메소드들 중 GET 이 외의 메소드나, POST 메소드에서 특정 MIME Type은 서버 데이터에 사이드 이펙트를 발생시킬 수 있기 때문에 기본적으로 브라우저는 SimpleRequest가 아닌 Preflight Request 방식으로 요청할 수 있도록 규제한다.

사실상 이 조건들을 모두 만족시키는 상황을 만나기 쉽지 않아 Simple Request 경우는 흔히 보기 어렵다.

📝 2. 프리플라이트 요청 (Preflight Requests)

실제 요청을 보내기 전에 사전 요청을 보내서 해당 리소스에 접근이 가능한지 먼저 확인하는 방식을 Preflight 방식이라고 한다. Preflight는 OPTIONS 메소드를 통해 요청된다.

Preflight 요청은 단순 요청과 마찬가지로 요청에 Origin 헤더를 추가해야한다. Preflight 요청은 여기에 더하여 실제 요청의 메서드를 Access-Control-Request-Method 헤더에, 실제 요청의 추가 헤더 목록을 Access-Control-Request-Headers 헤더에 담아 보내야한다.

실제 요청 이전에 '이런 메소드와 헤더로 요청을 보낼 예정인데, 너희 서버 CORS 정책에서 허용하는 요청이니?' 라고 브라우저가 서버에게 미리 물어보는 절차라고 보면 쉽다.

Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

응답 역시 단순 요청과 마찬가지로 Access-Control-Allow-Origin 헤더가 전송되어야 한다. 여기에 더해 서버 측에서 허용하는 메서드 목록이 담긴 Access-Control-Allow-Methods 헤더와 허가 헤더 목록이 담긴 Access-Control-Allow-Headers 헤더, 마지막으로 Preflight의 캐시 기간인 Access-Control-Max-Age 을 보내줘야 한다.

Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

Preflight 요청 때문에 실제 요청은 한번이지만 두번의 요청을 보내야하는 일이 발생한다. Preflight 캐시 기간을 보내는 이유는 Preflight로 발생하는 이런 오버헤드를 줄이기 위함이다.

❓ Preflight 요청이 필요한 이유는 무엇일까?

위에서 이야기한 것 처럼 CORS는 서버가 아닌 브라우저 구현 스펙에 포함된 정책이다. 따라서 서버는 CORS 위반 여부와 상관없이 일단 요청이 들어오면 처리를 하고 응답을 보낸다. 그 응답을 받은 브라우저가 응답 헤더를 확인하고 응답의 파기 여부를 결정하게 된다.

GET과 HEAD와 같은 요청은 단순 조회를 하기 때문에 상관없지만, POST, PUT, DELETE 와 같은 메서드는 서버에 부작용 (Side Effect) 을 야기할 수 있다. 이는 응답이 유효하지 않아 파기한 브라우저의 의사와 상관없이 발생한다.

Preflight는 실제 요청이 CORS를 위반하지 않았는지를 미리 확인하고, 부작용으로부터 서버를 보호하기 위해 전송한다. 하지만 POST와 같은 경우 조건만 만족하면 Preflight 요청 대신 단순 요청으로 전송될 수 있으므로 백엔드에서도 이에 대한 처리가 필요하다.

Postman이 CORS를 발생시키지 않는 이유.

참고로 Preflight 요청은 브라우저에서 자동으로 전송되므로 프론트엔드 개발자가 직접보낼 필요는 없다.

개발을 하면서 Postman 을 사용하면 정상적으로 요청이 되는데, 웹브라우저에서 호출 하기만 하면 CORS가 발생하는 경우를 겪어봤을 것이다. 브라우저와 다르게 Postman 과 같은 API 테스팅 도구에서는 기본적으로 Preflight 를 보내지 않기 때문이다.

CORS 정책 위반 확인 → Access-Control-Allow-Origin 값이 존재 유무

😬 주의할 점

예비 요청에 대한 응답에서 에러가 발생하지 않고 정상적으로 200이 떨어졌는데, 콘솔 창에는 빨갛게 에러가 표시되는 경우가 있다. 이는 CORS 정책 위반으로 인한 에러는 예비 요청의 성공 여부와 별 상관이 없다. 브라우저가 CORS 정책 위반 여부를 판단하는 시점은 예비 요청에 대한 응답을 받은 이후이기 때문이다.

물론 예비 요청 자체가 실패해도 똑같이 CORS 정책 위반으로 처리될 수도 있지만, 중요한 것은 예비 요청의 성공/실패 여부가 아니라 “응답 헤더에 유효한 Access-Control-Allow-Origin 값이 존재하는가”이다. 만약 예비 요청이 실패해서 200이 아닌 상태 코드가 내려오더라도 헤더에 저 값이 제대로 들어가있다면 CORS 정책 위반이 아니라는 의미이다.

→ 응답 상태는 200이지만, Access-Control-Allow-Origin에서 차이가 있는 것을 확인 가능.

→ 'Access-Control-Allow-Origin: *' 이 헤더가 의미하는 것은 어떠한 Origin 이든 허용한다는 뜻이며, 특정 Origin만 허용하고 싶다면, 서버에서 응답헤더에 "Access-Control-Allow-Origin: https://foo.example" 로 값을 설정해 주면 된다.

📝 3. 인증정보를 포함한 요청 (Credentialed Requests)

3번째 시나리오는 헤더에 인증과 관련된 정보(쿠키, 토큰 등)를 담아서 보내는 Credential Request (인증된 요청)을 사용하는 방법이다.
CORS의 기본적인 방식이라기 보다는 다른 출처 간 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법이다.

예를 들어, 자바스크립트의 fetch API를 사용하거나 Axios, Ajax 등을 사용할 때 서버로 쿠키를 함께 전송해야 하는 경우가 있는데, 요청에 쿠키가 담기게 되면 Credentialed Request 허용이 되어 있어야 한다.

즉, 인증과 관련된 정보를 담을 수 있게 해주는 옵션 'credentials'를 줘야하는데, 이 때 서버 쪽에서 응답 헤더에 Access-Control-Allow-Credentials: true를 보내주지 않는다면 브라우저에서 응답을 받는 것을 거부하게 된다.

이 옵션에는 총 3가지의 값을 사용할 수 있으며, 각 값들이 가지는 의미는 다음과 같다.

same-origin : 같은 출처 간 요청에만 인증 정보를 담을 수 있다.
include : 모든 요청에 인증 정보를 담을 수 있다.
omit : 모든 요청에 인증 정보를 담지 않는다.

fetch("http://example.com/", {
  method: "PUT",
  credentials: "include",
})

참고로 XMLHttpRequest 혹은 Axios 를 사용할 경우 withCredentials 옵션을 true 로 설정해주면 된다.

만약 same-origin이나 include와 같은 옵션을 사용하여 리소스 요청에 인증 정보가 포함된다면, 이제 브라우저는 다른 출처의 리소스를 요청할 때 단순히 Access-Control-Allow-Origin만 확인하는 것이 아니라 좀 더 빡빡한 검사 조건을 추가하게 된다.

요청에 인증 정보가 담겨있는 상태에서 다른 출처의 리소스를 요청하게 되면 브라우저는 CORS 정책 위반 여부를 검사하는 룰에 다음 두 가지를 추가하게 된다.

Access-Control-Allow-Origin에는 * (와일드카드)를 사용할 수 없으며, 명시적인 URL이어야한다.
(https://foo.com 과 같이 구체적인 origin을 지정해주어야 한다.)
응답 헤더에는 반드시 Access-Control-Allow-Credentials: true가 존재해야한다.

📚 출처

CORS가 대체 무엇일까? (feat. SOP)

웹 어플리케이션을 개발하다보면 거의 항상 CORS 이슈를 마주하게 된다. 그때마다 항상 이리저리 헤매며 해결방법만을 찾아 다녔는데, 이번 기회에 CORS가 무엇인지 조금 깊게 공부해보았다. 출처

hudi.blog

CORS란 무엇인가?

CORS가 무엇인지 알기 전에, 이 CORS가 등장하게 된 배경을 먼저 알아보자.SOP는 2011년 RFC 6454에서 등장한 보안 정책으로 "같은 출처에서만 리소스를 공유할 수 있다"라는 규칙을 가진 정책이다.그러

velog.io

https://www.baeldung.com/cs/cors-preflight-requests

'infra & network' 카테고리의 다른 글

HTTPS란 (SSL / TLS) (0)	2024.08.11
[Network] 만약 DNS가 요청한 도메인 정보를 가지고 있지 않다면? (0)	2024.06.09
[Network] 웹 브라우저에 URL을 입력한다면 일어나는 일 (2)	2024.05.19