네트워크/HTTP
CORS Checker / Explainer
브라우저가 크로스 오리진 요청을 허용할지 단계별로 설명합니다 — simple/preflight 분류, 응답의 Access-Control-* 헤더 확인, 요약.
한 줄에 하나씩, "이름" 또는 "이름: 값" — 값은 분류에 영향을 주지 않습니다.
DevTools의 Network 탭(응답 자체 또는 preflight OPTIONS의 헤더)이나 curl -I에서 가져오세요.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
자주 묻는 질문
서버가 성공적으로 응답했는데도 요청이 CORS 오류로 실패하는 이유는 무엇인가요?
CORS는 서버가 아니라 브라우저에 의해 적용됩니다 — 응답에 요청 출처와 일치하는 Access-Control-Allow-Origin 헤더가 없으면, 요청 자체는 완료되었더라도 브라우저는 JavaScript가 응답을 읽는 것을 차단합니다.
단순 요청과 프리플라이트 요청의 차이는 무엇인가요?
단순 요청(표준 헤더를 가진 기본 GET/POST)은 바로 통과하지만, 사용자 지정 헤더, 다른 메서드, 특정 콘텐츠 타입을 가진 요청은 실제 요청을 보내기 전에 권한을 확인하기 위해 먼저 프리플라이트 OPTIONS 요청을 트리거합니다.
여기서 CORS 헤더를 확인하면 제 데이터가 서버로 전송되나요?
이 도구는 사용자가 제공한 헤더를 검사하거나 브라우저에서 직접 가져옵니다 — 어떤 중간 서버도 요청 데이터를 저장하지 않습니다.
CORS가 API를 악의적인 요청으로부터 보호하나요?
아니요. CORS는 브라우저 내 JavaScript가 읽을 수 있는 것만 제한합니다 — curl, Postman, 백엔드 스크립트를 사용하는 공격자는 이를 완전히 우회하므로, 실제 인증과 권한 부여는 서버에서 구현되어야 합니다.
Access-Control-Allow-Origin: *가 credentials: include와 함께 작동하지 않는 이유는 무엇인가요?
사양은 보안상의 이유로 이 조합을 의도적으로 금지합니다 — 임의의 origin을 허용하는 와일드카드와 함께 credentials(쿠키, 인증 헤더)를 허용하면 심각한 보안 결함이 되므로, credentials를 사용할 때 서버는 정확한 origin을 반환해야 합니다.