클라이언트에서 AWS S3 데이터에 접근하는 도중 CORS 에러를 마주하게 됐다.
버킷-권한-CORS 설정을 작성해서 문제를 해결했다. 이번 기회에 CORS에 대한 개념을 정리하고자 한다.

CORS(Cross-Origin Resource Sharing)란?

교차 출처 자원 공유

말이 어렵지만 쉽게 말해서 다른 Origin(출처)에서 데이터 교환을 가능하게 하는 것이다.
CORS 에러는 요청 받은 Origin의 서버에서 요청을 허용하지 않은 경우 발생한다.

Origin이란?

URL의 구성 요소인 프로토콜, 도메인, 포트 번호를 포함한 주소

URL: https://www.example.com:8000

• 프로토콜 = https
• 도메인 = www.example.com
• 포트 번호 = 8000

즉, Origin = 포로토콜 + 도메인 + 포트 번호

SOP(Same-Origin Policy)와 CORS

동일 출처 정책

자신과 동일한 Origin(출처)에서 로드된 리소스에만 접근할 수 있는 정책
웹 브라우저의 기본 보안 모델로서 악의적인 리소스 접근을 방지합니다.
그러나 다른 출처와의 데이터 공유가 필요해짐에 따라 SOP 정책을 완화한 게 CORS이다.

정리하자면,
SOP = A Origin에서는 같은 A Origin과 데이터를 교환한다.
CORS = A Origin에서 B Origin과 데이터를 교환한다.

서버 측에서의 CORS 설정

HTTP 응답 헤더를 서버 측에서는 특정 Origin(출처)에 대한 요청을 허용하도록 구성할 수 있다.
일반적으로 서버의 응답 헤더에 Access-Control-Allow-Origin이라는 헤더를 추가해서 허용된 Origin을 명시한다.

예를 들어

Access-Control-Allow-Origin: https://www.allowed-origin.com

이렇게 명시하면 서버는 https://www.allowed-origin.com이라는 Origin의 CORS를 허용하게 된다.
*(와일드카드)를 사용하면 모든 Origin를 허용한다는 뜻이다.

Django 에서는 django-cors-headers 라이브러리를 사용해서 설정할 수 있고
AWS S3에서는 버킷 정책에서 CORS를 설정할 수 있다.
각 언어, 프레임워크에 맞게 CORS를 설정하자.

CORS 관련 헤더

추가적으로 Access-Control-Allow-Origin뿐만 아니라 CORS 관련 헤더를 사용하여 통신을 세밀하게 제어할 수 있다.

• Access-Control-Allow-Methods: 허용하는 HTTP 메서드를 지정한다.
• Access-Control-Allow-Headers: 허용하는 요청 헤더를 지정한다.
• Access-Control-Allow-Credentials: 인증된 사용자 요청을 허용할지 여부를 지정한다.
• Access-Control-Expose-Headers: 브라우저가 액세스할 수 있는 응답 헤더를 지정한다.

  ---

클라이언트 측에서의 CORS 처리

서버에서 허용 했는지 안 했는지에 따라 CORS가 처리되기에 클라이언트에서 따로 뭔가를 할 필요는 없다.
기본적으로 웹 브라우저에서 기본적으로 CORS 정책이 자동으로 적용되기 때문이다.

그러나 CORS 관련 특정 요청을 보내거나 응답을 처리해야 할 때, Fetch API를 사용해서 처리할 수 있다.
추가적으로 브라우저에서는 CORS 확인을 위해 Preflight 요청을 보내기도 합니다.

Preflight 요청

실제 요청을 보내기 전, 서버에서 해당 요청을 허용하는지 확인을 위한 사전 요청(HTTP)

OPTIONS 메서드를 사용한다.
사전에 CORS를 준수하는지 확인하기 때문에 불필요한 리소스 낭비를 줄일 수 있다.

🙄 P.S.

CORS 구성에서 *(와일드카드)는 보안상 문제가 될 수 있기에 신중하게 사용해야 한다.
CORS 에러 어려울 거 하나 없다.

🙇🏻‍ 잘못된 정보는 댓글을 통해 알려주시면 감사하겠습니다.