본문으로 건너뛰기
AZ Tools

CORS 헤더 빌더

Access-Control-* 응답 헤더 체크리스트 구성, 4 프리셋·위험한 조합 실시간 경고.

프리셋
Allow-Methods
응답 헤더
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 600
Vary: Origin

preflight OPTIONS와 실제 요청 응답 모두에 적용. Origin 에코 시 엣지 캐시엔 Vary: Origin 필요.

사용법

  1. 시나리오에 맞는 프리셋에서 시작.
  2. 오리진 설정(완전 공개는 *, credential API는 서버 측에서 요청 Origin 에코).
  3. 엔드포인트가 실제 받는 메서드·헤더만 선택 — 좁을수록 안전.
  4. 서버·엣지 워커·프레임워크 미들웨어에 헤더 복사.

자세한 설명

펼치기

브라우저의 교차 출처 요청을 만족시키기 위해 서버가 보내야 할 응답 헤더를 만듭니다. Allow-Origin, Allow-Methods, Allow-Headers, Expose-Headers, Allow-Credentials, Max-Age와 Vary: Origin 안내를 포함합니다. 흔한 지뢰를 표시합니다. 자격 증명과 *를 함께 쓰는 것(브라우저가 막습니다), Origin: null을 받아들이는 것(공격자가 위장할 수 있습니다), 프리플라이트를 비상식적으로 오래 캐시하라고 요구하는 것입니다.

붙들고 있어야 할 사실은 CORS를 강제하는 주체가 서버가 아니라 브라우저라는 점입니다. 이 헤더들은 자원을 보호하지 않습니다. 다른 사이트에서 도는 스크립트에 브라우저가 걸어 두는 제약을 푸는 것일 뿐입니다. 브라우저가 아닌 것, 즉 curl이나 백엔드 서비스, 스크레이퍼는 이 헤더를 들여다보지도 않고 응답을 그대로 받습니다. 아무나 읽으면 안 되는 URL이라면 필요한 것은 더 좁은 Allow-Origin이 아니라 인증입니다.

Access-Control-Allow-Credentials: true는 *와 함께 쓸 수 없습니다. 브라우저가 그 조합을 아예 거부하므로, 교차 출처 요청에 쿠키를 싣고 싶은 서버는 요청한 출처를 그대로 되돌려 보내야 합니다. 되돌려 보낸다는 것은 응답이 요청마다 달라진다는 뜻이고, 그래서 Vary: Origin이 중요합니다. 이것이 없으면 공유 캐시가 한 출처를 위해 만든 응답을 저장했다가 다음 요청자에게 건네고, 그 응답에 실린 헤더는 엉뚱한 사이트를 가리키게 됩니다.

Origin: null은 와일드카드도 아니고 안전한 기본값도 아닙니다. 브라우저는 샌드박스된 iframe, file:// 문서, 일부 리다이렉트 이후에 이 값을 보내며, 어떤 페이지든 그런 상태에 놓이도록 만들 수 있습니다. 따라서 이것을 허용하는 것은 제한적으로 보이면서 실제로는 모두를 허용하는 것에 가깝습니다.

Max-Age는 설정이 아니라 요청입니다. 브라우저는 프리플라이트 결과를 얼마나 오래 재사용할지에 상한을 두는데, 상한은 브라우저마다 다르고 크롬에서는 하루에 한참 못 미칩니다. 그래서 86400 같은 값은 존중되는 대신 조용히 잘립니다. 이 헤더는 프리플라이트 자체만 관장하며, 뒤따르는 실제 요청은 따로 검사됩니다.

자주 묻는 질문

*와 credentials 같이 쓸 수 있음?

안 됨. fetch 스펙은 Access-Control-Allow-Origin: *와 Access-Control-Allow-Credentials: true 페어링한 응답 거부. credentials 빼거나, 허용 목록 검증 후 실제 요청 Origin을 서버 측에서 에코.

Vary: Origin 권장 이유?

Origin을 Allow-Origin에 에코하면, 하위 캐시는 저장된 응답을 요청의 Origin 헤더로 키잉해야 함; 아니면 한 사이트의 CORS 응답이 다른 사이트 요청에 서빙될 수 있음. Vary: Origin이 캐시에 해당 헤더로 키잉하라고 알림.

프리플라이트는 통과했는데 브라우저가 요청을 계속 막는다. 어디를 봐야 하나?

프리플라이트가 아니라 실제 응답을 봐야 한다. 둘 다 Access-Control-Allow-Origin을 달고 있어야 한다. 브라우저는 실제 응답을 다시 확인하고 헤더가 없으면 막는다. 프리플라이트는 프록시나 프레임워크가 처리하는데 정작 엔드포인트는 그러지 않을 때 흔히 생긴다. 또 하나 잦은 원인은 리디렉션이다. 프리플라이트에 대한 응답은 리디렉션하면 안 된다.

네트워크 패널에는 보이는 헤더를 페이지에서 못 읽는 이유는?

교차 출처 응답이 자바스크립트에 노출하는 것은 짧은 안전목록뿐이고, 그 밖의 것은 Access-Control-Expose-Headers에 이름을 적어야 하기 때문이다. 패널은 브라우저가 받은 것을 보여주고, 페이지는 CORS가 허락한 것만 본다. 페이지네이션 개수, 레이트 리밋 헤더, 요청 ID 모두 코드가 읽으려면 먼저 명시적으로 노출해야 한다.

관련 도구

HTTP 헤더 참조

표준 HTTP 요청·응답·CORS·캐싱·보안·쿠키 헤더 약 50개의 검색 가능한 참조.

개발

Referrer-Policy 헤더 빌더

Referrer-Policy 값 선택 → 송출 요청이 보낼 Referer 헤더 정확히 확인 — 동일 오리진, 크로스 오리진 HTTPS, HTTPS→HTTP 다운그레이드.

네트워크

Cache-Control 헤더 빌더

체크리스트로 HTTP Cache-Control 헤더 생성 — 프레시니스·재검증·immutable·자주 쓰는 프리셋.

네트워크

robots.txt 테스터

robots.txt와 (user-agent, 경로) 쌍 리스트 붙여넣기 → 어느 줄이 정확히 허용·차단하는지 — 최장 매치 우선·와일드카드·* 그룹 폴백.

네트워크

HTTP Basic 인증 인코더/디코더

username:password를 Base64 Authorization: Basic 헤더로 인코딩 — 또는 기존 헤더 붙여넣어 누군지 확인.

네트워크

URL 쿼리 빌더

base URL + 편집 가능한 key-value 쿼리 파라미터로 URL 조립 — 각 쌍 토글, 자동 percent 인코딩.

네트워크