서버 측에서 프리플라이트 및 실제 요청을 시뮬레이션하여 Access-Control-Allow-Origin, Access-Control-Allow-Headers, credentials 문제를 빠르게 진단합니다.
서버에서 실제 CORS preflight와 실제 요청을 시뮬레이션하고, 6가지 응답 헤더를 항목별로 검사하여 교차 출처 구성 오류를 정밀하게 찾아내고 Nginx/Node.js/Spring 등 다중 프레임워크 수정 코드를 제공합니다.
이것이 가장 고전적인 CORS 문제입니다! Postman과 curl은 브라우저 동일 출처 정책의 제한을 받지 않기 때문입니다——이들은 HTTP 클라이언트이지 브라우저가 아니므로 응답을 차단하지 않으며 자동으로 OPTIONS preflight 요청을 보내지도 않습니다. 교차 출처 오류는 브라우저 고유의 보안 메커니즘으로, 브라우저의 JavaScript 런타임 환경에서만 CORS 검사를 실행합니다. Postman에서 호출이 된다는 것은 API 자체가 데이터를 반환할 수 있다는 것만 증명할 뿐 CORS 구성이 올바르다는 것을 증명하지는 않습니다. 브라우저를 사용하거나 이 도구(서버에서 브라우저 CORS 프로세스를 시뮬레이션)로 검사해야 문제를 발견할 수 있습니다.
99%의 CORS 오류는 백엔드 구성 문제(Nginx/게이트웨이 계층 구성 문제 포함)이며 프론트엔드가 할 수 있는 것은 매우 제한적입니다. CORS의 핵심은 서버가 응답 헤더를 통해 브라우저에 '권한을 부여'하여 교차 출처 접근을 허용하는 것이며, 프론트엔드는 withCredentials 설정, 요청 헤더 설정 정도만 할 수 있을 뿐 브라우저의 보안 제한을 우회할 수 없습니다. 인터넷에서 말하는 프론트엔드 프록시 사용(devServer proxy, Nginx 리버스 프록시로 프론트엔드와 API를 동일 출처로 프록시)은 본질적으로 브라우저를 '속여' 동일 출처 요청으로 인식하게 하는 것일 뿐 진정으로 CORS 문제를 해결한 것이 아닙니다. 프로덕션 환경에서 프론트엔드와 백엔드가 다른 출처라면 여전히 백엔드가 올바르게 CORS를 구성해야 합니다.
GET은 보통 단순 요청 조건을 충족하므로 브라우저가 직접 요청을 보내기 때문입니다; 하지만 POST에서 Content-Type: application/json을 보내면(90%의 POST API가 이것임), 단순 요청이 아니게 되어 OPTIONS preflight가 트리거됩니다. preflight 요청은 서버가 올바른 CORS 헤더를 반환해야 하는데 많은 사람이 GET/POST에만 CORS 헤더를 구성하고 OPTIONS 메서드를 처리하지 않았거나 OPTIONS 응답에 헤더가 없어 오류가 납니다. PUT/DELETE/PATCH 등의 메서드는 그 자체가 비단순 메서드이므로 반드시 preflight를 트리거합니다.
개발 환경에는 몇 가지方案이 있습니다: ①프레임워크 내장 프록시(Vue CLI의 devServer.proxy, Vite의 server.proxy, Create React App의 proxy): API 요청을 프론트엔드 개발 서버와 동일 출처로 프록시하여 브라우저가 동일 출처 요청으로 인식하게 하여 교차 출처가 되지 않게 함; ②브라우저 보안 매개변수 비활성화(예: Chrome에 --disable-web-security 시작 매개변수 추가), 로컬 임시 테스트에만 사용하며 정상 브라우징에는 절대 사용 금지; ③백엔드가 CORS를 구성하여 localhost 출처를 허용(권장, 프로덕션 환경과 동작이 일치함). 프로덕션 환경은 반드시 백엔드가 올바르게 CORS를 구성해야 합니다: 허용된 출처 화이트리스트 구성, Allow-Methods/Allow-Headers/Allow-Credentials 올바르게 설정, Vary: Origin 추가, 또는 게이트웨이/Nginx에서 CORS를 일관 처리합니다.
아니요, Access-Control-Allow-Origin 응답 헤더는 하나의 값만 가질 수 있으며 구체적인 한 출처(예: https://a.com)이거나 *입니다. 브라우저는 여러 출처를 허용하지 않습니다(예를 들어 https://a.com,https://b.com으로 작성하면 무효이며 브라우저는 불일치로 간주합니다). 올바른 다중 출처 구성 방법은: 서버가 허용된 출처 화이트리스트 목록을 유지 관리하고, 요청을 받을 때마다 요청 헤더의 Origin 값을 읽어 이 Origin이 화이트리스트에 있는지 확인한 후, 있다면 Access-Control-Allow-Origin을 이 구체적인 Origin 값으로 설정하고 Vary: Origin 헤더를 반환하는 것입니다; 없다면 CORS 헤더를 반환하지 않거나 오류를 반환합니다. 여러 Allow-Origin 헤더를 반환하거나 쉼표로 여러 값을 구분하려고 하지 마세요. 브라우저가 인식하지 않습니다.
OPTIONS preflight 요청은 어떤 비즈니스 로직이나 응답 본문도 반환할 필요가 없으며 올바른 CORS 응답 헤더와 200/204 상태 코드만 반환하면 됩니다. 브라우저는 올바른 CORS 헤더를 받으면 preflight가 통과되었다고 간주하며 OPTIONS 응답의 body 내용을 읽지 않습니다. 따라서 모범 사례는: Nginx/게이트웨이 계층에서 OPTIONS 요청을 직접 가로채어 204 No Content와 올바른 CORS 헤더를 반환하고 백엔드 애플리케이션 서버로 전달하지 않는 것입니다. 이렇게 하면 백엔드 부하를 줄일 뿐만 아니라 백엔드 라우트가 OPTIONS를 지원하지 않아 발생하는 405 오류도 피할 수 있습니다. 단, OPTIONS 응답의 CORS 헤더가 실제 요청의 CORS 헤더와 일관되게 유지되도록 주의해야 합니다.
Cookie가 포함된 교차 출처 요청은 세 가지 조건을 동시에 충족해야 합니다: ①프론트엔드 XMLHttpRequest.withCredentials = true 또는 fetch의 credentials: 'include'; ②백엔드 응답 헤더 Access-Control-Allow-Credentials: true; ③Access-Control-Allow-Origin은 *가 될 수 없으며 구체적인 출처여야 함. 세 가지 조건이 하나라도 빠지면 안 됩니다. 또한 Cookie 속성에도 주의해야 합니다: Cookie에 SameSite=None; Secure(HTTPS 환경)가 설정되어야 교차 출처 요청에 포함될 수 있습니다; Cookie가 SameSite=Lax나 Strict이면 교차 출처 요청에 포함되지 않습니다; Cookie의 Domain 속성이 올바르게 설정되어야 합니다; 제3자 Cookie 정책의 영향도 주의해야 합니다(Chrome 등 브라우저는 제3자 Cookie에 제한이 있음).
CORS는 교차 출처 접근 제한을 완화하는 것이고 CSRF는 교차 사이트 요청 위조 공격으로 둘은 다른 개념입니다. 올바르게 구성된 CORS가 직접 CSRF 취약점을 유발하지는 않습니다——CORS는 JS가 응답을 읽는 것을 허용할 뿐이지, CSRF는 공격자가 사용자가 모르게 요청을 보내도록 유도하는 것이기 때문입니다(예: img 태그, 자동 제출 양식). 이러한 요청은 CORS가 없어도 전송되고 Cookie가 포함됩니다. CSRF 방어에는 CSRF Token, SameSite Cookie, Origin/Referer 검증 등의方案을 사용해야 하며 CORS 비활성화로 CSRF를 막을 수 없습니다. 하지만 CORS 구성 시 Allow-Origin을 *로 설정하고 자격 증명을 허용하면 CSRF 위험이 확대될 수 있으므로, 자격 증명 시나리오에서는 절대 *를 사용하지 말고 화이트리스트 출처를 엄격히 제한해야 합니다.
일반적인 <img>, <script>, <link> 태그로 교차 출처 리소스(CDN 이미지, JS 스크립트, CSS)를 로드하는 것은 기본적으로 CORS 문제가 없습니다. 이들은 '포함 리소스'이지 'AJAX 요청'이 아니며 브라우저가 로드를 허용하지만 JS가 내용을 읽을 수는 없습니다. 하지만 Canvas에서 교차 출처 이미지를 조작하거나 fetch/XHR로 이러한 리소스를 로드하여 내용을 읽으려면 CORS가 필요하며 태그에 crossorigin 속성을 추가해야 합니다. 교차 출처 파일 다운로드(a 태그 클릭 다운로드)도 기본적으로 CORS가 필요하지 않습니다. 리디렉션은 CORS에 영향을 줍니다: preflight OPTIONS 요청이 3xx 리디렉션을 반환하면 브라우저가 직접 거부합니다(Preflight redirect is not allowed); 실제 요청의 리디렉션이 교차 출처인 경우 각 홉마다 올바르게 CORS 헤더를 반환해야 합니다.
Nginx 권장 구성 요점: ①map 지시문으로 Origin 화이트리스트를 매칭하여 $cors_origin 변수를 동적으로 설정; ②OPTIONS 요청은 직접 204를 반환하고 백엔드로 전달하지 않음; ③add_header에 always 매개변수를 추가하여 오류 응답에도 헤더가 포함되도록 함; ④Vary: Origin 추가; ⑤Allow-Methods/Allow-Headers/Credentials 올바르게 구성. 예시 구성은 이 도구 검사 결과의 수정 제안에서 찾을 수 있으며, Nginx, Apache, Node.js Express, Spring Boot, Python Flask/Django, Koa, Go Gin 등 주요 프레임워크에 대해 검증된 구성 스니펫을 제공합니다.
CORS 검증 단계: ①먼저 이 도구로 온라인 검사를 하여 URL, Origin, 메서드, 헤더, 자격 증명 옵션을 입력하고 preflight와 실제 요청의 각 항목 검사가 통과하는지 확인; ②브라우저 DevTools의 Network 패널을 열고 Disable cache를 체크하여 캐시를 비활성화하고(오래된 캐시 간섭 방지), 교차 출처 요청을 트리거하여 OPTIONS preflight와 실제 요청의 응답 헤더가 올바른지 확인; ③Console에 CORS 관련 오류가 있는지 확인; ④다양한 시나리오 테스트: 사용자 정의 헤더 없는 GET 요청, application/json이 포함된 POST 요청, PUT/DELETE 메서드, Cookie 포함/미포함, 사용자 정의 헤더 포함; ⑤curl로 OPTIONS 요청 시뮬레이션: curl -i -X OPTIONS -H "Origin: https://yoursource.com" https://api.example.com/endpoint로 응답 헤더가 올바른지 확인.
브라우저마다 CORS 사양 구현 세부 사항에 차이가 있습니다: ①Safari는 preflight 캐시 Max-Age 제한이 더 엄격하고(예전 버전은 600초였음) Cookie 정책(ITP 지능형 추적 방지)도 더 엄격하여 교차 출처 Cookie 문제가 발생할 수 있음; ②Chrome은 자격 증명 시 와일드카드 검사가 더 엄격하여 Allow-Headers/Allow-Methods에도 *를 허용하지 않으며, Firefox 일부 버전은 더 관대할 수 있음; ③구형 IE(IE11)는 표준 XMLHttpRequest가 아닌 XDomainRequest를 사용하여 CORS 구현에 많은 함정이 있음(예: 사용자 정의 헤더 미지원, GET/POST만 지원); ④브라우저마다 Vary 헤더 처리, 리디렉션 처리, 보안 헤더 처리에 미묘한 차이가 있습니다. 해결 방법은 특정 브라우저의 호환 동작에 의존하지 말고 CORS 사양에 따라 엄격하게 구성하는 것입니다.
3600(1시간)에서 86400(24시간) 사이로 설정하는 것을 권장합니다. 너무 짧게 설정하면(예: 60초) preflight 캐시가 빨리 만료되어 OPTIONS 요청을 빈번하게 보내 요청 지연 시간과 서버 부하가 증가하며 모바일 약한 네트워크 환경에서 영향이 두드러집니다. 너무 길게 설정하면(예: 31536000 즉 1년) CORS 구성을 업데이트한 경우(예: 허용 메서드/헤더 추가) 사용자 브라우저에 캐시된 오래된 preflight 결과가 오랫동안 만료되지 않아 구성이 적용되지 않는 문제가 발생할 수 있습니다. 또한 Chrome과 Firefox는 86400초를 초과하는 값을 자동으로 86400초로 자르므로 더 길게 설정해도 소용이 없습니다. 개발 환경에서는 -1로 설정하여 preflight 캐시를 비활성화하면 디버깅에 편리합니다.
WebSocket(ws://와 wss://)은 HTTP CORS 메커니즘의 제한을 받지 않습니다. WebSocket은 독립적인 프로토콜이며 HTTP AJAX 요청이 아니기 때문입니다. 하지만 WebSocket 핸드셰이크 단계는 HTTP 요청이므로 서버가 Origin 헤더를 검사하여 연결 허용 여부를 결정할 수 있습니다——이것은 WebSocket 수준의 권한 제어이지 표준 CORS는 아니지만 원리는 비슷합니다. WebSocket 연결이 거부되면 HTTP CORS 헤더가 아니라 WebSocket 서버의 Origin 검증 구성을 확인해야 합니다. Socket.IO 등 라이브러리는 자체적인 교차 출처 구성 방식이 있을 수 있으며 표준 CORS 구성과 유사하지만 완전히 같지는 않습니다. 또한 HTTP/2 Server Push, WebRTC 등 다른 브라우저 API도 자체적인 권한 제어가 있으며 HTTP CORS를 완전히 따르지는 않습니다.
이 도구는 서버에서 W3C CORS 사양에 따라 브라우저의 preflight와 실제 요청 프로세스를 엄격하게 시뮬레이션하며, CORS 헤더 검사 로직은 현대 브라우저와 기본적으로 일치합니다. 도구 검사는 통과했는데 브라우저에서 여전히 오류가 난다면 가능한 원인: ①브라우저가 오래된 preflight 결과나 응답을 캐시했습니다. Ctrl+F5로 강제 새로고침하거나 캐시를 지우고 다시 시도; ②브라우저 확장 프로그램(광고 차단, 개인 정보 보호, 보안 플러그인)이 요청을 수정하거나 차단함; ③도구에 입력한 Origin, 요청 헤더, 메서드, 자격 증명 옵션이 실제 프론트엔드가 보내는 것과 불일치(예: 프론트엔드가 실제로 어떤 사용자 정의 헤더를 더 보내는데 도구에 추가하지 않음); ④CDN/프록시 노드 캐시가 일관되지 않아 도구가 요청한 노드와 브라우저가 요청한 노드가 다른 결과를 반환함; ⑤브라우저에 특수 보안 정책이 있음(예: HTTPS 페이지가 HTTP 혼합 콘텐츠를 요청하여 차단됨, 로컬 파일 file:// 프로토콜의 특수 제한).
