CORS 헤더 & CDN 캐시 설정 자동 생성기

CORS 오류를 재현하고 확인하는 순서

예를 들어 프론트엔드가 https://app.example.com, API가 https://api.example.com이면 Allowed Origins에는 프론트엔드의 출처를 넣습니다. 경로가 포함된 /login 주소가 아니라 프로토콜·호스트·포트 조합입니다.

브라우저 개발자 도구에서 실패한 요청과 OPTIONS 요청을 찾습니다.
요청의 Origin과 응답의 Access-Control-Allow-Origin이 일치하는지 확인합니다.
JSON POST 또는 Authorization 같은 비단순 헤더를 쓰면 사전 요청이 필요할 수 있습니다. 필요한 메서드와 헤더가 모두 허용되는지 확인합니다.
쿠키를 사용하면 클라이언트의 credentials, 서버의 Allow-Credentials, 쿠키의 SameSite·Secure 설정을 함께 확인합니다.

Origin을 허용해도 로그인 인증이나 권한 검사는 따로 필요합니다. CORS는 브라우저의 응답 읽기 규칙이며 서버 접근 제어나 CSRF 방어를 대신하지 않습니다.

캐시 정책 선택 예제

로그인 후 내 정보: 인증 쿠키 사용 + no-store. 사용자마다 다른 응답을 public 캐시로 공유하지 않습니다.
모든 사용자에게 같은 카테고리: 쿠키 없음 + public 1시간. 갱신 주기와 캐시 무효화 방법을 먼저 정합니다.
Origin별 다른 응답: Vary: Origin을 유지하고 CDN이 이를 어떻게 처리하는지 확인합니다.

no-cache는 저장 금지가 아니라 재사용 전 재검증입니다. 저장하지 않으려면 no-store를 사용합니다. Max-Age는 사전 요청의 캐시 시간이며 브라우저가 적용하는 상한은 다를 수 있습니다.

프레임워크별 적용 범위

Express와 FastAPI

출력은 애플리케이션에 넣을 미들웨어 예제입니다. 이미 있는 앱 인스턴스에 통합하고 동일한 CORS 미들웨어를 두 번 등록하지 마세요. 캐시 미들웨어는 적용되는 모든 응답에 영향을 주므로 로그인 응답과 공용 응답을 라우터 단위로 분리하는 것이 좋습니다.

PHP와 Nginx

PHP는 허용 목록과 요청 Origin을 비교하여 하나의 Origin만 응답합니다. Nginx는 map을 http 문맥에, 나머지 지시어를 대상 location에 배치합니다. 기존 location 블록에 중복 헤더가 없는지 확인하고 nginx -t로 문법을 검사하세요.

왜 생성이 중단되나요?

*와 인증 쿠키의 조합, Origin에 경로·자격증명·줄바꿈이 포함된 경우, 인증 쿠키와 public 캐시를 동시에 선택한 경우에는 잘못된 예제를 복사하지 않도록 출력을 비웁니다. 여러 Origin은 쉼표로 구분하며 요청 헤더 이름에는 값이 아닌 이름만 입력하세요.

설정은 브라우저에서 생성하며 서버에 적용하지 않습니다. 광고 서비스는 별도 외부 요청을 사용할 수 있습니다. MDN CORS 안내 · 오류 제보