CORS(Cross-Origin Resource Sharing)와 proxy

CORS?

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제입니다. 웹 애플리케이션은 리소스가 자신의 출처(도메인, 프로토콜, 포트)와 다를 때 교차 출처 HTTP 요청을 실행합니다. - MDN, CORS

CORS란 다른 출처의 자원에 접근할 수 있는 권한을 부여하도록 알려주는 체제라고 했다.

다시 말하면, 기본적으로 실행 중인 웹 애플리케이션이 다른 출처에 접근할 수 없다는 말이다.

❌ Access to fetch at ‘https://localhost:8080/ from origin ‘http://localhost:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

출처(Origin)?

그렇다면 여기서 말하는 출처란 무엇인가?

  http://example.com:8042/over/there?name=ferret#nose
  \___/\________________/\_________/ \_________/ \__/
   |           |            |            |        |
protocol      host         path        query   fragment

여기서 출처란 protocol + host를 합친 것을 의미한다.

즉, 리소스를 받아올 서버의 기본적인 위치를 의미한다.

다시 말해 다른 출처라는 것은 다른 서버라는 말이다.

SOP(Same-Origin Policy)

다른 서버에서 리소스 좀 편하게 받아오면 안될까..? 필요한 것좀 가져다 펑펑 써보자..

다른 출처의 정보를 편하게 가져온다는 것은

반대로 말하면, 내 서버의 자원을 누군가 맘껏 가져갈 수 있다는 것이다.

공유하는 것은 좋지만, 이는 보안상 매우 위험한 환경에 노출된 것이라고 볼 수 있다.

악의적인 의도를 가진 누군가(ex, hacker)가 마음대로 접근해 소스 코드를 훑어보고 XSS(Cross-Site Scripting)등의 방법으로 해킹하기 수월해질 수 있기 때문이다.

그래서, SOP(Same-Origin Policy), “같은 출처에서만 리소스를 공유할 수 있다”라는 보안 정책이 제시되었다.

하지만, 요즘 웹 생태계는 Front-end, Back-end가 분리되어 있는 경우가 흔하고, 다른 출처의 리소스를 가져와서 사용하는 일이 비일비재하다.

이와 같은 웹이라는 공유의 환경에서 무작정 다른 출처에 대한 접근을 막을 수 없기 때문에, 몇 가지 예외 조항을 세우고, 이 조항을 지키는 리소스 요청은 다른 출처(Cross-Origin)이어도 허용되도록 했는데, 이 중 하나가 “CORS 정책을 지킨 리소스 요청”이라고 한다.

---

작성 중…