FileSystem: Reject opaque filesystem URLs in security policy

자식 프로세스의 URL 요청과 탐색 commit 검사에서 opaque origin을 가진 filesystem: URL을 거절하도록 변경했습니다. 정상적으로 생성 가능한 opaque blob: URL의 허용 동작은 유지하면서 두 URL 유형의 정책을 구분합니다.

문제 설명

기존 ChildProcessSecurityPolicyImpl::CanRequestURL()은 blob:과 filesystem: URL을 같은 분기에서 처리했습니다. 내부 출처가 opaque이면 바로 허용하고, 그렇지 않으면 내부 출처를 기준으로 요청 권한을 다시 검사했습니다. CanCommitURL()에도 같은 형태의 조건이 있었습니다.

하지만 두 유형은 생성 가능한 조건이 다릅니다. 샌드박스 또는 data: 문서처럼 opaque origin을 가진 문서도 Blob URL은 만들 수 있지만, FileSystem API는 opaque origin의 접근을 허용하지 않습니다. 두 유형에 같은 예외를 적용할 이유가 없었습니다.

리뷰에서는 정상적인 filesystem: URL의 내부 스킴과 백엔드 지원 범위도 검토했습니다. 특히 filesystem:file:의 출처는 url::Origin에서 opaque로 취급되지 않으므로, 이번 제한과 구분해야 합니다.

해결 내용

CanRequestURL()에서 내부 출처가 opaque이면 url.SchemeIsBlob()의 결과를 반환합니다. Blob URL은 허용하고 파일 시스템 URL은 거절하도록 공통 허용 조건을 구분했습니다.
CanCommitURL()에도 같은 구분을 적용했습니다. opaque 파일 시스템 URL을 거절할 때는 opaque_filesystem_url을 실패 사유로 기록합니다. 요청이 허용되지 않는 URL을 탐색 commit 검사에서 허용하던 불일치도 방지합니다.
opaque가 아닌 URL은 기존처럼 내부 출처를 대상으로 CanRequestURL() 또는 CanCommitURL()을 재귀 호출합니다. 기존 URL 유효성 검사와 잘못된 Blob URL의 거절 처리도 유지합니다.

테스트 방법

child_process_security_policy_unittest.cc에 OpaqueBlobAndFileSystemSchemeTest를 추가했습니다. 두 URL이 유효하고, 출처가 모두 opaque임을 먼저 확인한 뒤 같은 렌더러 프로세스에서 요청과 탐색 commit 권한을 각각 검사합니다.

URL	요청 허용	탐색 commit 허용
`blob:null/some-guid`	허용	허용
`filesystem:chrome-error://chromewebdata/temporary/a.gif`	거절	거절

유효한 opaque 파일 시스템 URL을 사용하므로, URL 문법 검사 때문에 실패한 것과 새 출처 정책 때문에 거절된 것을 구분할 수 있습니다.

Gerrit 기록상 Patch Set 3은 2026년 10월 2일 UTC에 CQ 실행을 통과했습니다. 위 내용은 최종 패치와 Gerrit 기록을 기준으로 정리했으며, 보고서 작성 과정에서 Chromium 테스트를 별도로 실행하지는 않았습니다.

배운 점

내부에 출처를 포함하는 URL이라도 스킴별 생성 규칙이 다르면 같은 예외를 적용해서는 안 됩니다.
요청을 허용하는 정책과 탐색 commit을 허용하는 정책을 함께 살펴야 검사 사이의 불일치를 발견할 수 있습니다.
URL 문법의 유효성과 출처의 opaque 여부는 별개의 조건입니다. 정상적인 file: 출처까지 제한하지 않도록 기존 동작도 확인해야 합니다.