VPN은 CORS를 끌 수 없다, 응답을 바꿀 뿐이다

동시에 바뀐 두 가지를 분리하는 것부터 시작하라. 네트워크 경로와 브라우저의 적용이다. VPN은 출구 주소를 바꾸지만 페이지의 오리진은 바꾸지 않는다. 오리진은 스킴, 호스트, 포트로 만들어진다. 요청이 이제 성공한다면 응답의 무언가가 바뀌었거나 요청 자체가 바뀐 것이다. 어느 쪽인지 밝히는 것이 조사의 전부다.

CORS는 브라우저가 적용하는 헤더 프로토콜이므로 네트워크 경로의 무엇도 그것을 끌 수 없다.

오리진은 IP 주소가 아니다

오리진은 스킴, 호스트, 포트다. 패킷이 나가는 주소도 아니고 서버가 보는 IP도 아니다. 그래서 VPN은 관찰 가능한 모든 주소를 바꾸면서 오리진은 그대로 둘 수 있다. 브라우저는 응답의 Access-Control-Allow-Origin을 페이지의 오리진과 비교하며, 출구 주소는 그 비교에 결코 들어가지 않는다.

따라서 CORS 오류를 고치는 것처럼 보이는 확장 프로그램이나 프록시는 다른 일을 한다. 헤더를 다시 쓰거나, 요청이 더 이상 교차 오리진이 아니도록 경로를 바꾼다. 둘 다 VPN의 속성이 아니다.

브라우저가 실제로 보내는 것

단순하지 않은 교차 오리진 요청에서는 브라우저가 먼저 프리플라이트 OPTIONS를 보내며, 의도한 메서드와 헤더를 담는다. 서버는 허용하는 권한으로 응답해야 하고, 그 응답이 규칙을 만족할 때만 실제 요청이 이어진다. VPN은 두 교환을 모두 나르는 경로를 바꾸고 중간 서비스의 응답을 바꿀 수 있다. 그러나 오리진 문자열이나 프리플라이트 요구는 바꾸지 않는다.

명령줄 클라이언트는 보통 그중 아무것도 보여주지 않는다. Origin 헤더를 보내지 않을 수 있고, 프리플라이트를 자주 생략하며, 다른 자격 증명을 담을 수 있다. curl에 반환된 본문은 서버가 curl에 응답했다는 증거일 뿐이다.

바뀐 응답을 찾아라

상태 코드만이 아니라 각 경로의 실제 응답을 비교하라. CORS 권한을 담은 헤더, 콘텐츠 타입, 모든 리다이렉트, WAF나 CDN 변형이 다른 페이지를 만들었는지 살펴라. 지역적 거부, 인증 리다이렉트, 권한 헤더가 없는 오류 페이지는 모두 브라우저에서 실패하지만 CORS 버그처럼 보인다. 그것은 전달 경로의 차이이며, 기록해야 할 대상이다.

두 경로의 응답 헤더를 캡처해 줄마다 비교하라. 유일한 차이가 한 오류 페이지에서 Access-Control-Allow-Origin이 빠진 것이라면 원인을 찾은 것이다.

적용이 아니라 서비스를 고쳐라

서비스가 당신 것이라면 허용된 오리진과 요청 기능을 명시하고, 그 프런트엔드와 중개자가 만드는 오류를 읽어라. 그렇지 않다면 서비스 소유자에게 정제된 비교를 보내라. 그 보고서에 쿠키, 인증 헤더, 세션 내보내기를 절대 포함하지 마라. 정책은 그 자격 증명을 보호하기 위해 존재한다.

CORS를 끄는 브라우저 확장 프로그램을 피하라. 그것은 보안 경계를 바꾸면서 설명해야 할 응답 차이를 숨기고, 다른 모든 사용자에게 같은 실패를 남긴다.

두 응답, 사용한 오리진, 지나온 경로를 기록하라. 그 기록이 VPN 소문을 서비스 버그로 바꾼다.