브라우저가 왜 CORS 오류를 내는지를, 동일 출처 정책(SOP)의 보안 목적에서 역으로 풀어 설명한다. 출처의 정의부터 요청 종류별 흐름, 그리고 실무에서 문제를 푸는 방법까지 순서대로 짚는다.
핵심 포인트- 한 서버에서 처리하던 웹이 프런트엔드와 API 서버로 분리되며, 기본 차단인 SOP 위에 안전한 예외를 표현할 CORS가 필요해진 배경을 설명 — CORS는 다른 출처 자원 읽기를 서버가 허가하는 메커니즘
- 출처는 프로토콜·호스트·포트로 결정돼 하나라도 다르면 교차 출처가 되며, 로그인 쿠키를 가진 사용자가 악성 사이트 요청을 실행할 수 있어 브라우저가 기본적으로 교차 출처 읽기를 차단
- OPTIONS 예비 요청으로 허용 메서드·헤더를 확인하는 preflight와, GET·HEAD·POST에 제한된 헤더·콘텐츠 타입만 쓰는 simple request를 비교(JSON API가 흔한 현대 웹은 simple 조건 충족이 어려움), 쿠키를 보내려면 클라이언트 credentials + 서버 Access-Control-Allow-Credentials가 필요하고 이때 Allow-Origin은 와일드카드 불가
- 같은 출처의 프록시를 거쳐 서버 간 통신으로 우회하거나 대상 서버가 Access-Control-Allow-* 헤더를 올바르게 반환하는 두 해법을 비교 — 배포 도메인을 정확히 공유하는 프런트·백엔드 협업이 핵심
왜 읽나CORS 오류에 반복해서 막히는 프런트엔드·백엔드 개발자에게 SOP의 원리부터 요청 유형·해결책까지 원인 중심으로 정리해주는 10분 톡.