본문으로 건너뛰기

CORS 점검

CORS Tester

지정한 출처에서 브라우저가 보낼 프리플라이트와 Origin을 실은 GET 요청을 보내고, Fetch 표준 규칙으로 어떤 헤더 때문에 막혔는지 짚어 줍니다.

콘솔의 CORS 오류는 빠진 헤더 이름만 알려 주고 이유는 거의 알려 주지 않으며, 브라우저가 실제로 보낸 요청은 코드에 적힌 그 요청이 아닙니다. 이 도구는 지정한 출처에서 브라우저가 보낼 프리플라이트를 보내고, 이어서 그 Origin을 실은 GET을 보낸 뒤 Fetch 표준 규칙으로 결과를 읽습니다.

☁️ 서버를 사용corshttpdebugweb

이 도구는 우리 서버가 대신 요청합니다. 입력한 URL·출처·메서드·헤더 이름만 서버로 전송되고, 브라우저의 쿠키나 로그인 정보는 함께 가지 않습니다. 서버는 공인 주소에만 접속하며 사설망·내부 주소로의 요청은 거부합니다.

브라우저가 보낼 프리플라이트(OPTIONS)와 실제 요청을 서버가 대신 보내고, Fetch 표준의 CORS 규칙으로 판정합니다. 실제 요청은 언제나 GET(또는 HEAD)입니다 — 남의 API에 PUT·DELETE를 대신 쏘지 않습니다.

API를 호출하는 웹페이지의 스킴·호스트·포트.

application/json은 항상 프리플라이트를 부릅니다.

사용 방법

  1. 주소와 출처를 입력합니다

    출처는 요청을 *보내는* 쪽, 즉 호출하는 페이지이지 API가 아닙니다. 이 둘을 뒤바꾸는 것이 검사 결과와 브라우저가 어긋나는 가장 흔한 이유입니다.

  2. 실제로 쓰는 메서드와 헤더를 넣습니다

    프리플라이트는 단순 요청이 아닐 때만 발생합니다. `Content-Type: application/json`이나 `Authorization` 헤더가 그 방아쇠이므로, 이를 빼고 검사하면 실제로 보내지 않는 요청을 검사하게 됩니다.

  3. 어떤 규칙이 어긋났는지 봅니다

    결과는 일반적인 실패가 아니라 어긋난 검사를 짚어 줍니다. 출처 미허용, 메서드 미포함, 헤더 미포함, 자격증명과 와일드카드 출처의 조합 같은 것들입니다.

자주 묻는 질문

여기서는 통과인데 브라우저는 막습니다.

코드가 보내는 메서드·헤더·자격증명 모드가 정확히 같은지, 서버가 쿠키나 사용자 에이전트에 따라 응답을 바꾸지는 않는지 확인하십시오. 이 검사는 서버에서 실행되므로, 당신의 세션에 따라 달라지는 응답은 결과가 다를 수 있습니다.

왜 `Access-Control-Allow-Origin: *`은 쿠키와 함께 안 되나요?

표준이 금지합니다. `credentials: 'include'`를 쓰면 출처를 그대로 되돌려주고 `Access-Control-Allow-Credentials: true`가 있어야 합니다. 와일드카드와 자격증명의 조합은 버그가 아니라 설계상 거부됩니다.

이 검사는 브라우저에서 도나요?

아니요. 서버에서 실행합니다. CORS가 막는 요청은 브라우저가 보낼 수 없기 때문입니다. 따라서 당신의 쿠키나 네트워크 위치 없이 공개 응답을 보게 됩니다.

내부 주소도 검사할 수 있나요?

안 됩니다. 요청은 당신의 네트워크에 닿을 수 없는 서버에서 나가므로, 내부에서만 해석되는 주소는 CORS 설정과 무관하게 실패합니다.

이 도구로 이어지는 것

다음 단계

이 도구의 결과를 그대로 받을 수 있는 도구들입니다.