개요

Access-Control-Allow-Headers는 CORS 프리플라이트 응답에서, 교차 오리진 실제 요청이 보낼 수 있는 커스텀·비단순 요청 헤더 목록을 알리는 헤더입니다. 여기 허용되지 않은 헤더를 실제 요청에 넣으면 브라우저가 차단합니다.

값은 허용 헤더 이름을 콤마로 나열하며, 비자격증명 요청에 한해 *를 쓸 수 있습니다.

자세히

Authorization·Content-Type: application/json·X-Requested-With 같은 커스텀/비단순 헤더를 교차 오리진 요청에 넣으려면 브라우저가 프리플라이트에서 Access-Control-Request-Headers로 먼저 알립니다. 서버는 그중 허용할 헤더를 Access-Control-Allow-Headers로 답해야, 브라우저가 실제 요청에 그 헤더를 실어 보냅니다.

*는 모든 헤더를 허용하지만 credentials 모드에서는 무효이며, 특히 와일드카드는 Authorization 헤더를 포함하지 않으므로(브라우저에 따라) 인증 헤더가 필요하면 명시적으로 나열하는 것이 안전합니다.

이 헤더는 요청이 보내는 헤더를 통제하는 반면, 응답에서 스크립트가 읽을 수 있는 헤더를 노출하는 것은 Access-Control-Expose-Headers입니다. 방향이 반대이니 혼동하지 마세요.

문법

Access-Control-Allow-Headers: <header>[, <header>]* | *

e.g. Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

실무 참고

• 가장 흔한 CORS 오류: 클라이언트가 Authorization이나 커스텀 헤더를 보내는데 서버가 Access-Control-Allow-Headers에 그 헤더를 넣지 않아 프리플라이트가 실패하는 경우입니다.
• 헤더 이름은 대소문자를 구분하지 않지만, 요청이 보내려는 이름과 정확히 대응되게 나열하세요. 클라이언트 라이브러리가 자동으로 추가하는 헤더(X-Requested-With 등)도 빠뜨리지 마세요.
• 이 헤더도 프리플라이트(OPTIONS) 응답에만 붙습니다. 실제 응답에 넣을 필요는 없습니다.

관련 헤더

관련 상태코드

스펙 근거