프론트를 괴롭히는 CORS, 왜 일어나는걸까?

 

상황 가정

• 나의 앱 주소: https://myapp.com
• API 주소: https://api.other.com

→ 서로 도메인(other.com vs myapp.com)이 다르다 = "Cross-Origin" 요청

 

1. 앱이 API 요청을 보냄

fetch("https://api.other.com/data")

 

2. 브라우저가 "잠깐, 도메인이 다르네?"

"내가 이걸 보내긴 보내는데, 상대방 서버가 진짜 허용했는지 확인하고 올게."

 

그래서 먼저 요청을 보냄 (간단한 요청이면 그냥 보내고, 복잡하면 OPTIONS 요청으로 먼저 물어봄 → 이걸 preflight 이라고 함)

 

📍 CORS Preflight Request (OPTIONS 요청)을 하는 조건!

조건	예시
메서드가 GET, POST, HEAD 이외	PUT, DELETE, PATCH 등
헤더에 Content-Type: application/json 같이 특별한 거 있음	(ex. 로그인 시)
Authorization 헤더 같이 민감한 헤더 있음	(ex. JWT)

 

3. 서버가 응답을 줌

HTTP/1.1 200 OK
Content-Type: application/json

 

🙅 문제: 응답 헤더에 “너 이 응답 써도 돼”라고 허락하는 표시 가 없음

Access-Control-Allow-Origin: https://myapp.com

 

4. 브라우저가 응답을 받고 이렇게 말함:

“야, 저 서버가 ‘너(myapp.com) 써도 된다고 안 했어’
그러니까 나는 이 응답을 네 앱에 못 넘겨줘. 그냥 막을게. 🔒” 

 

그래서 콘솔에 이런 에러가 뜬다.

Access to fetch at 'https://api.other.com/data' from origin 'https://myapp.com' has been blocked by CORS policy

 

 

핵심 요약

• 요청은 정상적으로 서버까지 감 → 응답도 내려옴
• 브라우저가 응답 내용 보려고 확인하는데
  • 헤더에 “얘 써도 돼”(Access-Control-Allow-Origin)가 없음
• 그래서 브라우저가 차단함 (JS 코드에선 못 씀)

 

🎯 해결하려면?

서버에서 아래 헤더를 반드시 내려줘야 한다.

Access-Control-Allow-Origin: https://myapp.com

 

또는 모든 데서 쓰게 하려면 이렇게 

Access-Control-Allow-Origin: *

 

 

 

 

 

( + 나의 궁금증 )

근데 왜 서버가 "써도 돼"라고 말해줘야 할까?

 

1. 브라우저는 자기가 취약하다는 걸 알고 있음
2. 그래서 기본적으로 Same-Origin Policy(같은 출처 정책)으로 보호하려고 함
3. 하지만 요즘은 백엔드와 프론트엔드를 분리해서 개발하니까
   • 이 정책만으론 유연한 통신이 안 됨
4. 그래서 나온 게 CORS
   • 서버가 어떤 출처(origin)에서 온 요청을 허용할지 명시하는 방식
5. 브라우저는 그 명시를 보고 판단해서
   • 응답을 받아도 JS 코드에게는 안 넘겨줄 수 있음 → 사용자가 의도하지 않은 데이터 유출을 막음

 

 

 CORS가 막을 수 있는 것

막을 수 있는 것	설명
✅ 악의적인 외부 사이트	예: badguy.com이 너 대신 API 요청해서 응답을 탈취하려 할 때
✅ 브라우저에서 실행되는 JS 코드	브라우저만 CORS를 검사하니까
✅ Origin이 다른 경우	https://notmyapp.com에서 https://api.myapp.com으로 요청 시

 

 CORS가 막을 수 없는 것

못 막는 것	이유
❌ 같은 origin에서 실행 중인 악성 JS	CORS는 origin만 보지, 코드의 선악은 판단 못함
❌ Postman, curl, 모바일 앱	브라우저에서만 동작함 (서버에서 막아야 함)
❌ XSS로 삽입된 코드	브라우저 입장에선 "같은 출처"니까 CORS 검사 안 함
❌ 정상 유저가 인증된 상태에서 발생하는 오용	권한 검증은 서버 로직이 해야 함

 

CORS는 서버를 보호하는 게 아니라,
악의적인 웹사이트들이 “브라우저를 통해” API를 몰래 호출하는 걸 막는 브라우저 보안 장치다.

 

진짜 서버 보안은? ( 추가로 공부해야할 것들....)

• 인증 & 권한 검증 (JWT, 세션, Role check)
• XSS 방지 (Content-Security-Policy, input escape)
• CSRF 방지 (SameSite=Lax or token)
• Origin/IP 필터링
• Rate limiting