[Seminar4] CORS

[yeeun0702]

💡CORS란 ?

CORS(Cross-Origin Resource Sharing)는 출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념입니다. 직역하면, 교차되는 출처 자원들의 공유입니다. 다른 출처에 있는 자원을 요청한다고 하면, 이를 교차 출처 요청이라고 부릅니다.

정리하자면, CORS란 도메인이 다른 서버끼리 리소스를 주고 받을 때 보안을 위해 설정된 정책이라고 생각하면 됩니다.

다른 출처의 자원에 접근해서 리소스를 사용한다는 의미입니다.

🔎 CORS와 관련해서 우리가 개발을 할 때 마주하는 문제 !!
웹 프론트 엔드와 api 서버를 따로 구성하는 경우, 프론트 엔드에서 다른 origin의 api 서버로 요청을 보내면 문제가 발생합니다.

🔎 하지만, Postman이나 서버에서 같은 요청을 보내면 통과된다! 왜 그럴까?
Postman이나 백엔드에서는 CORS 정책을 따르지 않기 때문입니다. CORS는 오로지 브라우저(크롬, 엣지, 사파리같은 프론트엔드)가 적용하는 보안 정책이기 때문에 서버 사이에서는 아무런 문제 없이 데이터를 주고받을 수 있습니다.

🔎 출처란 ?
요청을 보내는 웹사이트와 요청을 받는 API 서버의 주소

위의 구성요소 중에서 Protocol + Host + Port 3가지가 같으면 동일 출처(Origin)라고 합니다. 
다른 경우에 교차 출처(Cross-Origin) 가 됩니다.

---

💡CORS의 등장배경

웹 애플리케이션의 보안 문제와 사용성 향상 필요성에서 비롯되었습니다. 브라우저는 기본적으로 동일 출처 정책(Same-origin policy)을 따릅니다. Same-Origin Policy(동일 출처 정책)은 보안을 위해 브라우저가 스크립트를 통해 다른 도메인(출처)의 리소스에 접근하지 못하도록 제한하는 정책입니다. 이 정책은 웹 애플리케이션이 악의적인 사이트로부터 데이터를 훔치거나, 민감한 정보에 접근하는 것을 방지하는 중요한 보안 장치입니다.

그러나 웹 애플리케이션이 복잡해지고 분산화되면서, 애플리케이션의 프론트엔드와 백엔드를 분리하여 개발하는 방식이 보편화되었습니다. 예를 들어, https://example.com에서 호스팅되는 프론트엔드가 https://api.example.com에서 제공되는 API와 통신하는 구조가 일반화되었습니다.

이 경우, 동일 출처 정책에 의해 다른 서브도메인에 접근이 차단되는 문제가 발생했습니다. 따라서 서로 다른 출처 간의 리소스 공유를 안전하게 허용할 수 있는 새로운 메커니즘이 필요해졌습니다.

따라서 CORS가 등장했습니다. !!

CORS는 웹 보안의 필수 요소인 동일 출처 정책의 한계를 보완하고, 동시에 다른 출처의 리소스와 안전하게 상호작용할 수 있는 방법을 제공합니다.

🔎 그런데 만약 CORS 정책이 없다면 ?

CORS 정책이 없고 모든 다른 출처 요청이 가능한 브라우저를 생각해봅시다.

1. CSRF(Cross-Site Request Forgery) 공격 위험 증가
   다른 사이트에서 사용자의 권한으로 민감한 데이터를 변경하거나 접근하는 요청을 보낼 수 있습니다. 예를 들어, 사용자가 은행 웹사이트에 로그인한 상태에서 악의적인 웹사이트가 해당 사용자의 권한으로 은행 서버에 요청을 보내 계좌 이체를 할 수 있습니다.

2. 개인 정보 유출
   다른 도메인에서 자바스크립트를 통해 중요한 데이터(예: 사용자 세션, 인증 토큰 등)에 접근할 수 있게 됩니다. 이렇게 되면 악성 사이트가 사용자의 개인 정보를 수집하거나, 민감한 데이터를 훔칠 수 있습니다.

3. API 남용
   악성 사이트가 API에 자유롭게 접근하여 서비스 자원을 무단으로 사용하는 것을 방지할 수 없게 됩니다. 이는 서비스 비용 증가와 API 오용으로 이어질 수 있습니다.

4. 보안 정책 무력화
   CORS는 브라우저에서 서버 간의 요청을 관리하고 제어하는 중요한 보안 메커니즘입니다. CORS가 없으면 서버의 의도와 상관없이 다양한 도메인에서 서버에 접근할 수 있게 되어 보안이 취약해집니다.

CORS 정책이 없다면 웹 애플리케이션의 보안 수준이 크게 낮아져 악의적인 공격에 매우 취약해집니다. CORS는 이러한 문제를 완화하여, 웹 애플리케이션이 안전하게 상호작용할 수 있도록 도와주는 중요한 보안 기능입니다.

---

💡CORS 동작 과정

📌 CORS 기본 흐름

1. 브라우저가 요청을 전송하면서, 요청 출처(Origin)에 대한 정보를 Origin 헤더에 담아 서버로 보냅니다.
   • Origin 헤더는 요청이 어느 출처(도메인)에서 시작되었는지 서버에 알리는 역할을 합니다.
2. 서버는 요청을 확인하고 응답을 보낼 때, 해당 요청이 허용된 출처인지 여부를 Access-Control-Allow-Origin 헤더를 통해 명시합니다.
   • 서버가 요청을 허용한다면, Access-Control-Allow-Origin 헤더에 요청한 출처(예: https://aaa.com)를 설정하거나, 모든 출처를 허용하는 와일드카드(``)를 설정할 수 있습니다.
3. 브라우저는 서버 응답의 CORS 헤더를 확인합니다.
   • 만약 서버의 Access-Control-Allow-Origin 값이 브라우저의 요청 출처와 일치한다면, 브라우저는 해당 응답을 허용하고 리소스를 사용할 수 있게 됩니다.
   • 일치하지 않거나 Access-Control-Allow-Origin 헤더가 없으면, 브라우저는 CORS 오류를 발생시키고 응답을 차단합니다.

📌 조금 더 자세하게 3가지 시나리오가 존재 !! CORS 요청의 유형

1️⃣ Simple Request (단순 요청)

• Simple Request는 말 그대로 단순한 요청으로, 브라우저가 바로 요청을 전송할 수 있는 경우입니다.
• 이 요청은 보통 추가적인 보안 검증(사전 요청)을 거치지 않고 서버로 직접 전송됩니다.

✅Simple Request 조건

• 요청의 HTTP 메서드가 GET, POST, HEAD 중 하나여야 합니다.
• Content-Type 헤더는 text/plain, application/x-www-form-urlencoded, multipart/form-data 중 하나만 포함해야 합니다.
• 커스텀 헤더(사용자 정의 헤더)를 포함하지 않아야 합니다.

🍃Simple Request 예시

GET /api/resource HTTP/1.1
# HTTP GET 요청으로 api.example.com 서버의 /api/resource 경로에 리소스를 요청

Host: api.example.com
# 요청을 받는 서버의 호스트명 (api.example.com)

Origin: https://aaa.com
# 요청을 보낸 출처의 도메인 (https://aaa.com)
# 서버가 허용된 출처인지 확인하는 데 사용

이 경우, 브라우저는 서버에 Access-Control-Allow-Origin이 설정된 응답을 확인합니다. 만약 서버가 해당 출처를 허용했다면 브라우저는 이 응답을 사용할 수 있습니다.

---

2️⃣ Preflight Request (사전 요청)

• Preflight Request는 민감하거나 서버의 데이터를 변경할 수 있는 요청입니다.
• 브라우저는 본 요청을 보내기 전에 먼저 OPTIONS 메서드로 서버에 사전 요청을 보내서 해당 요청이 허용되는지 확인합니다.

✅ Preflight가 필요한 경우

• 요청 메서드가 PUT, DELETE, PATCH 등 서버의 상태를 변경할 가능성이 있는 메서드인 경우.
• Authorization이나 X-Custom-Header 같은 커스텀 헤더가 포함된 경우.
• Content-Type이 application/json과 같이 일반적이지 않은 특정 타입일 경우.

✅ Preflight Request 과정

1. OPTIONS 메서드로 사전 요청 전송: 브라우저는 서버로 프리플라이트 요청을 먼저 전송합니다. 여기서 요청의 Origin과 요청에 사용할 메서드와 헤더에 대한 정보를 서버에 전달합니다.
2. 서버의 응답: 서버는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등을 응답 헤더에 포함하여, 해당 요청이 허용되는지 알려줍니다.
3. 본 요청 전송: 프리플라이트 요청이 승인되면, 브라우저는 실제 요청을 서버로 보냅니다.

🍃Preflight Request 예시

OPTIONS /api/resource HTTP/1.1
# OPTIONS 메서드를 사용해 사전 요청을 전송하여, DELETE 요청을 허용하는지 확인

Host: api.example.com
# 요청을 받는 서버의 호스트명 (api.example.com)

Origin: https://aaa.com
# 요청을 보낸 출처 (https://aaa.com)
# 서버가 허용된 출처인지 확인하기 위해 포함

Access-Control-Request-Method: DELETE
# 본 요청에 사용할 HTTP 메서드가 DELETE임을 서버에 알림

Access-Control-Request-Headers: Content-Type
# 본 요청에 포함될 헤더(Content-Type)가 있는지 서버에 알림

🍃서버의 프리플라이트 응답 예시:

HTTP/1.1 200 OK
# 사전 요청에 대한 응답이 성공적으로 허용되었음을 나타내는 상태 코드 200

Access-Control-Allow-Origin: https://aaa.com
# https://aaa.com 출처에서의 요청을 허용

Access-Control-Allow-Methods: DELETE
# DELETE 메서드를 허용함을 명시

Access-Control-Allow-Headers: Content-Type
# Content-Type 헤더를 포함한 요청을 허용

🍃본 요청 전송 예시:

DELETE /api/resource HTTP/1.1
# 서버의 /api/resource 경로에 DELETE 메서드를 사용해 실제 데이터 삭제 요청을 전송

Host: api.example.com
# 요청을 받는 서버의 호스트명 (api.example.com)

Origin: https://aaa.com
# 요청을 보낸 출처 (https://aaa.com)

Content-Type: application/json
# 요청 본문이 JSON 형식임을 나타내는 Content-Type 헤더

---

3️⃣ 인증 정보 포함 요청 (Credentials)

• 인증 정보가 필요한 요청의 경우, 클라이언트와 서버 모두 별도의 설정이 필요합니다. 예를 들어, 쿠키나 로그인 토큰 같은 정보를 서버로 전송할 때가 이에 해당합니다.

✅인증 정보 포함 요청의 조건

• 클라이언트는 credentials: 'include' 옵션을 설정하여 브라우저가 쿠키나 세션 같은 인증 정보를 포함하도록 명시합니다.
• 서버는 응답에 Access-Control-Allow-Credentials: true 헤더를 추가해, 인증 정보 포함 요청을 허용하겠다는 의사를 표시해야 합니다.

주의: Access-Control-Allow-Origin에 와일드카드 *를 사용할 수 없고, 특정 도메인만 지정해야 합니다.

🍃인증 정보 포함 요청 예시

GET /api/secure-resource HTTP/1.1
# HTTP GET 요청으로 api.example.com 서버의 /api/secure-resource 경로에 리소스를 요청

Host: api.example.com
# 요청을 받는 서버의 호스트명 (api.example.com)

Origin: https://aaa.com
# 요청을 보낸 출처의 도메인 (https://aaa.com)
# 서버가 이 출처에서의 요청을 허용할지 확인하기 위해 포함

Cookie: session_id=abc123
# 클라이언트가 인증 정보를 포함한 요청을 보냄 (여기서는 쿠키 "session_id=abc123")
# 로그인 세션이나 사용자 식별을 위해 서버에 쿠키를 전송

🍃서버의 응답 헤더:

HTTP/1.1 200 OK
# 서버가 요청을 성공적으로 처리했음을 나타내는 상태 코드 200

Access-Control-Allow-Origin: https://aaa.com
# 서버가 이 요청 출처 (https://aaa.com)를 허용한다는 것을 명시
# 인증 정보 요청 시, 반드시 특정 출처만 지정해야 하며, * 와일드카드를 사용할 수 없음

Access-Control-Allow-Credentials: true
# 클라이언트가 인증 정보를 포함한 요청을 허용하도록 설정
# 브라우저는 이 헤더가 포함되어 있어야 쿠키나 세션 정보를 사용할 수 있음

---

이러한 CORS 요청 유형을 통해, 웹 애플리케이션은 보안적으로 안전하게 다른 출처의 리소스에 접근할 수 있습니다.

더 자세한 내용이 알고 싶다면 !!
+++ 와인잔조 5죠원들과의 코드토크 내용을 참조하여 작성했습니다 ㅎㅎ
https://developer.mozilla.org/ko/docs/Web/HTTP/CORS