CORS 테스터

다음

CORS 오류는 브라우저 콘솔의 “고전적인” 빨간 글씨입니다: 다른 출처의 API를 호출하면 브라우저가 응답을 차단합니다. 이 테스터는 붙여넣은 어떤 URL에든 선택한 출처와 메서드로 프리플라이트 OPTIONS 요청을 보낸 뒤 Access-Control-* 헤더를 해독해, 서버가 정확히 무엇을 허용하고 무엇을 차단하는지, 그리고 브라우저가 왜 불평하는지 보여줍니다.

CORS 테스트 방법

  1. 1

    대상 URL 입력

    프런트엔드에서 호출하려는 API 엔드포인트. 쿼리 문자열과 프로토콜을 포함하세요.

  2. 2

    메서드와 출처 설정

    GET/POST/PUT/DELETE/PATCH. 출처는 사이트 URL이거나 시뮬레이션하려는 임의의 출처일 수 있습니다.

  3. 3

    프리플라이트 이해하기

    테스터는 선택한 출처와 메서드에 Access-Control-Request-Headers: Content-Type 헤더를 더한 OPTIONS 요청을 항상 보냅니다. 브라우저가 JSON 요청 전에 보내는 프리플라이트와 똑같습니다.

  4. 4

    테스트 실행

    테스터는 프리플라이트를 보낸 뒤 HTTP 상태와 CORS 응답 헤더(Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials, Max-Age)를 보고합니다.

  5. 5

    잘못된 설정 수정

    보고서가 무엇이 누락되었거나 잘못되었는지 표시합니다: 누락된 Allow-Origin, 금지된 헤더, 허용되지 않은 메서드.

중요한 헤더

헤더 역할
Access-Control-Allow-Origin 어떤 출처가 응답을 읽을 수 있는지
Access-Control-Allow-Methods 프리플라이트: 어떤 메서드가 허용되는지
Access-Control-Allow-Headers 프리플라이트: 어떤 요청 헤더가 허용되는지
Access-Control-Allow-Credentials 쿠키/인증이 허용되는지
Access-Control-Expose-Headers JS가 읽을 수 있는 응답 헤더
Access-Control-Max-Age 프리플라이트 결과가 얼마나 캐시되는지

단순 요청 대 프리플라이트 요청

요청은 다음이 모두 참일 때만 “단순”합니다(프리플라이트 없음):

  • 메서드가 GET, HEAD 또는 POST.
  • 헤더가 Accept, Accept-Language, Content-Language, Content-Type(특정 값)으로 제한됨.
  • Content-Type이 있다면 application/x-www-form-urlencoded, multipart/form-data, 또는 text/plain.

그 외 무엇이든, JSON 본문, Authorization 헤더, 커스텀 X-Foo 헤더, PUT/DELETE/PATCH, 는 프리플라이트 OPTIONS를 유발합니다. 서버는 올바른 Allow-* 헤더로 프리플라이트에 응답해야 하며, 그렇지 않으면 실제 요청은 결코 발사되지 않습니다.

흔한 CORS 실패

  • “No Access-Control-Allow-Origin header” → 서버가 헤더를 설정하지 않음. 클라이언트가 아니라 서버에서 고치세요.
  • “Credentials mode requires Allow-Origin not to be *” → 쿠키를 보내면 Allow-Origin은 특정 출처여야 합니다(또는 Origin 헤더를 되돌려줌).
  • “Request header X not allowed” → 프리플라이트 응답의 Access-Control-Allow-Headers에 X를 추가하세요.
  • “Method not allowed”Access-Control-Allow-Methods에 메서드를 추가하세요.
  • “Redirect not allowed in preflight” → 프리플라이트는 리다이렉트를 따라갈 수 없습니다. OPTIONS 엔드포인트가 직접 응답해야 합니다.

Allow-Origin: * 대 Origin 되돌려주기

Access-Control-Allow-Origin: *는 관대하지만 자격 증명과 결합할 수 없습니다. 프로덕션에서는 요청 Origin을 (허용 목록과 대조해 검증한 뒤) 되돌려주고, 쿠키가 필요하면 Allow-Credentials: true를 설정하세요.

우회책으로서의 프록시

서버를 제어할 수 없다면 자기 도메인의 얇은 프록시가 CORS를 완전히 벗겨냅니다, 브라우저는 동일 출처로 봅니다. 많은 호스팅 플랫폼(Vercel, Netlify, Cloudflare)이 바로 이를 위한 rewrite 규칙을 제공합니다.

자주 묻는 질문

악성 페이지가 사용자의 브라우저 쿠키를 이용해 다른 사이트의 비공개 데이터를 읽는 것을 막기 위해서입니다. CORS가 없다면 evil.com을 방문하는 것만으로 사용자인 척 은행 내부 API에 요청할 수 있습니다. CORS는 은행이 교차 출처 읽기를 명시적으로 허용하도록 강제합니다.

개발 환경에서만 가능합니다. Chromium에는 --disable-web-security 플래그가 있지만 모든 사이트에 영향을 주고 위험합니다. 올바른 해결책은 서버 측 헤더이거나 프록시입니다.

Postman은 브라우저가 아니므로 CORS를 완전히 무시합니다. CORS는 JavaScript 요청에 대해 브라우저만 시행합니다. Postman에서 작동하는 서버가 자동으로 CORS에 맞는 것은 아닙니다.

이미지와 고전적인 <script> 태그는 CORS 없이 교차 출처로 로드되지만, JS는 그 내용을 읽을 수 없습니다. <img crossorigin>fetch()는 CORS를 시행하므로, 이것이 없으면 canvas에 그린 이미지가 “tainted” 상태가 됩니다.

관련 도구