Chrome 124에는 혼합 콘텐츠를 완화하기 위한 비공개 네트워크 액세스 권한 기능이 포함되어 있습니다. 이 변경사항에 대비하는 데 시간이 더 필요한 사이트를 대상으로 지원 중단 무료 체험판이 진행 중이지만, 이 무료 체험판은 2025년 2월 4일에 출시될 예정인 Chrome 132에서 종료됩니다. 이 게시물에서는 변경사항, 기능 설계, 현재 웹사이트를 이전하는 방법, 구현을 테스트하는 방법을 자세히 설명합니다.
어떤 점이 달라지나요?
전역적으로 고유한 이름이 없으므로 TLS 인증서를 가져올 수 없는 비공개 네트워크의 기기에 연결하려면 이 기능을 통해 fetch()에 새로운 옵션을 도입하여 개발자가 이러한 기기와 통신할 의도를 선언합니다. 여기에는 각 사이트의 이 기능 액세스를 제어하는 새로운 정책 제어 기능과 추가 메타데이터를 제공하는 서버의 사전 비행 응답을 위한 새로운 헤더가 포함됩니다.
비공개 네트워크 액세스란 무엇인가요?
비공개 네트워크 액세스 (PNA, 이전 명칭: CORS-RFC1918, 간단히 로컬 네트워크 액세스)는 웹사이트가 비공개 네트워크의 서버에 요청을 전송하는 기능을 제한하는 보안 기능입니다. 이를 통해 Cross-Site Request Forgery (CSRF)와 같은 잠재적인 공격으로부터 사용자와 내부 네트워크를 보호할 수 있습니다. Chrome은 PNA를 점진적으로 구현하고 있으며 향후 출시에서 보호 기능이 확대될 예정입니다.
권한 메시지가 필요한 이유는 무엇인가요?
Chrome 94에서는 안전하지 않은 공개 웹사이트에서 비공개 네트워크에 액세스하는 것을 차단하는 기능을 도입했습니다. 진행 중인 안전하지 않은 컨텍스트에서의 비공개 네트워크 액세스 지원 중단 체험판으로 인해 영향을 받는 웹사이트를 HTTPS로 이전하는 데 어려움이 있음이 드러났습니다. 일반적인 우려사항은 비공개 기기를 HTTPS로 이전하기가 어렵고 이로 인해 혼합 콘텐츠 확인 위반이 발생한다는 점입니다.
이 문제를 해결하기 위해 Chrome 120의 오리진 트라이얼에 새로운 권한 메시지가 추가되었으며 Chrome 124의 안정화 버전에서는 이 메시지가 추가되었습니다.
권한 메시지는 언제 필요한가요?
Google에서는 권한 메시지 기능이 출시된 후 몇 가지 주요 시점 이후에 비보안 컨텍스트 지원 중단 기능 트라이얼을 종료할 계획입니다. 호환성을 보장하려면 공개 웹사이트를 HTTPS로 이전해야 합니다. 비공개 서버를 HTTPS로 이전할 수 없는 경우 새로운 권한 메시지 기능을 사용하면 혼합 콘텐츠 검사를 완화할 수 있습니다.
권한 메시지가 표시되는 비공개 네트워크 액세스 요청의 일반적인 워크플로는 다음과 같습니다.
권한 메시지 트리거
새 targetAddressSpace 속성을 가져오기 옵션으로 추가하면 요청에서 혼합 콘텐츠 검사를 건너뛸 수 있습니다.
fetch("http://router.local/ping", {
targetAddressSpace: "private",
});
비공개 네트워크 액세스: 프리플라이트 도입에 따라 모든 비공개 네트워크 요청이 프리플라이트 요청이 선행됩니다. 이 사전 비행 요청에는 새 헤더 Access-Control-Request-Private-Network: true가 포함되며 상응하는 응답에는 Access-Control-Allow-Private-Network: true 헤더가 포함되어야 합니다.
새 권한 메시지를 수용하려면 기기에서 두 가지 새 응답 헤더인 Private-Network-Access-Name 및 Private-Network-Access-ID를 통합해야 합니다.
Private-Network-Access-ID: 48비트 값이며 6개의 16진수 바이트로 콜론으로 구분됩니다.Private-Network-Access-Name: ECMAScript 정규 표현식/^[a-z0-9_-.]+$/.과 일치하는 유효한 이름(문자열)입니다. 이름의 최대 길이는 248개 UTF-8 코드 단위입니다.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"
데모
데모는 https://private-network-access-permission-test.glitch.me/에서 확인할 수 있습니다.
데모 웹사이트를 사용하려면 개인 비공개 서버를 시작해야 합니다. 비공개 서버는 서버 지정 헤더 Private-Network-Access-ID 및 Private-Network-Access-Name와 함께 HTTP 헤더 Access-Control-Allow-Private-Network: true로 응답해야 합니다. 모든 것이 올바르게 설정되면 다음과 같은 권한 메시지가 표시됩니다.
비보안 컨텍스트 지원 중단 기능 트라이얼 종료
비보안 컨텍스트용 비공개 네트워크 액세스 지원 중단 체험판을 등록한 웹사이트의 경우 이제 새 권한 메시지를 사용하여 웹사이트를 이전하고 체험판을 종료해야 합니다.
코드를 업데이트한 후 HTML, JavaScript 또는 HTTP 헤더에서 무료 체험판 토큰을 삭제합니다. 평가 토큰을 어디에 넣었는지 기억나지 않으면 이전 블로그 게시물의 지원 중단 체험판 등록 섹션을 참고하세요.
체험판 페이지에서도 토큰을 삭제하는 것이 좋습니다.
다음 단계
API가 아닌 fetch()의 요청을 위한 솔루션은 아직 연구 중입니다.
서비스 워커를 사용하거나 타겟 주소 공간을 새 Content-Security-Policy로 만드는 등 여러 솔루션이 테스트되었습니다. 하지만 API가 아닌 fetch()의 요청에 대한 최종 형식은 아직 조사 중입니다.
하위 프레임의 요청은 향후 권한 정책으로 지원될 수 있습니다.
향후 하위 프레임의 기능을 완화하기 위해 권한 정책을 지원할 수 있습니다.
비공개 네트워크 사용 사례에 관한 의견
공용 네트워크의 요청이 필요한 비공개 네트워크에서 웹사이트를 호스팅하는 경우 Chrome팀에 의견을 보내주세요. Chromium Issue Tracker(구성요소: Blink>SecurityFeature>CORS>PrivateNetworkAccess) 또는 GitHub 저장소에서 문제를 신고합니다.