Cross-Origin Resource Sharing (CORS) 완벽 정리

한 번쯤은 마주치게 되는 CORS 에러를 해결해보자

2024.10.11

10분 소요

글을 시작하며

웹 개발을 하다 보면 한 번쯤은 마주치게 되는 악명 높은 CORS 에러. 특히 프론트엔드 개발자라면 더더욱 친숙한 이 에러는 때로는 개발을 막막하게 만들기도 합니다.
아래와 같은 메시지를 본 적이 있으신가요?

"Access to XMLHttpRequest at 'http://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy"

오늘은 CORS가 무엇인지, 왜 발생하는지, 그리고 어떻게 해결할 수 있는지 자세히 알아보겠습니다.

CORS란 무엇인가?

CORS(Cross-Origin Resource Sharing)는 웹 브라우저에서 외부 도메인 자원을 요청할 때 필요한 보안 정책입니다. 쉽게 말해, 브라우저가 서로 다른 출처(origin)의 리소스를 요청할 때 발생하는 보안 정책입니다.
여기서 말하는 출처는 프로토콜, 호스트, 포트 번호를 의미하며, 이 중 하나라도 다르면 CORS 에러를 만나게 됩니다.

Origin이란?

Origin은 다음 세 가지 요소

  • 프로토콜 (http, https)
  • 호스트 (domain)
  • 포트 번호
https://www.example.com:443
└─┬─┘ └──────┬───────┘ └─┬─┘
프로토콜   호스트       포트

기본적으로 브라우저는 보안상의 이유로 다른 출처에서 리소스를 요청하는 것을 차단합니다. 이를 동일 출처 정책(Same-Origin Policy, SOP)이라고 합니다.

‘출처가 교차한다’는 건 리소스를 주고받으려는 ‘두 출처가 서로 다르다’는 뜻이고, CORS를 설정한다는 건 ‘출처가 다른 서버 간의 리소스 공유’를 허용한다는 뜻입니다.

위에서 SOP가 서로 다른 출처일 때 리소스 요청과 응답을 차단하는 정책이라면, CORS는 반대로 서로 다른 출처라도 리소스 요청, 응답을 허용할 수 있도록 하는 정책입니다.

따라서 우리가 만나는 에러는 CORS가 가능하도록 설정을 하라는 의미입니다.

CORS 에러 대응하기

서버에서 Access-Control-Allow-Origin 응답 헤더 세팅하기

서버에서 Access-Control-Allow-Origin 헤더를 설정해서 요청을 수락할 출처를 명시적으로 지정할 수 있습니다. 이 헤더를 세팅하면 출처가 다르더라도 리소스 요청을 허용하게 됩니다.

'Access-Control-Allow-Origin': <origin> | *

*(와일드카드)를 설정하면 출처에 상관없이 리소스에 접근할 수 있으므로 보안에 취약할 수 있습니다. 따라서 Access-Control-Allow-Origin: https://example.com와 같이 직접 허용할 출처를 세팅하는 방법이 더 좋습니다.

프록시 서버 사용하기

웹 애플리케이션이 리소스를 직접적으로 요청하는 대신, 프록시 서버를 사용하여 웹 애플리케이션에서 리소스로의 요청을 전달하는 방법입니다. 이 방법을 사용하면, 웹 애플리케이션이 리소스와 동일한 출처에서 요청을 보내는 것처럼 보이므로 CORS 에러를 방지할 수 있습니디.

결론

CORS는 웹 보안을 위한 중요한 메커니즘이지만, 개발 과정에서 종종 골치 아픈 문제를 일으킵니다. 하지만 CORS의 동작 원리와 해결 방법을 제대로 이해하면, 더 이상 두려운 대상이 아닙니다.

개발 중에는 편의를 위해 느슨한 설정을 사용할 수 있지만, 프로덕션 환경에서는 반드시 필요한 origin만 허용하도록 설정해야 합니다. 또한 CORS는 프론트엔드와 백엔드가 함께 해결해야 하는 문제라는 점을 기억해야 합니다. 양쪽 모두의 올바른 설정이 있어야 안전하고 효율적인 리소스 공유가 가능합니다.

이제 CORS 오류가 발생해도 당황하지 말고 해결해 보세요! 🚀

CORSCross-Origin Resource SharingSOPSame-Origin Policy