CORS (Cross - origin resource sharing)

CORS 정책은 우리가가져오는 리소스들이 안전한지 검사하는 관문이다!

추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 체제!

현재 브라우저로 접속중인 페이지에서 JS를 이용해 다른 도메인 또는 포트를 가진 주소로 요청하는 경우, 해당 리소스에 접근을 허용했는지 확인해 보안을 높이는 동작입니다.

HTML : 기본적으로 Cross-Origin정책을 따른다.

• link 태그에서 다른 origin의 css등의 리소스에 접근하는 것이 가능

• img 태그 등에서 다른 리소스에 접근하는 것이 가능

XMLHttpRequest, Fetch API등 script 태그 내 : 기본적으로 Same-Origin정책을 따름

• JS는 서로 다른 도메인에 대한 요청을 보안상 제안한다.(브라우저 기본 설정은 하나의 서버 연결만을 허용!)

• 브라우저는 주소(도메인, 포트 중 하나라도)가 다른 경우 리소스의 출처가 다르다고 판단!

---

📍CORS 탄생배경

이전의 브라우저 정책으로는 오리진이 다르면 요청을 주고 받을 수 없었다.

그러나 지금은 CORS를 통해 다른 오리진과 요청을 주고 받을 수 있게 되었다.

그렇다면 그이유가 무엇인지 알아보자.

이전의 웹 브라우저에서 서버와 통신하는 방식을 살펴보면 아래 그림과 같다.

브라우저에서 요청을 하면 HTML Page를 내려주는 방식이었다.

🔥웹 사이트의 발전

하지만 웹 사이트에서 단순 문서 제공만 하는게 아닌 다양한 기능을 가진 웹 어플리케이션 개발이 시작되면서 브라우저가 기존에 가지고 있었던 보안 정책으로 인한 불편함이 발생을 하였다.

사람들은 Web Server를 거치지 않고 한번에 통신하기를 원했으며,

개발자들은 JSONP라는 우회적인 방법을 선택하여 통신을 하였다.

하지만 브라우저 입장에서는 이런 우회적인 루트로 보안을 무력화 시키는 것을 방치할 수는 없었다.

그렇다고 너무 많은 수요가 있었기에 이 방식을 막아버릴 수도 없었다.

따라서 브라우저에서 우회적인 루트가 아닌 공식적인 루트를 제시해주었다.

그게 바로 CORS이다.🤗

---

출처(Origin)란?

: Protocol + Host + Port

---

🤔문제발생 이유

1. 브라우저가 요청하려고 시도했던 주소에 “OPTIONS” Method를 이용해 요청을 의도적으로 허용하고 있는게 맞는지 확인한다. (CORS preflight)
2. 요청을 받은 서버는 평소와 똑같이 응답을 한다.
3. 응답을 받은 브라우저는 요청에 대한 허가를 받지 못했다고 판단하고 CORS 에러발생!

• 이것은 브라우저에 구현된 비동기 요청 API에서만 동작하는 규칙으로, Thunder Client 같은 API Client를 이용해 요청하는 경우에는 절대 발생하지 않는다.(local 환경에서는 발생X)

---

📍CORS 기본 동작과정

1. 클라이언트에서 HTTP 요청헤더에 Origin을 담아 전달한다.
2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.
3. 클라이언트에서, 자신이 보냈던 요청의 Origin과 서버가 보내준 Access-Contorl-Allow-Origin을 비교한다.

👉 비교후 만약 유효하지 않다면 그 응답을 사용하지 않고 버린다.(차단!)

---

📍CORS의 세가지 시나리오

1. 기본 요청(단순 요청) Simple Request

예비 요청을 보내지 않고, 바로 HTTP Request를 하는 방식.
이 방식은 밑의 조건을 충족해야 적용된다.

• GET, POST, HEAD 중 하나라도 메서드가 포함이 되었을 때
• 웹 브라우저가 자동으로 설정한 헤더들만을 포함할 때
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

2.Preflight Request

브라우저는 예비요청을 HTTP method 중 OPTIONS를 이용해서 다음과 같은 확인 사항을 검사한다.

• Origin : 출처 정보 (서버에서 허락한 출처의 요청인지 검사)
• Access-Control-Request-Method : HTTP METHOD가 유효한지 검사
• Access-Control-Request-Headers : 본 요청에 HTTP의 HEADER가 유효한지 검사

서버는 해당 예비요청에 대한 응답으로 허락된 정책에 대한 정보를 제공한다.

• Access-Contorl-Allow-Origin : 서버가 허락한 출처들 (Protocol + Host + Port)
• Access-Control-Allow-Methods : 허락한 HTTP Method 리스트 업
• Access-Control-Allow-Headers : 허용되는 HEADERS 정보
  ( ' * ' 와일드 카드시 전부 허용하지만, Authorization은 따로 명시해야됨)
• Access-Control-Max-Age : 서버가 preflight요청에 대한 응답의 수명 (초 단위)

✔️하지만, 여기서 중요한 것은 이 예비요청의 응답 성공여부와 상관없이 CORS에러가 발생할 수 있다는 점이다.

예를 들어, 가끔씩 Preflight Request가 200 성공 응답을 주었어도 브라우저에 CORS에러가 나와 많이 당황한다.

이렇게 되는 이유는 일단 CORS 에러가 발생하는 시점이 예비 요청을 받고난 직후이기 때문이다. preflight request에서 검사한 정보에서 더 추가된 정보가 있거나, 메인 요청의 URL이 달라졌기 때문에 메인 요청에서 CORS 에러가 발생할 수 있다.

이 Preflight Request 방식은 Simple Request 방식에 적용될 수 없을 때 사용됩니다. 즉, Simple Request에 해당 사항이 없다면 예비요청이 발생 됩니다.

3.Credential Request(인증 요청)

인증된 요청을 사용하는 방법이다.
브라우저가 제공하는 리소스 요청인 XMLHttpRequest 객체나 fetch 는 기본적으로 인증과 관련된 쿠키나 헤더를 요청에 담지않고, credentials옵션을 적용해야지 담을 수 있다.

이 credential은 3가지 옵션을 가지며 다음과 같이 fectch를 사용할 때 옵션값을 설정하여 요청을 보낼수 있다.

✔️credentials 옵션을 include로 설정했을 때, CORS 정책에 2가지 항목이 더 추가된다.
1. Access-Control-Allow-Origin에는 *를 사용할 수 없으며, 명시적인 URL이어야한다.
2. 응답 헤더에는 반드시 Access-Control-Allow-Credentials: true가 존재해야한다.

Credentials 옵션

1. same-origin (기본값) : 같은 출처간의 요청에만 인증 저보를 담을 수 있다.
2. include : 모든 요청에 인증 정보를 담을 수 있다.
3. omit : 모든 요청에 인증정보를 담을 수 없다.

---

📍CORS 해결방법

1. Chrome 확장 프로그램 이용: Allow CORS : Access-Control-Allow-Origin 설치!
2. 서버에서 Access-Control-Allow-Origin 세팅하기

res.setHeader(’Access-Control-Allow-origin’, ‘*’); 
//'*'을 사용하면 모든 origin에서 오는 요청을 허용한다는 의미로, 
// 당장은 편해도 이상한 출처에서 오는 요청까지 모두 허용하기 때문에 보안이 허술해짐!
// 그러니 조금 불편하더라도 특정 도메인만 추가하는 걸로 하는게 좋음!
res.setHeader(’Access-Control-Allow-Credentials’ ‘true’);  //쿠키 주고받기 허용

✔️모듈설치방법

• 터미널에 npm i cors 명령어를 입력해 CORS 모듈 설치

• 미들웨어 추가

  • 모든 요청 허용 :

    app.use(cors());

  • 특정 도메인만 허용:

    const corsOption = {
      origin: "https://www.test-cors.org",
      credentials: true,
    };
    
    app.use(cors(corsOption));

  ---

⛵2022.06.02-09

항해톡을 준비하며 CORS에 대해 지긋!지긋!하게 들은 것같다.
오리진희라는 별칭도 얻으며 끝났던 CORS항해톡!

그래도 이 에러에 대해 제대로 알고가게 되어서 다행이라고 생각이 든다.
내가 일을 할때, 프론트에서 이러한 에러가 떴다면 누구의 탓만 할 게 아니라 서로 확인하고 맞춰나가야한다는 걸 더욱 느끼게 되었고, 더욱 서로를 이해할 수 있는 계기가 되는 것같았다.

확실히 시작때보다 훨씬 성장했다는 느낌이 들어 기분이 굉장히 좋다.
나자신 굉장히 칭찬해!

제발 나태해지지만 말고 끝까지 해보자!🤓