CORS 공부

그래도 아무튼 개발자·2023년 4월 18일

cors http 프론트엔드

웹프로그래밍

목록 보기

5/7

웹 개발을 하다보면 반드시, 혹은 정말 자주 마주치는 에러가 바로 CORS 이다. 누구나 한 번 이상은 무조건 적으로 겪는 에러로, 많은 신입 개발자들이 이로 인해 골머리를 앓는다..

CORS

Cross Origin Resource Sharing

우선 CORS를 학습하기 이전에 SOP에 대해서 알고 넘어가야 한다.

SOP

Same-Origin Policy의 줄임말로, 말 그래도 동일 출처 정책을 뜻한다. 한 마디로 같은 출처의 리소스만 공유가 가능하도록 만든 정책

위에서 말하는 Origin은 위 그림과 같이 프로토콜, 호스트, 포트로 구성된다. 한 마디로 이 3개의 Origin과 하나다로 다르다면 동일 출처로 보지 않는다는 것이다.

아래 표는 https://www.domain.com:3000 출처에 대한 여러 URL에 따른 동일 출처 비교 표 이다.

이러한 동일 출처 정책이 생겨난 이유는 간단하다. '보안'이다. 사실 만약 출처가 다른 두 어플리케이션이 자유로이 소통할 수 있는 환경이 주어졌다면 이러한 환경은 보안상으로 상당히 위험한 환경이다. 만일 이러한 상황에서 SOP 정책이 없다면, 해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 우리가 만든 어플리케이션에서 해커가 심어놓은 코드가 실행하여 개인 정보를 가로챌 수 있다.

하지만 인터넷은 여러 사람들에게 오픈된 환경이고, 이런 환경에서 웹페이지에서 다른 출처에 있는 리소스를 가져와 사용하는 일은 매우 흔한 일이라 무턱대고 막을 수는 없는 일이다. 여기서 나온 것이 바로 CORS이다!
아무리 보안이 중요하지만, 개발을 하다 보면 기능상 어쩔 수 없이 다른 출처 간의 상호작용을 해야 하는 케이스도 있으며, 또한 실무적으로 다른 회사의 서버 API를 이용해야 하는 상황도 존재한다. 따라서 이와 같은 예외 사항을 두기 위해 CORS 정책을 허용하는 리소스에 한해 다른 출처라도 받아들인다는 것이다.

MDN에서는 CORS를 다음과 같이 정의하고 있다.

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

즉, 브라우저는 SOP에 의해 기본적으로 다른 출처의 리소스 공유를 막지만, CORS를 사용하면 접근 권한을 얻을 수 있게 되는 것이다.

CORS 기본 동작 방식

기본 동작 방식으로는 3단계로 나뉜다.

프리플라이트 요청
단순 요청
인증정보를 포함한 요청

프리 플라이트 요청

실제 요청을 보내기 전, OPTIONS 메서드로 사전 요청을 보내 해당 출처 리소스에 접근 권한이 있는지부터 확인하는 것을 말한다.

만일 위 과정에서 실제 요청을 보낸 출처가 알고보니 접근 권한이 없다면, 브라우저에서 CORS 에러를 띄우게 되고, 받아놨던 실제 요청은 전달되지 않는다.

이러한 과정은 한 가지 문제점이 있는데, 요청을 보내기 전에 OPTIONS 메서드로 예비 요청을 보내 보안을 강화하는 목적의 취지는 좋다. 그러나 결국은 실제 요청에 걸리는 시간이 늘어나게 되어 어플리케이션 성능에 영향을 미치는 크나큰 단점이 있다.

단순 요청

특정 조건이 만족되면 프리플라이트 요청을 생략하고 요청을 보내는 것을 말한다.

프리플라이트 요청과 달리 다이렉트로 서버로 요청한다고 보면 된다.

다만, 과정이 매우 심플한 만큼 특정 조건을 만족하는 경우에만 예비 요청을 생략할 수 있다.

대표적으로 아래 3가지 경우를 만족 할때 만 가능하다.

요청의 메소드는 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중 하나여야한다. 아닐 경우 프리플라이트 요청으로 동작된다.

모두 충족하기엔 까다로운 조건들이 많기 때문에, 위 조건을 모두 만족되어 단순 요청이 일어나는 상황은 드물다고 보면 된다.
현존하는 대부분 HTTP API 요청은 text/xml 이나 application/json 으로 통신하기 때문에 3번째 Content-Type이 위반되기 때문... 이 때문에 대부분의 요청은 단순 요청이 아닌 프리 플라이트 요청으로 이루어진다고 생각하면 된다.

인증정보를 포함한 요청

요청 헤더에 인증 정보를 담아 보내는 요청이다. 주로 민감한 정보를 다루기 때문에 출처가 다를 경우에는 별도의 설정을 하지 않으면 쿠키를 보낼 수 없다. 따라서 이 경우에는 클라이언트, 서버 양측 모두 CORS 설정이 필요하다.

CORS 설정 방법

Node.js

const http = require('http');

const server = http.createServer((request, response) => {
// 모든 도메인
  response.setHeader("Access-Control-Allow-Origin", "*");

// 특정 도메인
  response.setHeader("Access-Control-Allow-Origin", "https://www.domain.com");

// 인증 정보를 포함한 요청을 받을 경우
  response.setHeader("Access-Control-Allow-Credentials", "true");
})

Express

const cors = require("cors");
const app = express();

//모든 도메인
app.use(cors());

//특정 도메인
const options = {
  origin: "https://www.domain.com", // 접근 권한을 부여하는 도메인
  credentials: true, // 응답 헤더에 Access-Control-Allow-Credentials 추가
  optionsSuccessStatus: 200, // 응답 상태 200으로 설정
};

app.use(cors(options));

//특정 요청
app.get("/example/:id", cors(), function (req, res, next) {
  res.json({ msg: "example" });
});

Express 프레임워크를 사용해서 서버를 만드는 경우에는, 위와 같이 cors 미들웨어를 사용해서 더욱 간단하게 CORS 설정을 해줄 수 있다.