CORS 설정 점검

CORS 설정 점검 도구는 특정 URL이 다른 출처(origin)에서 오는 브라우저 요청을 허용하는지 실제 요청을 보내 확인합니다. 서버가 응답에 붙이는 Access-Control-Allow-Origin·-Methods·-Headers·-Credentials 헤더를 그대로 보여주고, 그 의미를 정상/주의/위험으로 평가합니다. 자바스크립트에서 API를 호출할 때 나는 “has been blocked by CORS policy” 오류의 원인을 빠르게 좁힐 수 있습니다.

점검할 API URL과 요청을 보낼 출처(origin)를 입력하면, 서버가 단순 GET 요청과 OPTIONS preflight 요청을 함께 보내 응답 헤더를 수집합니다. 출처를 비워 두면 기본값 https://example.com으로 점검합니다. 브라우저가 아닌 서버에서 헤더만 읽으므로 실제 데이터는 가져오지 않으며, 결과는 잠시 캐싱되어 빠르게 응답합니다.

CORS가 동작하는 방식

브라우저는 자바스크립트가 자기 출처와 다른 출처로 요청을 보낼 때, 응답에 적절한 Access-Control 헤더가 있어야만 결과를 자바스크립트에 넘겨줍니다. 헤더가 없거나 출처가 맞지 않으면 네트워크 응답 자체는 도착해도 브라우저가 차단합니다.

• Access-Control-Allow-Origin: 허용할 출처. 특정 URL, 와일드카드(*), 또는 요청 출처를 그대로 반사한 값.
• Access-Control-Allow-Methods: preflight에서 허용되는 HTTP 메서드 목록.
• Access-Control-Allow-Headers: 요청에 허용되는 커스텀 헤더 목록.
• Access-Control-Allow-Credentials: 쿠키·인증 정보를 함께 보낼 수 있는지 여부.

preflight와 단순 요청

GET 같은 단순 요청은 곧바로 전송되지만, 커스텀 헤더가 있거나 PUT·DELETE 등은 브라우저가 먼저 OPTIONS preflight 요청으로 허용 여부를 묻습니다. 이 도구는 두 요청을 모두 보내, preflight 응답의 헤더를 우선 평가하고 없으면 단순 요청 응답으로 보완합니다.

* 와 credentials 동시 허용의 위험

Access-Control-Allow-Origin이 *(와일드카드)이면서 동시에 자격증명을 허용하는 설정은 위험합니다. 사양상 브라우저는 와일드카드와 credentials를 함께 허용하지 않지만, 서버가 요청 출처를 무조건 반사하면서 credentials까지 허용하면 사실상 모든 사이트가 사용자의 쿠키로 API를 호출할 수 있게 됩니다. 신뢰하는 출처만 명시적으로 허용하세요. CORS 외에 응답의 다른 헤더까지 확인하려면 HTTP 헤더 확인으로 전체 응답 헤더를 살펴보세요.

CORS 응답 헤더 해석표

결과에 나온 헤더 값을 아래 표와 대조하면 의미를 빠르게 판단할 수 있습니다. 같은 헤더라도 값에 따라 정상·주의·위험이 달라집니다.

실제 점검 예시

출처 https://app.example.com으로 https://api.example.com/users를 PUT 요청(커스텀 헤더 Authorization 포함)한다고 가정하면, 브라우저는 먼저 OPTIONS preflight를 보냅니다. 서버가 다음처럼 응답하면 통과합니다.

• Access-Control-Allow-Origin: https://app.example.com — 내 출처가 정확히 반사됨
• Access-Control-Allow-Methods: GET, PUT, DELETE — PUT 포함됨
• Access-Control-Allow-Headers: Authorization, Content-Type — 보낼 헤더 포함됨
• Access-Control-Allow-Credentials: true — 쿠키 동반 시 필요
• Access-Control-Max-Age: 600 — preflight 결과를 600초 캐싱(반복 OPTIONS 절약)

만약 Allow-Methods에 PUT이 빠졌거나 Allow-Headers에 Authorization이 없으면, 브라우저는 본 요청을 보내지 않고 콘솔에 “Method PUT is not allowed” 또는 “Request header field authorization is not allowed by Access-Control-Allow-Headers” 오류를 띄웁니다. 이 도구가 preflight 응답의 Methods/Headers를 따로 보여주므로 어느 쪽이 빠졌는지 바로 알 수 있습니다.

흔한 실수 / 함정

• “서버에서 curl로 응답이 오는데 왜 막히지?” — CORS는 오직 브라우저에서만 강제됩니다. curl·Postman·서버 간 호출은 절대 차단되지 않으므로, 그 도구로 “되는” 것이 CORS 통과를 뜻하지 않습니다.
• Allow-Origin에 끝 슬래시·여러 출처 나열·포트 누락이 있으면 매칭 실패합니다. 값은 정확히 하나의 출처(scheme://host:port)여야 하며 https://app.example.com,https://x.com처럼 콤마로 여러 개를 넣으면 무효입니다.
• 403/500 같은 오류 응답에는 보통 CORS 헤더가 안 붙어서, 실제 원인은 인증 실패인데 콘솔엔 “blocked by CORS”로만 보입니다. 상태 코드를 먼저 확인하세요.