네트워크
CORS
브라우저 동일 출처 정책과 그 우회 메커니즘. preflight와 헤더 협상.
- 초기
- Preflight 요청
- Preflight 응답
- 본 요청
- 응답
브라우저 / SPAapp.example.com
(요청 시도 전)
API 서버api.other.com
프론트엔드 https://app.example.com이 API https://api.other.com에 POST 요청을 보내려 합니다. 출처(origin)가 다르므로 브라우저가 CORS 정책을 검사합니다.
핵심 개념
동일 출처 정책 (SOP)
브라우저가 다른 출처(scheme + host + port)의 리소스를 스크립트로 접근 못하게 막는 보안 정책.
Preflight (OPTIONS)
GET/HEAD/POST의 단순 요청이 아닌 경우, 본 요청 전에 OPTIONS로 서버 허용 여부 확인.
주요 응답 헤더
Access-Control-Allow-Origin/Methods/Headers/Credentials. 브라우저가 응답을 받아도 헤더 없으면 차단.
credentials: include
쿠키를 함께 보내려면 클라이언트는 credentials, 서버는 Allow-Credentials=true + 명시적 Origin 필요.
면접 단골 질문
- Q1.CORS가 정확히 무엇을 막는 것인가요? 서버 요청을 막는 게 아니라는데 무슨 뜻인가요?
- Q2.Preflight 요청이 발생하는 조건은?
- Q3.Allow-Origin을 `*`로 설정해도 되는 경우와 안 되는 경우는?
- Q4.쿠키 인증을 쓰는 SPA에서 CORS는 어떻게 설정하나요?
- Q5.CORS 에러가 났을 때 서버/클라이언트 중 어디를 고쳐야 하는지 어떻게 판단하나요?