[CORS] 내 요청은 왜 차단될까?

이번 달에 진행한 프로젝트를 Glitch를 이용해서 배포했습니다.
한 번에 프론트와 API 연동이 되면 좋았겠지만 혼란스럽게도 CORS 에러가 발생했습니다.
오늘은 CORS가 무엇이고 왜 중요한지, 그리고 이것을 어떻게 해결했는지 알아보겠습니다.

---

1. Origin이란 무엇인가?

CORS를 이해하려면 먼저 Origin의 개념부터 알아야 합니다.
웹에서 Origin은 세 가지 요소로 구성됩니다.

• 프로토콜(http, https)
• 호스트(도메인 이름)
• 포트 번호

같은 Origin인지 판단하려면 이 세 가지가 모두 같아야 합니다.
예를 들어:

• https://example.com:3000
• http://example.com:3000

위 두 URL은 프로토콜이 다르기 때문에 서로 다른 Origin으로 간주됩니다.

 

2. CORS는 왜 사용하는가?

웹은 기본적으로 보안을 위해 동일 출처 정책을 따릅니다.
이는 한 Origin에서 다른 Origin의 리소스에 접근하지 못하도록 막는 것입니다.

하지만, 현대의 웹은 API 호출이나 리소스 공유가 필수적입니다.
이를 가능하게 하는 것이 바로 CORS입니다.
CORS는 보안을 유지하면서도 필요한 경우에 한해 특정 출처의 요청을 허용할 수 있도록 해줍니다.

 

3. CORS 정책의 주요 요소

3.1 헤더

CORS는 HTTP 헤더를 통해 작동합니다.
주요 헤더는 다음과 같습니다.

• Access-Control-Allow-Origin: 요청을 허용할 출처를 지정합니다.
• Access-Control-Allow-Methods: 허용할 HTTP 메서드를 지정합니다.
• Access-Control-Allow-Headers: 클라이언트가 사용할 수 있는 추가 헤더를 지정합니다.

3.2 Credentials

API 요청에서 쿠키나 인증 정보를 포함하려면 Access-Control-Allow-Credentials를 true로 설정해야 합니다.
그러나 이 경우 Access-Control-Allow-Origin에 *를 사용할 수 없다는 점을 주의해야 합니다.

3.3 Preflight 요청

CORS는 보안을 위해 사전 요청을 보내는 경우가 있습니다.
이는 브라우저가 서버에 요청을 보내기 전에, 이 요청이 허용될지를 확인하는 과정입니다.

 

4. CORS는 어떻게 동작하는가?

CORS의 요청은 아래와 같은 순서로 동작합니다.

1. 브라우저에 요청을 보냅니다.
   • 단순 요청인지 사전 요청이 필요한지 판단합니다.
2. 서버가 요청 헤더를 확인하고, CORS 정책에 따라 응답합니다.
3. 브라우저는 요청을 검토하고, 요청이 허용되었는지 확인합니다.

CORS 요청 순서

---

CORS는 처음에는 복잡하고 번거롭게 느껴졌지만, 웹 보안과 API 통합에 있어 얼마나 중요한지 알게 되었습니다.
특히, 사전 요청의 개념이나 크레덴셜 처리와 같은 세부적인 사항을 배우면서 서버와 클라이언트 간의 협력 방식에 대한 이해가 깊어졌습니다.

글을 끝까지 읽어주셔서 감사합니다.
틀린 내용이 있다면 댓글로 지적 부탁드립니다.