CORS preflight

브라우저는 실제 요청 전에 method와 header 허용 범위를 먼저 묻는다

safelisted 조건을 벗어난 CORS 요청은 OPTIONS 왕복을 먼저 수행한다. 서버가 허용 범위를 명확히 답해야 실제 GET/POST/PUT 요청이 이어진다.

01

OPTIONS probe

브라우저가 Origin, 요청 method, 요청 header 목록을 먼저 보낸다.

02

server allow list

서버는 허용 origin, methods, headers를 응답 헤더로 명시한다.

03

Max-Age cache

브라우저는 허용 결과를 잠시 캐시할 수 있지만 구현별 상한이 있다.

04

actual request

허용되면 실제 요청을 보내고, 응답 노출 여부는 다시 CORS 헤더로 판단한다. 

OPTIONS /orders
Origin: https://app.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization
Allow-Methods

실제 요청 method 허용

POST를 보내려면 preflight 응답에 POST가 포함되어야 한다.

Allow-Headers

요청 header 이름 허용

Authorization을 쓰면 서버가 그 이름을 명시해야 한다.

browser gate

실패하면 실제 요청 중단

서버 간 통신 차단이 아니라 브라우저가 JavaScript 노출을 막는 규칙이다.

preflight 반복은 서버 성능보다 정책 명확성 문제로 먼저 본다

Max-Age를 늘리기 전에 허용 origin, method, header가 과하게 넓지 않은지 확인해야 한다. Authorization을 붙인 요청은 CSRF와 별도로 토큰 노출, Origin 검증, credentials 정책을 함께 봐야 한다.