Chrome 152에 웹 애플리케이션의 네트워크 연결을 허용 목록으로 제한하는 기능이 들어갔다. 서버가 응답 헤더로 허용할 주소를 지정하면 브라우저가 연결을 검사하고, 목록에 없는 목적지는 차단한다. 생성형 인공지능이 만든 코드나 외부 스크립트를 실행하는 웹 앱에서 데이터 유출을 막으려는 팀이 활용할 수 있다.
연결 허용 목록은 어떻게 작동하나?
연결 허용 목록은 브라우저를 웹페이지에서 시작되는 모든 네트워크 연결의 문지기로 삼는 보안 기능이다. 건물 출입 명단을 떠올리면 쉽다. 브라우저는 연결을 만들기 전에 목적지가 목록에 있는지 확인하고, 없으면 네트워크 단계에서 막는다.
콘텐츠 보안 정책(Content Security Policy, CSP)은 페이지가 무엇을 불러오고 실행할지 통제하지만, 페이지가 어디와 통신할지를 제한하는 용도로 설계되지는 않았다. 요청 유형별 정책을 세워야 하는 세밀함도 있다. 또 DNS 미리 가져오기, 페이지 이동, 웹 실시간 통신(WebRTC) 등 모든 웹 플랫폼 API를 빠짐없이 다루지 않는다.
연결 허용 목록은 Fetch와 다른 웹 플랫폼 API를 통해 시작되는 통신의 허용 주소를 Connection-Allowlist HTTP 응답 헤더로 지정한다. 정책은 표준화된 URLPattern 문법을 사용하며, 창이나 작업자(worker)마다 별도로 적용된다. 기존 CSP 설정을 대체하기보다 함께 쓰는 보완책으로 사용할 수 있다.
서버 응답에 어떤 헤더를 넣나?
응답이 제공된 출처를 허용 목록에 동적으로 추가하려면 response-origin 토큰을 쓸 수 있다. 특정 API 주소도 함께 허용하는 기본 설정은 다음과 같다.
Connection-Allowlist: ("https://api.example.com/*" response-origin)
기본적으로 목록은 리디렉션과 WebRTC 연결을 차단한다. 리디렉션이 발생하는 요청은 명시적으로 허용하지 않으면 막힌다. 두 항목을 허용하려면 다음처럼 설정한다.
Connection-Allowlist: ("https://api.example.com/*"); redirects=allow; webrtc=allow
서비스를 중단하지 않고 위반 가능성을 살피려면 보고 전용 모드(report-only mode)를 사용할 수 있다. 이 모드에서는 정책을 해석하고 지정한 보고 엔드포인트(reporting endpoint)로 위반 보고서를 보내지만 연결을 차단하지는 않는다. 선택한 엔드포인트 이름을 실제 URL에 연결하도록 Reporting-Endpoints HTTP 응답 헤더도 설정해야 한다.
Connection-Allowlist-Report-Only: ("https://trusted.com/*"); report-to=security-endpoint
어떤 상황에서 쓸 만한가?
생성형 인공지능이 만든 사용자 인터페이스나 개발용 샌드박스처럼 신뢰할 수 없는 코드를 실행하는 앱에서는 코드가 외부 도메인으로 데이터를 보내지 못하게 제한할 수 있다. 제3자 스크립트나 웹 게임이 침해되더라도 승인되지 않은 서버로 데이터를 보내지 못하도록 감시할 때도 쓸 수 있다. 민감한 앱 영역의 통신을 승인된 백엔드로만 한정하는 아키텍처 보호 장치로도 활용할 수 있다.
이 기능은 Chrome 152부터 공식 제공된다. 개발 중에는 로컬 개발 서버가 Connection-Allowlist 응답 헤더를 보내도록 설정한 뒤, Chrome 개발자 도구의 네트워크 패널에서 차단된 요청을 확인하면 된다. 헤더 파싱에 관한 자세한 보고는 문제 탭에서 확인할 수 있다.
원문은 연결 허용 목록 명세, WICG GitHub 저장소, ChromeStatus 항목을 안내한다. 원문은 위반 보고서의 구체적인 형식과 Reporting-Endpoints 설정 예시는 제시하지 않는다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요