01
프런트엔드의 Origin 지정
API 주소가 아니라 호출하는 페이지의 스킴, 호스트와 포트를 입력하세요. 로컬 시뮬레이션에서는 가상 Origin을 쓸 수 있지만 브라우저 GET은 이 사이트의 실제 Origin으로 고정됩니다.
HTTP / 요청 디버깅
CORS 테스터브라우저가 읽을 수 있는지 확인
실제 응답 헤더와 필요한 경우 OPTIONS 응답을 붙여 넣으세요. 브라우저 GET은 직접 실행해야 합니다.
CORS 테스터
실제 응답 헤더
OPTIONS 응답 헤더(선택)
붙여 넣은 헤더는 브라우저에서만 분석하며 요청을 보내지 않습니다.
결과
응답 헤더를 붙여 넣으세요.
요청 조건
이 Origin은 로컬 분석용입니다. 브라우저 GET은 이 페이지의 실제 Origin을 사용합니다.
응답 헤더를 붙여 넣으세요.
서버 로그에는 200이 남았는데 프런트엔드의 fetch가 실패한다면 CORS 테스터로 응답 도착과 JavaScript의 읽기 권한을 분리해 보세요.
기본 CORS 검사기 모드는 붙여 넣은 헤더만 해석합니다. Origin과 메서드, 헤더 이름을 정하고 OPTIONS가 필요한지 확인할 수 있으며, 입력만으로 대상 서버에 접근하지 않습니다.
CORS 테스터를 쓰는 이유
HTTP 성공과 브라우저의 읽기 허용은 별개입니다.
서버의 200과 스크립트의 실패 구분
단순 GET이 서버에 도착해도 실제 응답의 Allow-Origin이 맞지 않으면 브라우저는 페이지 스크립트에 내용을 넘기지 않습니다. CORS 테스터는 두 결과를 같은 성공으로 표시하지 않습니다.
OPTIONS 근거를 별도로 확인
JSON POST나 Authorization 헤더는 프리플라이트 검사를 시작할 수 있습니다. 최종 응답만 붙이면 이 단계는 미확인입니다. OPTIONS 상태와 허용 헤더를 추가해 누락된 조건을 찾으세요.
두 단계의 허용 조건 추적
02
OPTIONS 필요 여부 확인
application/json, Authorization, 비단순 메서드는 사전 요청을 유발합니다. 요청 헤더 이름만 입력하면 됩니다. OPTIONS 응답을 넣지 않으면 그 단계는 미검증으로 남습니다.
03
최신 결과만 내보내기
입력이나 옵션이 바뀌면 예전 보고서의 복사와 다운로드가 비활성화됩니다. 자동 분석은 350ms 기다립니다. 끄면 버튼 또는 Ctrl/Cmd + Enter를 사용하세요.
브라우저 허용 조건별 분석
Origin과 인증 정보 비교
Allow-Origin: *는 credentials: include와 함께 사용할 수 없습니다. 특정 Origin을 반환해도 Allow-Credentials: true가 필요합니다. Authorization 요청 헤더는 별도로 사전 요청을 유발합니다.
메서드와 헤더 허용 확인
프리플라이트 검사에서 OPTIONS 상태, Allow-Methods와 Allow-Headers를 각각 확인하고 빠진 메서드 또는 헤더 이름을 보여 줍니다.
노출된 헤더와 Vary 검토
Expose-Headers와 Vary: Origin을 읽되 응답 한 개만 보고 모든 Origin을 반사하는 취약점이라고 단정하지 않습니다.
직접 선택한 브라우저 GET
사용자가 클릭한 뒤에만 인증 정보 없는 GET을 보냅니다. HTTP 오류 응답도 읽을 수는 있지만 fetch가 거부되면 숨겨진 상태와 헤더를 얻지 못합니다.
판정에 필요한 증거와 한계
- 붙여 넣은 헤더는 실측이 아님
- CORS 테스트의 로컬 결과는 제공된 텍스트와 Origin에 대한 조건부 분석입니다. 목표 API의 실제 응답을 확인하지 않습니다. 필요한 OPTIONS 응답이 없으면 미검증이라고 표시합니다.
- 브라우저 Origin은 바꿀 수 없음
- 직접 GET은 이 페이지의 Origin에서만 나갑니다. POST, Cookie 또는 사용자 지정 헤더 값은 보내지 않습니다. 같은 출처의 성공으로 교차 출처를 검증하지 않습니다.
- 서버 프록시와 스캔 없음
- CORS 테스터는 임의 URL을 서버에서 대신 요청하거나 Origin 목록을 순회하지 않습니다. Allow-Origin 부재만으로 결함이라고 판단하지 않습니다.
- 보이지 않는 헤더는 없다는 뜻이 아님
- 성공한 fetch도 기본 허용 또는 Expose-Headers로 노출된 헤더만 스크립트가 읽을 수 있습니다. 전체 응답은 개발자 도구나 서버 로그에서 확인하세요.
CORS 테스터 자주 묻는 질문
서버가 성공적으로 응답했는데도 요청이 CORS 오류로 실패하는 이유는 무엇인가요?
서버가 응답해도 브라우저가 그 응답을 JavaScript에 공개하지 않을 수 있습니다. 실제 응답의 Allow-Origin을 보고, 필요하면 OPTIONS의 결과도 따로 확인하세요.
단순 요청과 프리플라이트 요청의 차이는 무엇인가요?
단순 GET은 먼저 전송한 뒤 응답 읽기 여부를 검사합니다. JSON POST나 사용자 지정 헤더는 OPTIONS에서 Origin, 메서드와 헤더 이름의 허가를 먼저 확인합니다.
여기서 CORS 헤더를 확인하면 제 데이터가 서버로 전송되나요?
기본 로컬 분석은 붙여 넣은 내용을 전송하지 않습니다. 브라우저 GET 모드를 선택하고 실행을 누른 경우에만 대상 URL로 인증 정보 없는 GET이 나갑니다.
CORS가 API를 악의적인 요청으로부터 보호하나요?
아니요. CORS는 브라우저 스크립트가 다른 출처의 응답을 읽을 수 있는지만 제한합니다. 인증과 서버 권한 검사를 대체하지 못합니다.
Access-Control-Allow-Origin: *가 credentials: include와 함께 작동하지 않는 이유는 무엇인가요?
인증 정보가 있는 교차 출처 요청에는 정확히 일치하는 Origin과 Allow-Credentials: true가 필요합니다. 와일드카드 Allow-Origin은 브라우저에서 거부됩니다.
다른 사례가 필요하신가요?