CORS 응답 시뮬레이터
직접 입력한 헤더로 일반적인 브라우저 CORS 교환을 재현합니다. OPTIONS 사전 요청이 필요한지, 실제 요청이 전송되는지, 스크립트가 최종 응답을 읽을 수 있는지 단계별로 확인하세요.
주요 기능
- 스크립트 출처와 대상 URL의 스킴·호스트·포트를 비교
- 메서드와 CORS 안전 목록 밖의 요청 헤더로 사전 요청 필요 여부 계산
- OPTIONS 상태·허용 출처·인증 정보·메서드·헤더를 각각 검사
- 사전 요청 실패와 실제 요청 후 응답을 읽지 못하는 상황을 구분
- 성공·인증 정보와 와일드카드 충돌·단순 GET 예제를 서버 접속 없이 실행
사용 방법
- 스크립트 출처, 전체 대상 URL, 메서드, 인증 정보 모드와 직접 지정한 요청 헤더를 입력합니다.
- 예상하는 OPTIONS 응답 상태와 Access-Control-Allow-* 헤더를 입력합니다.
- 예상하는 실제 응답 상태와 Access-Control-Allow-* 헤더를 입력합니다.
- 시뮬레이션을 실행하고 각 단계의 통과·실패 근거를 읽습니다.
활용 예시
- 쿠키를 포함한 fetch가 Access-Control-Allow-Origin: *에서 왜 실패하는지 확인합니다.
- JSON POST에 OPTIONS가 필요한지와 Access-Control-Request-Headers에 들어갈 이름을 확인합니다.
- Authorization 명시 허용 누락이나 메서드 철자 불일치를 찾습니다.
- 서버의 403 응답은 읽을 수 있어도 실패한 사전 요청에서는 실제 요청이 전송되지 않는 차이를 설명합니다.
자주 묻는 질문
실제로 OPTIONS나 fetch 요청을 보내나요?
아닙니다. 브라우저 안에서 입력 텍스트만 평가합니다. 네트워크 오류·리다이렉트·캐시·사설 네트워크 접근·서비스 워커·브라우저 확장은 재현하지 않습니다. 최종 동작은 실제 브라우저 개발자 도구와 서버 로그에서 확인하세요.
인증 정보를 포함하면 Access-Control-Allow-Origin: *가 왜 실패하나요?
Fetch의 CORS 검사는 credentials 모드가 include가 아닐 때만 출처 와일드카드를 허용합니다. include에서는 직렬화된 요청 출처를 지정하고, 필요한 사전 응답과 실제 응답 모두에 Access-Control-Allow-Credentials: true를 제공해야 합니다.
메서드와 헤더 이름은 같은 대소문자 규칙으로 비교하나요?
아닙니다. Fetch는 DELETE·GET·HEAD·OPTIONS·POST·PUT을 먼저 대문자로 바꿉니다. 그 결과를 Access-Control-Allow-Methods와 정확히 비교하지만 허용 요청 헤더 이름은 대소문자를 구분하지 않습니다. PATCH 같은 확장 메서드는 입력한 대소문자를 유지합니다.
차단으로 나오면 서버가 요청을 받지 않은 건가요?
사전 요청이 실패하면 실제 요청은 전송되지 않습니다. 사전 요청이 없거나 통과하면 실제 요청이 서버에 도착한 후 최종 응답의 CORS 검사가 실패할 수 있습니다. CORS는 브라우저의 응답 읽기 규칙이지 서버 인증·인가 규칙이 아닙니다.
어떤 상황을 모델링하지 않나요?
HTTP(S) CORS 모드와 일반 메서드·ASCII 요청 헤더의 제한된 범위입니다. 리다이렉트, 304/407, 사전 요청 캐시, 스트리밍 본문에 의한 강제 사전 요청, 요청 본문, 응답 헤더 노출, 사설 네트워크 접근, 혼합 콘텐츠, 서버 인증은 제외합니다. 복잡한 MIME 매개변수는 보수적으로 안전하지 않은 헤더로 취급할 수 있습니다.
개인정보 안내
헤더 텍스트는 이 브라우저 탭의 메모리에서만 처리합니다. 도구는 요청을 보내거나 업로드·자동 저장하지 않습니다. 실제 인증 정보나 비밀값은 붙여 넣지 말고, 비공개 헤더가 보이는 화면을 공유할 때 주의하세요.
댓글과 질문