Permissions-Policy 헤더 빌더

Permissions-Policy는 브라우저에게 이 페이지와 그 안의 프레임이 어떤 강력한 기능을 쓸 수 있는지 알려 줍니다. 기능을 고르고 완전히 차단할지, 자기 출처에만 허용할지, 어디서든 허용할지, 직접 적은 목록으로 제한할지 선택합니다. 기능은 범주별로 묶여 있어서 잠그려던 것을 찾기 쉽고, 임베드된 모든 출처에 권한을 넘겨주는 형태나 허용 목록 항목에서 스킴이 빠진 경우에는 경고가 표시됩니다.

문법은 보기보다 간결하고, 미묘하게 틀리기도 쉽습니다. 빈 목록은 자기 페이지를 포함해 어디에서든 기능을 끕니다. camera=()는 "기본값"이 아니라 "아무도 안 됨"입니다. (self)는 최상위 문서와 동일 출처 프레임을 허용하고, *는 아무 출처나 허용하며, 지정 출처는 괄호 안에 따옴표로 감싸 스킴까지 포함해 적습니다 — geolocation=(self "https://maps.example.com"). 따옴표나 https://를 빠뜨려도 오류가 나지 않습니다. 그 항목이 그냥 이해되지 않을 뿐이고, 결과적으로 기능은 의도한 것보다 더 막히게 됩니다.

사람들이 걸려 넘어지는 지점은 이 헤더가 유일한 관문이 아니라는 사실입니다. 교차 출처 iframe에는 <iframe> 요소 자체에 붙는 allow 속성도 필요하고, 둘은 교집합으로 작동합니다. 헤더가 무엇을 허용하든, 임베드하는 태그가 요청하지 않으면 그 프레임은 아무것도 얻지 못합니다. 그래서 응답에 camera=(self "https://widget.example")이 있고 태그에 allow="camera"가 없으면, 카메라가 안 되는 위젯과 그 이유를 알 수 없는 상황이 만들어집니다. 양쪽이 모두 동의해야 합니다.

알아 둘 것이 둘 더 있습니다. 철자가 틀린 기능 이름은 거부되지 않고 조용히 무시되므로, 오타가 있는 정책은 아무것도 보호하지 않으면서 아무것도 알려 주지 않습니다. 작성한 헤더를 믿지 말고 브라우저 개발자 도구에서 실제로 적용된 정책을 확인하세요. 그리고 이 헤더는 공백으로 구분하는 다른 문법을 쓰던 Feature-Policy를 대체한 것입니다. 블로그 글에서 복사해 온 옛 예제는 요즘 브라우저에서 아무것도 아닌 것으로 파싱되는데, 이 역시 조용히 실패합니다.