CORS-safelisted Request

Simple request는 응답 허가가 아니라 preflight를 생략하는 조건이다

메서드, 요청 헤더 이름과 값, body 특성이 safelist에 들어오면 브라우저는 OPTIONS 확인 없이 actual request를 보낼 수 있다. 그래도 응답을 JavaScript가 읽으려면 실제 응답의 CORS 허가가 필요하다.

1. method GET / HEAD / POST PUT, PATCH, DELETE 등은 preflight 대상이 된다.
2. request headers Safelisted 이름과 값 값 길이, unsafe byte, 언어 헤더 문자 제한까지 만족해야 한다.
3. body features 특수 upload 기능 없음 XHR upload listener나 ReadableStream body는 preflight 조건을 만들 수 있다.
method OK header safelist body safe 모두 통과하면 preflight 생략 하나라도 벗어나면 OPTIONS 먼저
header names CORS-safelisted request headers
Accept Accept-Language Content-Language Content-Type Range
Content-Type MIME essence 기준 3종
application/x-www-form-urlencoded multipart/form-data text/plain
text/plain;charset=UTF-8처럼 parameter가 붙어도 essence가 기준이다.
Range 단일 byte range만 safelisted Range: bytes=0-499처럼 한 구간이어야 한다.
value limits 값 제한도 통과해야 함 헤더 값은 128바이트 이하이고, 일부 unsafe byte와 언어 헤더 문자 제한이 적용된다.
preflight
Authorization 직접 붙이면 safelist 밖이다. preflight 응답의 Access-Control-Allow-Headers: Authorization이 필요하다.
preflight
application/json JSON POST는 safelisted Content-Type이 아니므로 OPTIONS 확인이 먼저 필요하다.
credentials
쿠키 포함은 preflight 조건 자체가 아님 하지만 응답 공유에는 명시 origin과 Access-Control-Allow-Credentials: true가 필요하고 wildcard origin은 실패한다.
actual
simple이어도 ACAO 필요 실제 요청은 바로 갈 수 있지만, 응답에 적절한 Access-Control-Allow-Origin이 없으면 JS는 읽지 못한다.

정리: simple request는 "서버가 아무 허가 없이 응답을 공유한다"는 뜻이 아니다. 브라우저가 preflight를 생략할 뿐이며, CORS 응답 헤더 판정과 CSRF 방어는 여전히 별개로 설계해야 한다.