CORS 검사기

모든 URL에 대한 교차 출처 리소스 공유(CORS) 구성을 확인하세요. Access-Control-* 응답 헤드를 검사하고, 사용자 정의 Origin/메서드/헤더로 선택적 프리플라이트(OPTIONS) 요청을 실행하며, 와일드카드 + 자격 증명, 누락된 Vary: Origin, 또는 지나치게 광범위한 allow-headers와 같은 일반적인 오류 구성을 감지합니다.

Loading…

소개 CORS 검사기

API 또는 페이지 URL을 붙여넣고 브라우저가 교차 출처 요청을 허용할지 확인하세요. 이 도구는 CORS 응답 헤더를 분석하고, 현실적인 프리플라이트(OPTIONS) 검사를 실행할 수 있으며, 위험하거나 손상된 구성(예: 자격 증명과 함께 "*" 사용, Vary: Origin 누락, 약한 allow-methods/allow-headers)을 강조 표시합니다.

기능

  • 모든 공개 URL에 대한 CORS 헤더 검사(Access-Control-* 및 관련 헤더).
  • 사용자 정의 Origin, 요청 메서드 및 요청 헤더를 사용한 선택적 프리플라이트 시뮬레이션(OPTIONS).
  • 리디렉션(최대 10회)을 따라가 브라우저가 실제로 접근하는 최종 엔드포인트를 검증합니다.
  • 완전한 투명성과 디버깅을 위한 원시 헤더 보기.
  • 발견 사항 + 점수 카드와 함께 "문제만" 필터링 기능으로 빠른 분류 가능.
  • 누락된 Vary: Origin 및 기타 캐시 관련 CORS 함정을 감지하는 Vary 분석.
  • 감사, 티켓 및 문서화를 위해 결과를 JSON 및 PDF 보고서로 내보내기.
  • 일반적인 문제에 대한 내장 권장 사항: 와일드카드+자격 증명, Origin 반영, null Origin, 누락된 allow-methods/allow-headers, 누락된 max-age, 지나치게 광범위한 allow-headers.

🧭 사용 방법 for cors-checker

1

대상 URL 입력

테스트하려는 엔드포인트를 붙여넣으세요(예: https://api.example.com/resource).

2

테스트하는 Origin 설정

프론트엔드 앱의 Origin(스키마 + 호스트)을 입력하세요(예: https://app.example.com). 이는 브라우저가 Origin 헤더로 보내는 값입니다.

3

검사 모드 선택

응답 헤더와 프리플라이트 동작을 모두 분석하려면 자동(권장)을 사용하세요. 비프리플라이트 시나리오를 원하면 단순 요청을, OPTIONS 검사만 실행하려면 프리플라이트 전용을 사용하세요.

4

프리플라이트 세부 사항 구성(해당하는 경우)

"프리플라이트 실행(OPTIONS)"을 활성화하고 요청 메서드와 요청 헤더(쉼표로 구분)를 설정하여 실제 브라우저 프리플라이트 동작(예: 인증, 콘텐츠 유형)을 시뮬레이션하세요. 사용 사례에 쿠키 또는 인증 헤더가 포함된 경우 "자격 증명 고려"를 토글하세요.

5

발견 사항 검토 및 내보내기

발견 사항/점수 카드와 CORS 분석 세부 정보를 확인하세요. 디버깅 시 "원시 헤더 표시"를 켜세요. 감사, 공유 또는 저장을 위해 JSON/PDF로 내보내세요.

기술 사양

요청 모델

이 도구는 대상 URL에 대한 CORS 헤더를 검사하고, 제공된 Origin, 메서드 및 요청 헤더를 사용하여 선택적으로 프리플라이트(OPTIONS) 요청을 수행할 수 있습니다. 리디렉션 추적이 지원됩니다.

설정동작기본값
검사 모드자동, 단순 요청 또는 프리플라이트만자동
프리플라이트 실행 (OPTIONS)활성화 시 OPTIONS 프리플라이트 시뮬레이션 수행활성화됨
오리진분석/프리플라이트에 사용되는 Origin 헤더 값https://example.com
요청 메서드프리플라이트용 Access-Control-Request-Method 값GET
요청 헤더프리플라이트용 Access-Control-Request-Headers (쉼표로 구분)비어 있음
리디렉션 따르기최종 URL까지 리디렉션 체인을 따름활성화됨
최대 리디렉션 횟수루프 방지를 위한 리디렉션 상한10 (범위 0–20)
타임아웃요청 타임아웃 제한15000 ms
사용자 에이전트요청 사용자 에이전트를 식별Encode64Bot/1.0 (+https://encode64.com)
사설 네트워크안전을 위해 사설 네트워크 범위 접근 차단비활성화됨 (사설 네트워크 허용 안 됨)

분석된 헤더 (핵심 CORS 세트)

분석기는 브라우저 및 프리플라이트 검사에서 사용되는 표준 CORS 응답 및 요청 헤더에 중점을 둡니다.

헤더목적
Access-Control-Allow-Origin어떤 오리진이 허용되는지
Access-Control-Allow-Credentials쿠키/자격 증명 허용 여부 (와일드카드가 아닌 오리진 필요)
Access-Control-Allow-Methods교차 출처 요청에 허용되는 메서드 (사전 검사에 중요)
Access-Control-Allow-Headers허용되는 헤더 (인증 및 사용자 정의 헤더에 중요)
Access-Control-Expose-Headers브라우저 JS에서 읽을 수 있는 헤더
Access-Control-Max-Age브라우저가 사전 검사를 캐시할 수 있는 시간
Vary캐시 키 변형 (예: Vary: Origin)으로 캐시 오염/혼합 방지
Origin / Access-Control-Request-*사전 검사 동작을 시뮬레이션하는 데 사용

발견 패턴 (흔한 CORS 문제점 플래그)

결과는 실용적이고 보안 중심의 검사를 기반으로 하여 손상되었거나 위험한 CORS 설정을 탐지합니다.

검사 항목중요성
와일드카드 + 자격 증명Access-Control-Allow-Origin: *는 자격 증명과 함께 사용할 수 없음; 브라우저가 차단하거나 동작이 안전하지 않음
누락된 Vary: Origin응답이 Origin별로 다르지만 올바르게 캐시되지 않으면, 공유 캐시가 사이트 간 응답을 혼합할 수 있음
Origin 반사Origin을 무분별하게 반향하면 신뢰할 수 없는 출처를 의도치 않게 허용할 수 있음
Null Origin 경고Origin: null은 샌드박스된 iframe 또는 파일 컨텍스트에서 나타날 수 있음; 이를 허용하는 것은 종종 위험함
누락된 Allow-Methods / Allow-Headers서버가 메서드/헤더를 명시적으로 허용하지 않으면 사전 검사가 실패할 수 있음
과도하게 허용된 Allow-Headers너무 많은 헤더를 허용하면 공격 표면이 확대될 수 있음
누락된 Max-Age사전 검사가 너무 자주 실행되어 지연 시간이 증가할 수 있음
CORS는 브라우저 강제 메커니즘입니다. 서버는 비브라우저 클라이언트를 통해 교차 출처로 여전히 접근 가능할 수 있습니다; CORS를 유일한 통제 수단이 아닌 더 넓은 보안 태세의 일부로 취급하세요.

명령줄

터미널에서 CORS 및 사전 검사 동작을 재현하려면 다음 명령어를 사용하세요. 도구가 보고하는 내용을 디버깅하고 확인하는 데 유용합니다.

macOS / Linux

일반 요청에 대한 CORS 헤더 확인 (브라우저 Origin 시뮬레이션)

curl -i -H "Origin: https://example.com" https://api.example.com/resource

Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Vary를 확인하세요.

사전 검사 OPTIONS 요청 실행 (메서드 + 헤더)

curl -i -X OPTIONS -H "Origin: https://app.example.com" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: authorization, content-type" https://api.example.com/private

브라우저가 진행하려면 사전 검사가 올바른 Access-Control-Allow-Methods 및 Access-Control-Allow-Headers를 반환해야 합니다.

헤더를 확인하면서 리디렉션을 따르기

curl -iL -H "Origin: https://example.com" https://api.example.com

엔드포인트가 다른 CORS 규칙을 가진 다른 호스트로 리디렉션할 때 유용합니다.

Windows (PowerShell)

Origin 헤더와 함께 응답 헤더 검사하기

$r = Invoke-WebRequest -Uri https://api.example.com/resource -Headers @{ Origin = "https://example.com" }; $r.Headers

Access-Control-* 헤더가 존재하는 경우 표시합니다.

프론트엔드에서 쿠키나 인증을 사용하는 경우 허용적인 CORS를 피하세요. 신뢰할 수 있는 출처의 명시적 허용 목록을 선호하고, 응답이 출처에 따라 다를 경우 Vary: Origin을 포함하세요.

사용 사례

프론트엔드 "CORS 차단" 브라우저 오류 디버깅

fetch/XHR가 CORS 오류로 실패할 때, 서버가 사용자의 Origin과 요청 유형에 필요한 Access-Control-* 헤더를 반환하는지 확인하세요.

  • Access-Control-Allow-Origin이 앱 출처와 일치하는지 확인
  • 쿠키/인증을 사용하는 경우 Access-Control-Allow-Credentials가 true인지 확인 (그리고 출처가 와일드카드가 아닌지)
  • 여러 출처를 허용할 때 Vary: Origin이 존재하는지 확인

Authorization / 사용자 정의 헤더에 대한 사전 요청 검증

대부분의 인증된 API 호출은 Authorization 또는 비단순 콘텐츠 유형으로 인해 사전 요청을 트리거합니다. 이 도구는 OPTIONS 응답이 필요한 메서드와 헤더를 허용하는지 확인하는 데 도움이 됩니다.

  • Access-Control-Allow-Methods에 필요에 따라 POST/PUT/PATCH/DELETE가 포함되어 있는지 확인
  • Access-Control-Allow-Headers에 authorization, content-type 및 필요한 X-* 헤더가 포함되어 있는지 확인
  • 배포 전 누락된 allow-methods/allow-headers 발견하기

CORS 정책 보안 검토

CORS 오설정은 (특히 자격 증명과 함께) 악의적인 사이트에 비공개 API를 의도치 않게 노출시킬 수 있습니다. 결과를 사용하여 고위험 패턴을 발견하세요.

  • 자격 증명과 결합된 와일드카드 출처 감지
  • 임의의 사이트를 허용하는 출처 반영 패턴 감지
  • 의도하지 않은 경우 Origin: null 허용 플래그 지정

사전 요청 캐싱으로 성능 향상

사전 요청은 왕복 시간과 지연 시간을 추가합니다. 올바른 Max-Age는 안정적인 API에 대한 반복적인 사전 요청 검사를 줄일 수 있습니다.

  • 적절할 때 Access-Control-Max-Age가 존재하는지 확인
  • 빈번한 API 트래픽에 대한 반복적인 OPTIONS 호출 줄이기

❓ Frequently Asked Questions

간단히 말해 CORS란 무엇인가요?

CORS(교차 출처 리소스 공유)는 한 출처(스킴 + 호스트 + 포트)의 웹페이지가 다른 출처의 응답을 읽을 수 있는지 제어하는 브라우저 보안 메커니즘입니다. 이는 특정 Access-Control-* 응답 헤더에 의존합니다.

브라우저는 언제 사전 요청(OPTIONS)을 보내나요?

요청이 "단순"하지 않을 때, 예를 들어 특정 콘텐츠 유형과 함께 POST와 같은 메서드를 사용하거나 Authorization 또는 사용자 정의 X-* 헤더와 같은 헤더를 보낼 때 사전 요청이 전송됩니다. 브라우저는 실제 요청을 보내기 전에 OPTIONS를 통해 권한을 확인합니다.

왜 "Access-Control-Allow-Origin: *"이 자격 증명과 함께 사용될 때 위험한가요?

브라우저는 자격 증명이 관련된 경우 명시적 출처를 요구합니다. 자격 증명과 함께 와일드카드를 사용하는 것은 자격 증명 요청에 대해 유효하지 않으며 위험한 구성을 나타냅니다. 신뢰할 수 있는 출처의 명시적 허용 목록을 선호하세요.

왜 Vary: Origin이 필요한가요?

서버가 요청 Origin에 따라 다른 Access-Control-Allow-Origin 값을 반환하는 경우, 캐시는 한 사이트용 응답을 다른 사이트에 제공하는 것을 피하기 위해 Origin별로 다르게 처리해야 합니다. Vary: Origin은 캐시 혼합 및 관련 보안 문제를 방지하는 데 도움이 됩니다.

CORS가 브라우저가 아닌 클라이언트로부터 내 API를 보호할 수 있나요?

아니요. CORS는 브라우저에 의해 강제됩니다. 브라우저 외부에서 실행되는 스크립트(서버, curl, 모바일 앱)는 CORS와 관계없이 귀하의 API를 호출할 수 있습니다. 실제 접근 제어를 위해서는 인증, 권한 부여 및 속도 제한을 사용하세요.

사전 요청을 테스트할 때 "요청 헤더"에 무엇을 입력해야 하나요?

프론트엔드가 전송할 헤더를 쉼표로 구분하여 나열하세요(예: authorization, content-type, x-request-id). 이는 Access-Control-Request-Headers를 시뮬레이션하고 서버가 해당 헤더를 허용하는지 확인합니다.

여기에 URL을 붙여넣는 것이 안전한가요?

이 도구는 제공된 URL로 서버 측 요청을 수행하며 사설 네트워크 대상을 차단합니다. URL에 비밀 정보(쿼리 문자열의 토큰 등)를 포함하지 말고, 신뢰할 수 있는 공개 엔드포인트를 사용하세요.

Pro Tips

Security Tip

모든 Origin을 반영하는 대신 신뢰할 수 있는 출처의 허용 목록을 선호하세요. CORS를 보안에 민감한 구성으로 취급하세요.

Security Tip

쿠키/인증을 사용하는 경우, Access-Control-Allow-Credentials: true를 설정하고 명시적인 출처( "*"가 아닌)를 반환하세요.

Security Tip

여러 출처를 허용하거나 허용된 출처를 동적으로 선택할 때 Vary: Origin을 추가하세요.

Performance Tip

안정적인 API의 경우 사전 요청 지연을 줄이기 위해 적절한 Access-Control-Max-Age를 추가하세요.

Best Practice

사전 요청과 실제 요청 경로를 모두 테스트하세요. 일부 설정은 GET에 대해 올바른 헤더를 반환하지만 OPTIONS에서는 실패할 수 있습니다.

CI Tip

JSON 보고서를 내보내고 API 게이트웨이 구성 변경과 함께 보관하여 빠르게 회귀를 발견하세요.

Additional Resources

Other Tools

CORS 검사기 — Access-Control-* 헤더 및 프리플라이트(OPTIONS) 테스트 | Encode64