AI 생성 UI의 외부 전송, CSP에 무엇을 더할까

세 줄 요약

Chrome 152부터 Connection-Allowlist로 문서·워커의 연결 목적지를 제한할 수 있다.
CSP의 스크립트 보호를 유지하면서, AI 생성 코드를 실행하는 별도 iframe에 통신 제한을 추가하는 방식이다.
리디렉션과 WebRTC는 기본 차단되며, 보고 전용 모드는 연결을 막지 않는다.

CSP는 유지하고 연결 목적지 제한을 더한다

AI가 만든 HTML·React 화면을 앱 안에서 실행한다면, Connection-Allowlist를 해당 문서의 HTTP 응답에 추가해 연결 가능한 주소를 제한할 수 있다. Chrome 152부터 제공되는 기능으로, 서버가 정한 URL 패턴에 맞지 않는 연결을 브라우저가 막는다.

이미 CSP를 쓰고 있어도 역할을 구분할 필요가 있다. CSP의 connect-src는 fetch, XMLHttpRequest, WebSocket, sendBeacon 같은 스크립트 인터페이스의 목적지를 제한한다. CSP가 외부 통신에 아무 효과가 없는 것은 아니다.

차이는 요청 유형을 넘어 연결 목적지를 한 정책으로 관리한다는 데 있다. Connection Allowlists 명세는 탐색, DNS 프리페치, WebRTC 등도 범위에 넣는다. 반면 코드 삽입이나 XSS 자체를 막는 기능은 아니다. CSP의 스크립트 실행 제한을 지우고 새 헤더 하나로 대체할 이유는 없다.

정책은 앱 전체보다 생성 UI 문서에 먼저 적용한다

Chrome의 도입 안내는 신뢰할 수 없는 코드를 전용 iframe에 격리하고 그 문서에 헤더를 적용하도록 권한다. 메인 앱의 정상 요청까지 막는 일을 줄이고, 생성 코드에 필요한 통신만 좁혀 허용하기 위한 구성이다.

단순히 iframe 태그로 감싸는 것만으로는 부족하다. 부모와 다른 출처를 쓰거나 샌드박스로 격리해야 한다. 정책이 약한 동일 출처 문맥에 스크립트로 접근할 수 있으면 그쪽을 통해 제한을 벗어날 여지가 있다. 명세도 이 정책이 출처 전체가 아니라 문서·워커 같은 개별 실행 문맥에 적용된다고 설명한다.

다음은 헤더 문법 예시다. 응답을 제공한 출처와 지정한 API 주소를 허용한다.

Connection-Allowlist: (response-origin "https://api.example.com/*")

response-origin은 해당 응답의 출처를 뜻하며, 인용부호 안의 값은 URLPattern 문법이다. 허용한 서버로는 데이터가 갈 수 있으므로 목록에 넣는 주소 자체가 중요한 결정이다. 부모가 자식의 메시지를 받아 대신 API를 호출하는 구조라면 메시지 내용도 별도로 검증해야 한다. 이 헤더가 postMessage의 내용까지 검증하지는 않는다.

리디렉션 허용은 후속 목적지까지 허용하는 선택이다

정책을 켜면 리디렉션과 WebRTC는 기본적으로 차단된다. 목록에 있는 API에 요청했더라도 서버가 다른 주소로 보내는 응답을 반환하면 막힐 수 있다. 로그인·결제처럼 주소가 바뀌는 흐름은 이 차이가 드러나는 지점이다.

특히 명세의 리디렉션 설명에 따르면 redirects=allow를 붙였을 때 목록 검사는 최초 요청에만 적용된다. 그 요청이 허용되면 후속 리디렉션은 목적지와 관계없이 허용된다. ‘허용한 도메인 안에서만 이동한다’는 설정으로 읽으면 안 된다.

webrtc=allow 역시 WebRTC 연결을 허용하는 별도 선택이다. 정상 기능을 복구하려고 두 옵션을 함께 켜기 전에 어떤 흐름에 필요한지 나눠 판단해야 한다. 브라우저의 목적지 제한과 허용된 서버가 다시 데이터를 보내는 행위도 구분해야 한다.

보고 전용으로 필요한 연결부터 파악한다

처음에는 Connection-Allowlist-Report-Only로 예상 위반을 수집할 수 있다. 다음은 보고 endpoint를 함께 지정한 예시이며, 실제 보고 수신 서버와 API 주소로 바꿔야 한다.

Reporting-Endpoints: network="https://reports.example/ingest"
Connection-Allowlist-Report-Only: (response-origin "https://api.example.com/*"); report-to=network

이 상태는 보고만 하며 연결을 차단하지 않는다. 필요한 요청과 리디렉션을 확인한 뒤 차단용 Connection-Allowlist로 전환해야 실제 제한이 생긴다. Chrome은 DevTools의 Network 패널에서 차단 요청을, Issues에서 헤더 파싱 문제를 확인하도록 안내한다.

명세는 2026년 10월 기준 WICG 초안이며 W3C 표준이 아니다. Chrome에서 제공된다는 사실을 모든 브라우저의 동일한 보호로 확대할 수는 없다. 생성 UI를 격리하고 CSP를 유지한 채, 지원 브라우저에서 연결 제한을 추가하는 구성이 도입의 출발점이다.