CORS

CORS란?

• CORS는 Cross-Origin Resource Sharing의 약자
• 교차 출처 리소스 공유로 번역될 수 있는데, 브라우저에서 다른 출처의 리소스를 공유하는 방법

출처(origin)이란?

• 출처는 Protocol과 Host, Port를 모두 합친 것을 의미
  • 즉, 서버의 위치를 찾아가기 위해 필요한 가장 기본적인 것들을 합쳐놓은 것
  • 출처 내의 포트 번호는 생략이 가능한데, 이는 각 웹에서 사용하는 HTTP, HTTPS 프로토콜의 기본 포트 번호가 정해져있기 때문
    • 그러나 만약 https://google.com:443과 같이 출처에 포트 번호가 명시적으로 포함되어 있다면 이 포트 번호까지 모두 일치해야 같은 출처라고 인정
    • 하지만 이 케이스에 대한 명확한 정의가 표준으로 정해진 것은 아니기 때문에, 더 정확히 이야기하자면 어떤 경우에는 같은 출처, 또 어떤 경우에는 다른 출처로 판단될 수도 있음

• 브라우저의 개발자 도구의 콘솔에서 객체가 가지고 있는 origin 프로퍼티에 접근함으로써 실행되고 있는 출처를 알아낼 수 있음

같은 출처 vs 다른 출처

• 현재 웹페이지의 주소가 https://velog.io/@hwaya2828일 때

  URL	결과	이유
  https://velog.io/@hwaya2828/about	같은 출처	Protocal, Host, Port 동일
  https://velog.io/@hwaya2828/about?q=network	같은 출처	Protocal, Host, Port 동일
  https://velog.io/@hwaya2828/about#network	같은 출처	Protocal, Host, Port 동일
  http://velog.io/@hwaya2828	다른 출처	Protocal 다름
  http://github.io	다른 출처	Host 다름
  https://velog.io/@hwaya2828:8000	?	브라우저에 따라 다름

• 만약 출처에 https://velog.io/@hwaya2828:80처럼 포트 번호가 명시되어 있다면 명백하게 다른 출처로 인정되는 부분이지만, 예시로 든 출처의 경우 포트 번호가 포함되지 않았기 때문에 판단하기가 애매
  • 이런 경우에는 각 브라우저들의 독자적인 출처 비교 로직을 따라가게 됨

• 여기서 중요한 사실 한 가지는 출처를 비교하는 로직이 서버에 구현된 스펙이 아니라 브라우저에 구현되어 있는 스펙이라는 것
  • 만약 우리가 CORS 정책을 위반하는 리소스 요청을 하더라도 해당 서버가 같은 출처에서 보낸 요청만 받겠다는 로직을 가지고 있는 경우가 아니라면 서버는 정상적으로 응답을 하고, 이후 브라우저가 이 응답을 분석해서 CORS 정책 위반이라고 판단되면 그 응답을 사용하지 않고 그냥 버리는 순서인 것

• 즉, CORS는 브라우저의 구현 스펙에 포함되는 정책이기 때문에 브라우저를 통하지 않고 서버 간 통신을 할 때는 이 정책이 적용되지 않음
• 또한 CORS 정책을 위반하는 리소스 요청 때문에 에러가 발생했다고 해도 서버 쪽 로그에는 정상적으로 응답을 했다는 로그만 남기 때문에, CORS가 돌아가는 방식을 정확히 모르면 에러 트레이싱에 난항을 겪을 수도 있음

SOP란?

• 웹에서는 다른 출처로의 리소스 요청을 제한하는 것과 관련된 두 가지 정책이 존재
• 한 가지는 CORS, 그리고 또 한 가지는 SOP(Same-Origin Policy)

• SOP는 2011년, RFC 6454에서 처음 등장한 보안 정책으로 말 그대로 “같은 출처에서만 리소스를 공유할 수 있다”라는 규칙을 가진 정책
• 그러나 웹이라는 오픈스페이스 환경에서 다른 출처에 있는 리소스를 가져와서 사용하는 일은 굉장히 흔한 일이라 무작정 막을 수도 없는 노릇이니 몇 가지 예외 조항을 두고 이 조항에 해당하는 리소스 요청은 출처가 다르더라도 허용하기로 했는데, 그 중 하나가 “CORS 정책을 지킨 리소스 요청”
  • CORS라는 이름이 처음 등장한 것은 2009년이라, SOP의 등장보다 빠름

• 다른 출처로 리소스를 요청한다면 SOP 정책을 위반한 것이 되고, 거기다가 SOP의 예외 조항인 CORS 정책까지 지키지 않는다면 아예 다른 출처의 리소스를 사용할 수 없게 되는 것
• 즉, 이렇게 다른 출처의 리소스를 사용하는 것을 제한하는 행위는 하나의 정책만으로 결정된 사항이 아니라는 의미
  • SOP에서 정의된 예외 조항과 CORS를 사용할 수 있는 케이스들이 맞물리지 않을 경우에는 아예 리소스 요청을 할 수 없는 케이스도 존재할 수 있음

SOP 정책의 장점

• 동일 출처 정책을 지키면 외부 리소스를 가져오지 못해 불편하지만, 동일 출처 정책은 XSS나 XSRF 등의 보안 취약점을 노린 공격을 방어할 수 있음

Tip! XSS란?

• 사이트 간 스크립팅(cross-site scripting, XSS)은 웹 애플리케이션에서 많이 나타나는 취약점의 하나로 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점
  • 주로 여러 사용자가 보게 되는 전자 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어짐
• 이 취약점은 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지 않고 사용할 경우 나타남
• 이 취약점으로 해커가 사용자의 정보(쿠키, 세션 등)를 탈취하거나, 자동으로 비정상적인 기능을 수행하게 할 수 있음
• 주로 다른 웹사이트와 정보를 교환하는 식으로 작동하므로 사이트 간 스크립팅이라고 함

Tip! XSRF란?

• 사이트 간 요청 위조(Cross-site request forgery, CSRF, XSRF)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말함
  • 유명 경매 사이트인 옥션에서 발생한 개인정보 유출 사건에서 사용된 공격 방식 중 하나
• 사이트 간 스크립팅(XSS)을 이용한 공격이 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, 사이트간 요청 위조는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것
  • 일단 사용자가 웹사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출됨

CORS 동작 원리

• 기본적으로 웹 클라이언트 어플리케이션이 다른 출처의 리소스를 요청할 때는 HTTP 프로토콜을 사용하여 요청을 보내게 되는데, 이때 브라우저는 요청 헤더에 Origin이라는 필드에 요청을 보내는 출처를 함께 담아보냄
  • Origin: https://velog.io/@hwaya2828

• 이후 서버가 이 요청에 대한 응답을 할 때 응답 헤더의 Access-Control-Allow-Origin이라는 값에 “이 리소스를 접근하는 것이 허용된 출처”를 내려주고, 이후 응답을 받은 브라우저는 자신이 보냈던 요청의 Origin과 서버가 보내준 응답의 Access-Control-Allow-Origin을 비교해본 후 이 응답이 유효한 응답인지 아닌지를 결정

• 기본적인 흐름은 이렇지만 CORS가 동작하는 방식은 한 가지가 아니라 세 가지의 시나리오에 따라 변경됨

Preflight Request

• 프리플라이트(Preflight) 방식은 일반적으로 우리가 웹 어플리케이션을 개발할 때 가장 흔히 마주치는 시나리오
• 이 시나리오에 해당하는 상황일 때 브라우저는 요청을 한번에 보내지 않고 예비 요청과 본 요청으로 나누어서 서버로 전송
  • 이때 브라우저가 본 요청을 보내기 전에 보내는 예비 요청을 Preflight라고 부르는 것이며, 이 예비 요청에는 HTTP 메소드 중 OPTIONS 메소드가 사용
  • 예비 요청의 역할은 본 요청을 보내기 전에 브라우저 스스로 이 요청을 보내는 것이 안전한지 확인하는 것

• 자바스크립트의 fetch API를 사용하여 브라우저에게 리소스를 받아오라는 명령을 내리면 브라우저는 서버에게 예비 요청을 먼저 보내고, 서버는 이 예비 요청에 대한 응답으로 현재 자신이 어떤 것들을 허용하고, 어떤 것들을 금지하고 있는지에 대한 정보를 응답 헤더에 담아서 브라우저에게 다시 보내주게 됨
• 이후 브라우저는 자신이 보낸 예비 요청과 서버가 응답에 담아준 허용 정책을 비교한 후, 이 요청을 보내는 것이 안전하다고 판단되면 같은 엔드포인트로 다시 본 요청을 보내게 됨
• 이후 서버가 이 본 요청에 대한 응답을 하면 브라우저는 최종적으로 이 응답 데이터를 자바스크립트에게 넘겨줌

• 예비 요청에 대한 응답에서 에러가 발생하지 않고 정상적으로 200이 떨어졌는데, CORS 정책을 위반했다고 콘솔 창에는 빨갛게 에러가 표시될 때 헷갈릴 수 있는데 브라우저가 CORS 정책 위반 여부를 판단하는 시점은 예비 요청에 대한 응답을 받은 이후이기 때문에 CORS 정책 위반으로 인한 에러는 예비 요청의 성공 여부와 별 상관이 없음
• 물론 예비 요청 자체가 실패해도 똑같이 CORS 정책 위반으로 처리될 수도 있지만, 중요한 것은 예비 요청의 성공이나 실패 여부가 아니라 “응답 헤더에 유효한 Access-Control-Allow-Origin 값이 존재하는가”임
  • 만약 예비 요청이 실패해서 200이 아닌 상태 코드가 내려오더라도 헤더에 저 값이 제대로 들어가있다면 CORS 정책 위반이 아니라는 의미

• 대부분의 경우 이렇게 예비 요청과 본 요청을 나누어 보내는 프리플라이트 방식을 사용하기는 하지만, 모든 상황에서 이렇게 두 번씩 요청을 보내는 것은 아님
  • 조금 까다로운 조건이기는 하지만 어떤 경우에는 예비 요청 없이 본 요청만으로 CORS 정책 위반 여부를 검사하기도 함

Simple Request

• 이 시나리오에 대한 정식 명칭은 없지만 MDN의 CORS 문서에서는 이 시나리오를 단순 요청(Simple Request)라고 부르고 있음
• 단순 요청은 예비 요청을 보내지 않고 바로 서버에게 본 요청부터 보낸 후, 서버가 이에 대한 응답의 헤더에 Access-Control-Allow-Origin과 같은 값을 보내주면 그때 브라우저가 CORS 정책 위반 여부를 검사하는 방식
  • 즉, 프리플라이트와 단순 요청 시나리오는 전반적인 로직 자체는 같되 예비 요청의 존재 유무만 다름

• 하지만 아무 때나 단순 요청을 사용할 수 있는 것은 아니고 특정 조건을 만족하는 경우에만 예비 요청을 생략할 수 있는데, 이 조건이 조금 까다롭기 때문에 일반적인 방법으로 웹 어플리케이션 아키텍처를 설계하게 되면 거의 충족시키기 어려움
  • 조건
    • 요청의 메소드는 GET, HEAD, POST 중 하나여야 함
    • Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안됨
    • 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용

• 조건에 명시된 헤더들은 진짜 기본적인 헤더들이기 때문에, 복잡한 상용 웹 어플리케이션에서 이 헤더들 외에 추가적인 헤더를 사용하지 않는 경우는 드뭄
  • 사용자 인증에 사용되는 Authorization 헤더 조차 조건에 포함되지 않음
• 또한 대부분의 HTTP API는 text/xml이나 application/json 컨텐츠 타입을 가지도록 설계되기 때문에 사실상 이 조건들을 모두 만족시키는 상황을 만들기는 그렇게 쉽지 않은 것이 현실

Credentialed Request

• 인증된 요청을 사용하는 방법
  • 이 시나리오는 CORS의 기본적인 방식이라기 보다는 다른 출처 간 통신에서 좀 더 보안을 강화하고 싶을 때 사용하는 방법

• 기본적으로 브라우저가 제공하는 비동기 리소스 요청 API인 XMLHttpRequest 객체나 fetch API는 별도의 옵션 없이 브라우저의 쿠키 정보나 인증과 관련된 헤더를 함부로 요청에 담지 않는데, 이때 요청에 인증과 관련된 정보를 담을 수 있게 해주는 옵션이 바로 credentials 옵션임

  • credentials 옵션에는 3가지 값이 존재

    옵션 값	설명
    same-origin (기본값)	같은 출처 간 요청에만 인증 정보를 담을 수 있음
    include	모든 요청에 인증 정보를 담을 수 있음
    omit	모든 요청에 인증 정보를 담지 않음

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

• 요청에 인증 정보가 담겨있는 상태에서 다른 출처의 리소스를 요청하게 되면 브라우저는 CORS 정책 위반 여부를 검사하는 룰에 다음 두 가지를 추가하게 됨
  • Access-Control-Allow-Origin에는 *를 사용할 수 없으며, 명시적인 URL이어야 함
  • 응답 헤더에는 반드시 Access-Control-Allow-Credentials: true가 존재해야함

CORS 해결 방법

• CORS 동작 원리를 보면 서버에서 Access-Control-Allow-Origin 헤더를 포함한 응답을 브라우저에 보내는 방식으로 CORS 에러를 해결할 수 있음
  • CORS 에러를 확인했다면 서버에서 Access-Control-Allow-Origin 등 CORS를 해결하기 위한 몇 가지 응답 헤더를 포함시켜야 함
  • 프레임워크에 따라 CORS를 해결해 주는 라이브러리 존재

HTTP 응답 헤더

• 라이브러리를 사용하면 간단하게 CORS를 해결할 수 있지만, CORS를 해결하기 위한 응답 헤더가 무엇이 있는지 알고 있으면 좋음

• Access-Control-Allow-Origin: <origin> | *
  • Access-Control-Allow-Origin 헤더에 작성된 출처만 브라우저가 리소스를 접근할 수 있도록 허용함
  • 사용 방법
    • Access-Control-Allow-Origin: https://velog.io/@hwaya2828
      • 브라우저는 https://velog.io/@hwaya2828 에서 서버 응답으로 온 리소스에 접근할 수 있음
    • Access-Control-Allow-Origin: *
      • 브라우저는 출처에 상관없이 모든 리소스에 접근할 수 있음

• Access-Control-Allow-Methods: <method>[, <method>]
  • 브라우저에서 보내는 요청 헤더에 포함된 Access-Control-Request-Method 에 대한 응답 결과로, 리소스 접근을 허용하는 HTTP 메서드를 지정해 주는 헤더
  • 사용 방법
    • Access-Control-Allow-Methods: GET, PUT
      • GET, PUT, POST, DELETE 등의 HTTP 메서드를 ,로 구분하여 넘겨줌

• Access-Control-Expose-Headers: <header-name>[, <header-name>]
  • 서버에서 응답 헤더에 Access-Control-Expose-Headers를 추가해야 브라우저의 자바스크립트에서 헤더에 접근할 수 있음
  • 사용 방법
    • Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
      • ,로 구분하여 여러 개의 헤더를 넣을 수 있음

• Access-Control-Allow-Headers: <header-name>[, <header-name>
  • 브라우저에서 보내는 요청 헤더에 포함된 Access-Control-Request-Headers 헤더에 대한 응답 결과
  • 사용 방법
    • Access-Control-Allow-Headers: X-Custom-Request
      • 자바스크립트에서 커스텀 헤더를 서버에 전달하면 OPTIONS 요청 헤더의 Access-Control-Request-Headers 헤더에 커스텀 헤더 이름이 추가되는데, 서버에서는 Access-Control-Request-Headers에 작성된 값을 보고 Access-Control-Allow-Headers 응답 헤더에 커스텀 헤더 이름을 명시해줘야 함

• Access-Control-Max-Age: <delta-seconds>
  • Preflight 요청 결과를 캐시 할 수 있는 시간을 나타냄
  • 사용 방법
    • Access-Control-Max-Age: 60
      • 초 단위로 캐시 시간을 설정할 수 있으며, 위의 코드는 60초 동안 preflight 요청을 캐시 하는 코드이기 때문에 60초 동안 OPTIONS 메서드를 사용하는 예비 요청을 보내지 않음

• Access-Control-Allow-Credentials: true
  • 자바스크립트 요청에서 credentials가 include일 때 요청에 대한 응답을 할 수 있는지를 나타내며, false로 설정해 주고 싶을 경우에는 헤더를 생략하면 됨
  • 사용 방법
    • Access-Control-Allow-Credentials: true

HTTP 요청 헤더

• 요청 헤더들은 별도로 명시해 주지 않아도 브라우저에서 OPTIONS 요청에 추가함

• Origin: <origin>
  • Origin 헤더는 요청하는 대상의 출처를 나타냄
  • API를 호출하는 페이지의 출처 값이 저장됨

• Access-Control-Request-Method: <method>
  • Access-Control-Request-Method 헤더는 실제 요청이 어떤 HTTP 메서드를 사용하는지 서버에 알려주기 위해 사용됨

• Access-Control-Request-Headers: <field-name>[, <field-name>]
  • Access-Control-Request-Headers 헤더는 브라우저에서 보내는 커스텀 헤더 이름을 서버에 알려주기 위해 사용됨