Client - Server : SOP와 CORS

📌  SOP? (Same Origin Policy)

 

동일 출처 정책으로, 하나의 Origin에서 로드된 문서나 스크립트가 다른 Origin의 자원과 상호작용하지 못하도록 제한하는 것.

 

여기서 말하는 Origin은 아래 3가지 요소를 조합한 것이다.

✔  URL Scheme (http, https ... etc URL SCHEME 종류 참고)
✔  Hostname [NodeName] (localhost, 내 블로그 기준 -> code-designer)
✔  port (3000, 8080 ...)

 

예전에는 브라우저에서 요청을 보내면, 서버에서 해당하는 로직을 수행한 뒤 "HTML을 완성시켜 반환"해줬다.

즉, 하나의 서버(동일한 Origin)에서 모든 작업이 수행되었다.

다른 브라우저와 교류할 일도 적었고,

만약 우리 서버와 연결되어 있지 않은 곳에서 요청이 들어오면 보안상 공격이라고 생각했기 때문에, SOP 정책이 유지될 수 있었다.

 

 

📌  CORS?  (Cross-Origin Resource Sharing)

 

날로 다형화되는 웹 페이지를 감당하기 위해 등장한 것이 CORS다. 물론 SOP의 단점도 커버한다.

교차 출처 리소스 공유 정책으로, 다른 Origin과 상호작용할 수 있게 접근 권한을 확인하고, 부여하는 방식의 규약이다.

 

말이 좀 어려운데, 쉽게 풀어보자면

SOP 방식이 있었던 건 결국 보안 문제였다. 서버와 통신하고 있는 브라우저 이외의 접근은 마음껏 허용할 수 없었다.

그런데 서버에서 "이런 Origin 들은 접근해도 괜찮아" 라며 믿을만한 Origin들을 지정해 준다면 ?! 안전하게 통신할 수 있지 않나?!

즉 서버가 허용한 클라이언트에게만 응답할 수 있게끔 (안전도 챙기고 다형성도 챙기고) 만든 정책이 CORS인거다 ^____&

 

CORS는 아래 3가지 요청에 따라 다르게 동작한다.

✔  Simple Request ( 단순 요청 )
     ** 사실 CORS를 정의한 Fetch 명세는 'Simple Request'라는 용어를 사용하지 않는다.**
     ** Preflight Request와 대비되게 표현하기 위해 임의적으로 사용한다.**
✔  Preflight Request ( 사전 요청 )
✔  Credentialed Request ( 인증 정보有 요청 )

 

◾  Simple Request 

 

 

https://ko.javascript.info/fetch-crossorigin

 

Simple Request를 보내기 위해서는, 본 요청이 서버가 원하는 메서드와 헤더를 지니고 있어야 한다.

1. 요청 메서드가 아래 중 하나여야 한다.

      ✔  GET 
      ✔  POST 
      ✔  HEAD 

2. 요청 메서드가 POST라면, 요청 메서드의 Content-Type이 아래 중 하나여야 한다.

      ✔  application/x-www-form-urlencoded
      ✔  multipart/form-data
      ✔  text/plain

3. User-Agent가 자동으로 설정한 header나
    CORS-safelisted request-header로 정의된 헤더
    외의 커스텀 헤더를 사용하면 안된다. ( 아래는 허용. 이외는 금지 !! )

     📍 forbidden header name  (수동으로 설정 불가)
      ✔  Accept-Charset
      ✔  Accept-Encoding
      ✔  Access-Control-Request-Headers
      ✔  Access-Control-Request-Method
      ✔  Connection
      ✔  Content-Length
      ✔  Cookie
      ✔  Cookie2
      ✔  Date
      ✔  DNT
      ✔  Expect
      ✔  Host
      ✔  Keep-Alive
      ✔  Origin  
      ✔  Referer
      ✔  TE
      ✔  Trailer
      ✔  Transfer-Encoding
      ✔  Upgrade
      ✔  Via

     📍 CORS-safelisted request-header name (수동으로 설정 가능) ⭐⭐
      ✔  Accept
      ✔  Accept-Language
      ✔  Content-Language
      ✔  Content-Type

 

Simple Request 로 요청을 보내기란 .. 꽤 어렵다. 

일반적으로 HTTP API는 Content-Type으로 application/json 타입을 가지도록 설계하고, (보통 JSON형식으로 주고받으니)

토큰을 인증해야하는 (로그인, 비밀번호 등) 경우에는 Authorization header를 사용한다고 .. !!

실제로 Simple Request를 사용하게되는 빈도가 궁금하긴 하다 ㅋㅋ

 

Simple Request 로 서버에 요청을 보내게 되면,

해당 Origin의 허용 여부 ( Access-Control-Allow-Origin ) 를 검사한 후 통과했을 때

브라우저에 요청에 대한 응답을 전달한다.

 

 

◾  Preflight Request

 

 

https://ko.javascript.info/fetch-crossorigin

 

Simple Request 조건을 만족하지 않는 경우는 Preflight Request 방식으로 진행된다.

Preflight Request 는 앞선 Simple Request처럼 바로 본 요청을 보내지 않는다.

"내가 이런 메서드, 이런 헤더를 가지고 있는데 너희 서버와 통신해도 되겠니 ..?" 라는 예비 요청을 보낵고

"음 나는 이런 메서드, 이런 헤더를 허용해. 넌 들어와도 되겠다/안 되겠다." 등의 응답을 받는 후 본 요청을 보낸다.

당연히 "넌 안돼" 라는 응답을 받으면 데이터 요청은 거부된다. 허용됐을 시에만 데이터를 반환한다.

이후 본 요청이 수행되는 과정은 Simple Request와 동일하다.

 

Simple Request와 Preflight Request의 교류 방식을 보면 알겠지만, 서버에게는 메서드와 헤더가 정말 중요한 것 같다.

원하는 메서드와 헤더를 가지고 있으면 해당 Origin을 허용하는 지 여부만 따지고 데이터 반환 여부를 결정한다.

Preflight Request도 메서드와 헤더를 검사해서 허용되지 않으면 응답을 거부하는 로직을 보며 추측할 수 있다.

 

 

◾  Credentialed Request

 

아직 써보지 않아서 ... 사용해 본 다음에 내용을 정리하겠다

 

 

 

 

 

 

 

 

 

 

참고 > request-header 인지 response-header 인지 분별을 잘 해야한다.

 

📍 CORS-safelisted request-header name      

      ✔  Accept
      ✔  Accept-Language
      ✔  Content-Language
      ✔  Content-Type

 

📍 CORS-safelisted response-header name 

     ✔  Cache-Control

     ✔  Content-Language
     ✔  Content-Length

     ✔  Content-Type
     ✔  Expires
     ✔  Last-Modified
     ✔  Pragma 

 

 

 

 

 

 

참고 자료

https://ko.javascript.info/fetch-crossorigin

https://kyu9341.github.io/WEB/2020/10/24/WEB_CORS/

https://developer.mozilla.org/en-US/docs/Glossary/CORS

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Allow

https://sowells.tistory.com/170

https://fetch.spec.whatwg.org/#http-new-header-syntax

https://docs.aws.amazon.com/ko_kr/apigateway/latest/developerguide/how-to-cors.html

https://nodejs.org/ko/docs/guides/anatomy-of-an-http-transaction/

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS