참조
웹 개발을 하다 보면, 한 번쯤은 다음과 같은 에러를 마주하게 된다.
⚠️ “Access to fetch at … has been blocked by CORS policy”
이 글에서는 CORS가 무엇인지, 왜 필요한지, 그리고 실제로 어떻게 동작하는지를 정리한다.
1. CORS란?
📚 CORS(Cross-Origin Resource Sharing) 는
서로 다른 출처(origin) 간의 리소스 요청을 브라우저가 제어하기 위한 보안 정책이다.
웹 브라우저는 기본적으로 같은 출처(Same-Origin)에서만 서버 응답을 사용할 수 있도록 제한한다.
- CORS는 이 제한을 서버의 명시적인 허용 하에 완화하는 메커니즘이다.
2. Origin(출처)이란?
브라우저에서 말하는 origin은 다음 세 요소의 조합이다.
1. 프로토콜 (http/https)
2. 도메인
3. 포트번호
예시:
http://localhost:3000http://localhost:8000
→ 포트가 다르므로 서로 다른 origin(출처)
3. 왜 CORS가 필요한가?
CORS의 근본적인 배경은 Same-Origin Policy(SOP)이다.
🎯 Same-Origin Policy는 다음과 같은 공격을 방지하기 위해 존재한다.
- 악성 사이트가 사용자의 인증 정보를 이용해 → 다른 사이트의 민감한 API를 몰래 호출하는 행위
🎯 따라서 브라우저는 기본적으로:
- 다른 origin으로 요청을 보내는 것은 허용
- 응답을 JS에서 읽는 것은 차단
✨ 이때 서버가 "이 요청은 안전하다"고 명시적으로 알려주면, 브라우저가 응답 사용을 허용한다.
이 규칙이 바로 CORS이다.
4. CORS는 누가 제어하는가?
중요한 것은 다음이다.
- ❌ 프론트엔드가 허용 여부를 정하지 않는다
- ✅ 서버가 허용 여부를 응답 헤더로 선언한다
- ❌ 서버 에러가 아니다
- ✅ 브라우저 단에서 발생하는 보안 차단
5. CORS 관련 주요 HTTP 헤더
서버 응답에 포함되는 대표적인 헤더는 다음과 같다.
1️⃣ Access-Control-Allow-Origin
- 허용할 origin 지정
- 예:
http://localhost:3000*(모든 origin 허용): ⚠️ 모든 웹사이트에 API를 공개하는 것과 같다
🤓 언제 *를 써도 되는가?
→ 다음 조건을 모두 만족할 때만 고려할 수 있다: 인증 정보가 전혀 없는 API & 공개되어도 문제없는 데이터
(예: 공공 데이터, 상태 체크, 단순 헬스 API)
2️⃣ Access-Control-Allow-Methods
- 허용할 HTTP 메서드
- 예:
GET, PUT, POST, DELETE
3️⃣ Access-Control-Allow-Headers
- 허용할 요청 헤더
- 예:
Content-Type, Authorization
6. Preflight 요청이란?
일부 요청은 실제 요청 전에 사전 확인 요청을 수행한다.
이를 Preflight 요청이라고 한다.
🎮 Preflight가 발생하는 경우
POST,PUT,DELETE요청Content-Type: application/jsonAuthorization헤더 사용- 커스텀 헤더 포함
🧑💻 동작 과정
- 브라우저 → OPTIONS 요청 전송
- 서버 → CORS 허용 헤더 응답
- 허용되면 실제 요청 전송
- 허용되지 않으면 브라우저가 차단
7. 자주 하는 오해
⚙️ 1) “서버는 정상인데 프론트에서만 에러 난다”
- 정상적인 상황이다.
- CORS는 브라우저 보안 정책이다.
⚙️ 2) “Postman에서는 되는데 브라우저에서는 안 된다”
- Postman은 브라우저가 아니므로 CORS 검사를 하지 않는다.
⚙️ 3) “CORS 에러 = 서버 에러”
- 아니다.
- 서버 응답은 정상이어도 브라우저가 응답을 폐기한다.
CORS는 브라우저가 다른 출처의 서버 응답을 사용해도 되는지를 서버의 허가를 통해 판단하는 보안 정책이다.
