CORS 정책의 이해와 브라우저 결정 분석
웹 브라우저는 교차 출처 리소스 공유(CORS) 정책에 따라 다른 출처(Origin)의 리소스 접근을 제한합니다. CORS 검사기는 사용자가 제공한 HTTP 응답 헤더와 요청 세부정보를 비교하여 브라우저가 해당 교차 출처 요청을 허용할지 여부를 판별합니다.
이 도구는 실제 서버에 접속하거나 실시간 요청을 보내지 않으며, DNS/TLS 검사, 쿠키 설정, 서버 구성 변경 등도 수행하지 않습니다. 오직 사용자가 입력한 정적 헤더 데이터만을 기반으로 브라우저의 명세에 따른 통과 여부를 분석합니다.
입력 데이터 및 유효성 검증 규칙
CORS 검사기를 사용하려면 검사할 응답 유형을 선택하고 관련 요청 정보를 입력해야 합니다. 입력 과정에서 다음과 같은 규칙과 제한 사항이 적용됩니다.
- 확인을 위한 응답: "실제 응답" 또는 "실행 전 응답" 중 하나를 선택합니다.
- HTTP 응답 헤더: 최대 200,000자까지 입력할 수 있습니다. 비어 있는 경우 "확인하기 전에 HTTP 응답 헤더를 붙여넣으세요."라는 오류가 발생하며, 제한을 초과하면 "이 응답은 비정상적으로 큽니다.
‹max›문자 아래에 유지하세요."라는 메시지가 표시됩니다. 줄 바꿈이나 헤더 이름 형식이 잘못되면 "라인‹line›는 유효한 HTTP 헤더 또는 상태 라인이 아닙니다." 또는 "라인‹line›에 잘못된 HTTP 헤더 이름이 포함되어 있습니다." 오류가 발생합니다. - 요청 원본: 구성표(Scheme), 호스트, 선택적 포트만 포함된 순수 원본이어야 하며 경로, 쿼리, 자격 증명은 허용되지 않습니다. 예시 형식은
https://app.example.com이며, 잘못된 형식 입력 시 "https://app.example.com와 같이 구성표, 호스트 및 선택적 포트만 포함하여 원본을 입력합니다." 오류가 발생합니다. - 요청된 방법: HTTP 메서드 토큰을 입력합니다. 유효하지 않은 토큰은 "유효한 HTTP 메소드 토큰을 입력하세요." 오류를 발생시키며, 브라우저가 fetch 요청에서 금지하는 메서드는 "브라우저는 fetch 요청에서
‹method›메서드를 허용하지 않습니다." 오류를 반환합니다. - 요청된 헤더 이름:
Access-Control-Request-Headers에 대응하는 헤더 이름들을 쉼표나 줄 바꿈으로 구분하여 입력합니다. 잘못된 헤더 이름이 있으면 ""‹header›"는 유효한 HTTP 요청 헤더 이름이 아닙니다." 오류가 발생합니다. - 자격 증명 포함: 쿠키나 HTTP 인증을 요청에 포함할지 여부를 결정하는 토글입니다.
자격 증명 설정에 따른 CORS 동작 규칙
요청에 자격 증명(Cookies, HTTP Authentication)이 포함되는지 여부는 CORS 통과 여부를 결정하는 핵심 기준입니다.
- 자격 증명이 포함된 경우:
Access-Control-Allow-Origin헤더 값은 와일드카드(*)일 수 없으며, 요청 원본과 정확히 일치해야 합니다. 또한Access-Control-Allow-Credentials헤더가 반드시 존재해야 하며 그 값은 정확히true여야 합니다. 이 조건이 충족되지 않으면 "자격 증명 요청에는 Access-Control-Allow-Credentials: true가 필요합니다." 또는 "Access-Control-Allow-Origin는 *일 수 없습니다."라는 판정 이유와 함께 요청이 차단됩니다. 자격 증명이 포함되면 허용된 메서드 및 헤더에 지정된 와일드카드(*)도 그 의미를 잃고 무효화됩니다. - 자격 증명이 포함되지 않은 경우:
Access-Control-Allow-Credentials헤더는 결정에 영향을 미치지 않으며, "자격 증명은 포함되지 않으므로 Access-Control-Allow-Credentials는 이 결정에 영향을 미치지 않습니다."로 처리됩니다. 이 경우Access-Control-Allow-Origin에 와일드카드(*)를 사용할 수 있습니다.
프리플라이트(Preflight) 응답 검증과 와일드카드 예외
실제 요청을 보내기 전에 브라우저가 안전성 확인을 위해 전송하는 OPTIONS 요청에 대한 응답을 "실행 전 응답"이라고 합니다.
프리플라이트 검증 시에는 HTTP 상태 코드의 확인이 필수적입니다. 응답 헤더에 HTTP 상태 줄이 누락된 경우 "HTTP 상태 줄을 붙여넣지 않았으므로 필수 2xx 실행 전 상태를 확인할 수 없습니다."라는 메시지와 함께 결과가 "헤더가 통과했지만 실행 전 상태를 알 수 없습니다." 상태가 됩니다. 상태 코드가 2xx 성공 코드가 아니면 "비행 전 상태 ‹status›는 성공적인 2xx 상태가 아닙니다."로 판정되어 차단됩니다.
메서드 검증 시, 요청 메서드가 CORS 허용 목록(Safelisted)에 포함된 경우에는 Access-Control-Allow-Methods에 명시되어 있지 않아도 "‹method›는 CORS 허용 목록에 있는 방법이므로 Access-Control-Allow-Methods에 나타날 필요가 없습니다." 규칙에 따라 허용됩니다.
헤더 검증 시, 자격 증명이 없는 요청에 대해서는 Access-Control-Allow-Headers: *가 모든 헤더를 승인할 수 있습니다. 그러나 Authorization 헤더는 예외입니다. Authorization 헤더는 와일드카드(*)의 영향을 받지 않으며, 반드시 Access-Control-Allow-Headers에 명시적으로 나열되어야만 "Authorization는 명시적으로 나열되어야 합니다. Access-Control-Allow-Headers: *는 다루지 않습니다." 규칙을 통과할 수 있습니다.
개인정보 보호 및 데이터 처리 방식
CORS 검사기에 입력하는 모든 HTTP 응답 헤더와 요청 세부정보는 외부 서버로 전송되지 않습니다. 모든 구문 분석과 CORS 정책 비교 연산은 사용자의 웹 브라우저 내부에서 직접 실행됩니다. BroBroGo에 어떠한 데이터도 업로드되거나 저장되지 않으므로 안심하고 로컬 브라우저 환경에서 테스트를 진행할 수 있습니다.
자주 묻는 질문 (FAQ)
Q. 실제 응답을 붙여넣어야 합니까, 아니면 비행 전 응답을 붙여넣어야 합니까?
A. 브라우저 코드가 하나의 응답을 읽을 수 있는지 확인하려면 실제 응답을 사용하십시오. 이후 메서드와 요청된 헤더 이름을 승인하는 OPTIONS 응답에 대해 Preflight 응답을 사용합니다.
Q. 자격 증명과 함께 와일드카드가 실패할 수 있는 이유는 무엇입니까?
A. 쿠키 또는 HTTP 인증이 포함된 경우 허용된 출처는 요청하는 출처와 정확히 일치해야 합니다. 허용된 메서드 및 헤더에 대한 와일드카드도 와일드카드 의미를 잃습니다.
Q. 통과 결과가 실시간 요청이 작동한다는 것을 증명합니까?
A. 아니요. 이 결과에는 붙여넣은 응답과 여기에 입력된 요청 세부정보만 포함됩니다. 리디렉션, 캐시된 응답, 서버 규칙 변경, 브라우저 확장 및 실행 전 실제 응답으로 인해 여전히 결과가 변경될 수 있습니다.