Chrome Connection Allowlists 실험: 웹 데이터 유출 경계를 다시 그리는 법
Chrome이 2026년 4월 발표한 Connection Allowlists 오리진 트라이얼의 범위와 한계를 짚고, 한국 웹서비스가 기존 CSP와 함께 안전하게 시험하는 방법을 제안합니다.
먼저 읽는 세 줄
- Connection Allowlists는 연결 목적지를 기본 거부하는 실험적 브라우저 경계이며 CSP나 서버 egress 통제를 대체하지 않는다.
- 민감 페이지의 실제 외부 연결을 보고 전용으로 관측하고 공급자·데이터·소유자를 매핑한 뒤 작은 범위에서 강제해야 한다.
- WICG 초안은 W3C 표준이 아니므로 미지원 브라우저, 워커 범위, 명세 변경을 전제로 기존 방어선과 롤백을 유지해야 한다.
Chrome 팀은 2026년 4월 16일 웹 문서의 외부 네트워크 연결을 허용 목록으로 제한하는 Connection Allowlists 오리진 트라이얼을 발표했다. 핵심 아이디어는 응답 헤더에 허용 목적지를 적고, 일치하지 않는 연결을 브라우저 네트워크 계층에서 기본 차단하는 것이다. 한국 웹서비스 운영자는 이를 콘텐츠 보안 정책(CSP)의 즉시 대체재로 보면 안 된다. 현재는 실험 기능이며 지원 범위가 변하고 있으므로, 민감 페이지에서 실제 데이터 흐름을 먼저 발견하고 보고 전용 방식으로 오탐을 줄인 뒤 제한된 파일럿으로 검증해야 한다.
확인된 사실: Chrome 공식 발표는 Connection-Allowlists가 문서와 워커를 위한 네트워크 샌드박스를 목표로 하며, 오리진 트라이얼은 Chrome 148부터 151까지 예정됐다고 설명한다. 발표 당시 트라이얼의 보고 기능은 문서 컨텍스트만 지원하고 Dedicated·Shared·Service Worker는 지원하지 않는다.
POEMORA 해석: 이 기능은 제3자 스크립트가 침해됐을 때 허가되지 않은 서버로 정보를 보내는 경로를 줄일 가능성이 있지만, 서버 측 유출·허용된 분석 도메인의 오용·다른 브라우저 사용자는 별도 통제로 다뤄야 한다.
무엇이 새롭고 무엇이 아직 실험인가
사실. 사이트는 Connection-Allowlist 응답 헤더에 허용할 URL 패턴을 지정할 수 있다. 브라우저는 하위 리소스 요청, 리디렉션, WebSocket 등 연결 목적지를 허용 목록과 비교해 맞지 않으면 네트워크 단계에서 차단한다. Chrome 문서는 Fetch뿐 아니라 WebRTC, WebTransport, DNS prefetch, preload 같은 여러 웹 플랫폼 연결을 하나의 경계로 다루는 목표를 설명한다.
사실. WICG 문서는 계속 갱신되는 Draft Community Group Report이며, 2026년 9월 12일 검토 당시 표지 날짜는 2026년 8월 26일이었습니다. W3C 표준이나 표준 트랙 문서는 아닙니다. 명세에는 iframe이 하위 문서에 요구할 허용 목록을 전달하는 방향과 리디렉션·WebRTC 관련 설계가 포함돼 있지만, 논의 중인 항목도 남아 있다.
POEMORA 해석. 제품 로드맵에는 “도입 완료”가 아니라 “브라우저 실험”으로 기록해야 한다. 보안 정책의 강제력을 이 기능 하나에 의존하면 지원하지 않는 브라우저와 워커에서 보호가 비어 버린다. 기존 CSP, 서버 측 송신 제어, 서브리소스 무결성, 의존성 검토를 유지하면서 추가 방어선으로 평가해야 한다.
CSP와 경쟁시키지 말고 역할을 분리한다
CSP는 스크립트·이미지·프레임 등 자원 유형별 로드와 실행을 세밀하게 통제한다. 반면 Connection Allowlists는 페이지가 통신할 수 있는 목적지 경계를 더 단순하고 포괄적으로 표현하려는 접근이다. 두 정책의 문법과 적용 지점이 다르므로 “새 헤더를 넣었으니 CSP를 지운다”는 전환은 위험하다.
POEMORA 해석. 운영 모델은 세 층으로 나누는 편이 명확하다. 첫째, CSP로 실행 가능한 코드와 자원 출처를 줄인다. 둘째, Connection Allowlists 실험으로 브라우저에서 나갈 수 있는 연결 목적지를 좁힌다. 셋째, 서버와 클라우드 네트워크에서도 외부 송신을 제한한다. 이 구조라면 한 계층이 지원되지 않거나 우회돼도 다른 계층이 남는다.
정책을 만들 때는 도메인 전체를 넓게 허용하기보다 기능별 경로와 소유자를 적는다. 결제, 오류 추적, 분석, 고객지원 위젯, CDN이 각각 왜 필요한지 기록하고 계약 종료나 SDK 제거 시 허용 목록도 함께 삭제한다. 웹 공급망과 보안 헤더를 함께 정리하려면 웹 개발·운영 지원에서 실제 요청 지도를 기준으로 범위를 잡을 수 있다.
보고 전용 관측으로 실제 연결 지도를 만든다
Chrome 발표는 위반을 모니터링하기 위한 Connection-Allowlist-Report-Only 헤더와 Reporting API 사용 방향을 소개한다. 강제 전에 보고 데이터를 모으면 문서에 없는 이미지 프록시, 인증 리디렉션, 지역별 CDN, 장애 시 폴백처럼 정상인데 누락된 연결을 찾을 수 있다.
도입 순서는 다음처럼 보수적으로 잡는다.
- 로그인, 결제, 관리자, 파일 업로드 등 민감 페이지를 우선 선정한다.
- 개발·스테이징에서 네트워크 요청과 리디렉션 목적지를 수집한다.
- 목적지마다 기능, 데이터 유형, 공급자, 계약 소유자, 보존 정책을 연결한다.
- 보고 전용 위반을 정상·오설정·의심 유출로 분류한다.
- 미지원 브라우저의 기존 통제가 유지되는지 확인한 뒤 작은 사용자군에서 강제한다.
보고 엔드포인트 자체에도 개인정보 최소화가 필요하다. 전체 URL의 쿼리 문자열이나 사용자 식별자가 그대로 들어오지 않는지 확인하고, 접근 권한과 보존 기간을 제한한다. 위반 수를 줄이기 위해 허용 목록을 넓히는 대신 실제로 불필요한 SDK와 연결을 제거하는 것이 먼저다.
제3자 스크립트와 생성 코드에 적용할 판단 기준
공식 발표는 침해된 제3자 스크립트와 생성형 AI가 만든 비신뢰 코드를 주요 사용 사례로 든다. 그러나 허용 목록에 분석 또는 고객지원 공급자 도메인이 포함돼 있다면 악성 코드가 그 허용 경로를 악용할 가능성은 남는다. 목적지 제한은 전송 내용의 정당성까지 판정하지 않는다.
따라서 제3자 스크립트에는 최소 로드, 지연 로드, 권한 분리, 데이터 필드 제한, 공급자 변경 감시를 함께 적용한다. 사용자가 만든 코드나 AI 생성 코드를 실행하는 서비스는 별도 origin과 샌드박스, 짧은 수명의 자격 증명, 서버 측 egress 제한이 필요하다. 브라우저 헤더는 격리 구조를 보강할 뿐 대체하지 않는다.
| 위험 | Connection Allowlists의 역할 | 남는 통제 |
|---|---|---|
| 미승인 도메인으로 전송 | 브라우저 연결 차단 가능 | 미지원 브라우저와 서버 egress |
| 허용된 공급자 오용 | 목적지 경계만 제공 | 필드 최소화와 공급자 접근 통제 |
| 악성 스크립트 실행 | 직접 실행 통제는 아님 | CSP, 무결성, 의존성 관리 |
| 워커·향후 명세 변화 | 발표 시 지원 제한 존재 | 기능 탐지와 회귀 테스트 |
한국 서비스의 도입 결정은 세 가지 증거로 내린다
첫 번째 증거는 자산 지도다. 페이지별 외부 연결, 데이터 유형, 공급자 책임자가 연결돼 있어야 한다. 두 번째는 호환성·오탐 결과다. 지원 브라우저 비율만 보지 말고 핵심 고객 여정이 정책 때문에 실패하지 않는지 확인한다. 세 번째는 사고 억제 결과다. 테스트용 미승인 수집 서버로 정보 전송을 시도해 브라우저, CSP, 서버 계층 중 어디에서 실제로 막히는지 기록한다.
POEMORA 해석. 이 세 가지를 충족하면 제한된 민감 화면에서 실험할 가치가 있다. 반대로 현재 연결 목적지를 설명하지 못하거나 CSP조차 넓은 와일드카드로 운영한다면 새 헤더 등록보다 자산 정리부터 해야 한다. 명세가 W3C 표준이 아니고 구현 범위가 변할 수 있다는 사실을 사용자 보호 계획과 롤백 조건에 분명히 남기는 것이 안전하다.
자주 묻는 질문
Connection Allowlists를 적용하면 CSP를 제거해도 되나요?
아닙니다. Chrome 공식 문서는 두 기능을 상호 보완적으로 설명합니다. CSP는 자원 로드와 실행을 세밀하게 통제하고, Connection Allowlists는 연결 목적지 경계를 다루므로 기존 CSP와 서버 측 송신 통제를 유지해야 합니다.
지금 모든 운영 사용자에게 바로 강제할 수 있나요?
오리진 트라이얼이자 발전 중인 기능이므로 즉시 전면 의존하는 것은 위험합니다. 개발 환경과 보고 전용 관측으로 누락된 정상 연결을 찾고, 미지원 브라우저의 보호와 롤백 절차를 확인한 뒤 제한적으로 시험해야 합니다.
제3자 스크립트의 데이터 유출을 완전히 막아 주나요?
미승인 목적지로의 연결을 줄일 수 있지만 완전한 방지는 아닙니다. 악성 코드가 이미 허용된 공급자 도메인을 악용할 수 있으므로 수집 필드 최소화, CSP, 무결성 검증, 공급자 권한 통제가 함께 필요합니다.
보고 데이터를 수집할 때도 개인정보 검토가 필요한가요?
필요합니다. 위반 보고에 전체 URL, 쿼리 문자열, 사용자 식별자가 포함될 가능성을 점검하고 수집 항목·접근 권한·보존 기간을 최소화해야 합니다. 보고 시스템 자체가 새로운 개인정보 저장소가 되지 않게 해야 합니다.
