본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.
Permissions-Policy 설정 기준 정리
Permissions-Policy는 문서와 그 안에 포함된 iframe에서 어떤 브라우저 기능과 API를 사용할 수 있는지 서버가 제어하는 HTTP 응답 헤더다. 2026년 5월 20일 기준 MDN과 W3C Permissions Policy 문서를 보면, 카메라, 마이크, 위치 정보, 전체화면, 결제 API처럼 민감하거나 강한 권한이 필요한 기능을 origin 단위 allowlist로 제어할 수 있다.
이 헤더는 보안 헤더처럼 취급되지만, 실제로는 권한 노출 범위와 임베드된 서드파티의 기능 사용 범위를 조정하는 정책 도구에 가깝다. 이 글은 공식 문서 기준으로 Permissions-Policy가 무엇을 제어하는지, iframe allow와 어떻게 함께 동작하는지, 그리고 운영에서 어떤 기준으로 값을 정하면 되는지를 객관적인 사실만으로 정리한다.
Permissions-Policy는 정확히 무엇을 제어할까?
MDN은 Permissions-Policy를 문서와 그 문서 안의 iframe에서 브라우저 기능 사용을 허용하거나 차단하는 응답 헤더로 설명한다. 정책이 기능을 막으면 관련 JavaScript API는 권한 요청 창이 뜨기 전에 거부되거나, false를 반환하거나, 아예 노출되지 않을 수 있다.
이 헤더는 모든 브라우저 기능을 한 번에 다루는 것이 아니라, 정책 제어 대상(feature)별로 각각 선언한다. 예를 들어 geolocation, camera, microphone, fullscreen, payment, autoplay 같은 directive가 따로 존재한다.
Feature Policy와는 무엇이 다를까?
MDN은 Permissions Policy가 과거의 Feature Policy에서 이름과 헤더 문법이 바뀐 형태라고 설명한다. 따라서 오래된 문서나 예제에는 Feature-Policy 헤더가 남아 있을 수 있지만, 현재 문서 기준으로는 Permissions-Policy와 현재 문법을 기준으로 보는 편이 맞다.
반면 iframe의 allow 속성 문법은 계속 유지되고 있다. 실무에서는 예전 블로그 글의 구문을 그대로 복사하기보다, 최신 문서 기준으로 header와 allow 속성 표현을 다시 확인하는 편이 안전하다.
헤더와 iframe allow는 어떻게 함께 동작할까?
MDN은 권한 정책을 지정하는 방법을 두 가지로 구분한다. 하나는 응답 전체와 그 안의 임베드 콘텐츠에 영향을 주는 Permissions-Policy 헤더이고, 다른 하나는 특정 iframe에만 적용되는 allow 속성이다.
공식 문서 기준으로 특정 iframe에서 기능을 쓰려면 부모 문서의 헤더 allowlist에도 그 origin이 허용되어 있어야 한다. 그래서 상위 문서 헤더에서는 허용 가능한 최대 범위를 정하고, 실제 각 iframe에서는 allow 속성으로 더 좁은 범위를 지정하는 방식이 일반적이다.
allowlist 문법은 어떻게 읽어야 할까?
MDN은 헤더 allowlist가 괄호 안의 값으로 구성된다고 설명한다. 대표적인 값은 다음과 같다.
*: 모든 origin과 모든 하위 browsing context에서 허용한다.(): top-level 문서와 하위iframe모두에서 비활성화한다.self: 현재 문서와 same-origin 하위 문서에서만 허용한다.- 명시적 origin 목록: 예를 들어
("https://player.example.com")처럼 특정 origin만 허용한다.
iframe allow에서는 src가 기본값으로 쓰인다. 즉 별도 origin을 적지 않으면 그 iframe의 src와 같은 origin에서 로드된 문서에 대해서만 해당 기능을 허용하는 방식으로 해석된다.
기본값을 믿어도 될까?
이 질문의 핵심은 feature마다 기본 allowlist가 같지 않다는 점이다. MDN은 directive마다 기본 allowlist가 *, self, none 중 하나로 정해진다고 설명한다. 따라서 어떤 기능은 헤더를 쓰지 않아도 동작할 수 있고, 다른 기능은 기본적으로 더 엄격하게 제한될 수 있다.
그래서 Permissions-Policy를 운영 기준으로 잡을 때는 "기본값이 무엇인가"보다 "내가 실제로 허용하고 싶은 기능이 무엇인가"를 먼저 정하는 편이 낫다. 특히 서드파티 iframe를 많이 쓰는 서비스라면, 명시적으로 필요한 기능만 열어 주는 구성이 더 예측 가능하다.
보통 어떤 상황에서 설정을 검토할까?
1. 서드파티 iframe이 카메라나 위치 정보를 요구할 때
영상회의, 본인확인, 지도, 결제, 광고, 분석 도구처럼 외부 origin의 iframe가 민감한 API를 쓰는 경우가 대표적이다. 이때는 부모 문서 헤더와 해당 iframe의 allow 속성이 함께 맞아야 하므로, 허용 범위를 문서화해 두는 편이 좋다.
2. 강한 권한 API를 기본적으로 막고 싶을 때
서비스에서 카메라, 마이크, 위치 정보, 결제 API를 전혀 쓰지 않는다면, 관련 directive를 빈 allowlist로 두는 구성이 가능하다. 공식 문서가 설명하는 효과는 단순하다. 기능이 정책 단계에서 막히므로, 브라우저는 사용자를 대상으로 한 권한 요청 자체를 진행하지 않거나 API 호출을 즉시 거부할 수 있다.
3. 임베드 파트너별로 허용 기능을 다르게 줘야 할 때
예를 들어 한 파트너는 전체화면만 필요하고, 다른 파트너는 위치 정보까지 필요할 수 있다. 이 경우 상위 헤더에서는 허용 가능한 origin 집합을 선언하고, 각 iframe에서는 실제 필요한 기능만 열어 두는 방식이 관리하기 쉽다.
실무에서 바로 참고할 수 있는 설정 예시는 무엇일까?
아래 예시는 문법 설명용 예시다. 실제 지원 여부와 필요한 directive 이름은 사용하는 기능별 문서를 함께 확인해야 한다.
Permissions-Policy: geolocation=(), camera=(), microphone=(), fullscreen=(self)
이 예시는 위치 정보, 카메라, 마이크를 모두 막고, 전체화면은 same-origin 문서에서만 허용하는 형태다. 반대로 특정 외부 영상 플레이어에 전체화면을 허용해야 한다면 헤더와 iframe allow에 같은 방향의 설정을 넣어야 한다.
Permissions-Policy-Report-Only는 언제 쓸까?
MDN은 Permissions-Policy-Report-Only 헤더를 별도로 정의하고 있다. 이 헤더는 정책을 실제로 강제하지 않고, 위반 상황을 보고만 하게 만든다. 운영 중인 페이지에 바로 차단 정책을 넣기 부담스럽다면 먼저 어떤 기능 사용이 걸리는지 관찰하는 용도로 쓸 수 있다.
Permissions-Policy 헤더 자체에도 directive별 report-to 파라미터를 둘 수 있고, 보고 대상 endpoint는 Reporting-Endpoints 헤더로 연결한다. 보고 수집 체계가 없다면 차단만 넣는 구성이 더 단순할 수 있고, 반대로 큰 서비스라면 report-only 단계가 변경 리스크를 낮추는 데 도움이 될 수 있다.
자주 생기는 오해는 무엇일까?
Q. Permissions API와 같은 것일까?
같지 않다. MDN은 Permissions Policy와 Permissions API가 밀접하지만 다른 기술이라고 설명한다. Permissions Policy는 서버가 어떤 문서에서 기능 사용 자체를 허용할지 정하고, Permissions API는 사용자 권한 상태를 조회하거나 브라우저 권한 모델과 연결되는 쪽에 가깝다.
Q. 헤더만 넣으면 모든 iframe이 자동으로 쓸 수 있을까?
그렇지 않다. 공식 문서 기준으로 부모 헤더가 넓게 열려 있어도, 각 iframe의 allow 속성은 별도로 적용된다. 실제 동작은 부모 정책, 자식 container 정책, 로드된 origin이 함께 맞아야 한다.
Q. 보안 헤더 세트처럼 무조건 많이 막는 것이 정답일까?
그렇게 단정할 수는 없다. Permissions-Policy는 기능 사용 계약을 문서화하는 도구에 가깝기 때문이다. 쓰지 않는 기능을 닫는 것은 합리적이지만, 실제로 필요한 임베드 기능까지 닫으면 결제, 인증, 플레이어, 회의 기능이 예상대로 동작하지 않을 수 있다.
FAQ
Q. 가장 먼저 확인할 directive는 무엇일까?
서비스에서 실제로 사용하지 않는 강한 권한 API부터 확인하는 편이 현실적이다. 예를 들어 camera, microphone, geolocation, payment처럼 사용자 권한과 연결된 기능부터 검토하면 정책 효과를 이해하기 쉽다.
Q. 브라우저 호환성은 안정적일까?
MDN은 Permissions-Policy와 일부 directive를 experimental로 표시하고 있으며, production 적용 전 브라우저 호환성 표를 확인하라고 안내한다. 따라서 문법만 맞는다고 해서 모든 directive가 동일하게 동작한다고 가정하면 안 된다.
Q. 최소한의 운영 기준은 무엇일까?
공식 문서를 기준으로 정리하면 세 가지다. 첫째, 사용하지 않는 강한 권한 기능은 명시적으로 닫을지 검토한다. 둘째, 서드파티 iframe가 필요한 기능은 부모 헤더와 allow 속성을 함께 점검한다. 셋째, 큰 변경이라면 Permissions-Policy-Report-Only나 위반 리포팅으로 영향을 먼저 관찰한다.
정리
Permissions-Policy는 "브라우저 권한을 서버가 어떻게 제한할 것인가"를 문서와 임베드 단위로 나누어 관리하는 수단이다. 2026년 5월 20일 기준 공식 문서상 핵심은 각 feature의 기본 allowlist가 다르고, 부모 헤더와 iframe allow가 함께 동작한다는 점이다.
실무에서는 보안 헤더 체크리스트처럼 일괄 적용하기보다, 실제 사용하는 브라우저 기능과 서드파티 임베드 요구사항을 먼저 정리한 뒤 필요한 feature만 명시하는 편이 더 정확하다.
참고 자료
'프로그래밍 > HTML, Javascript, CSS' 카테고리의 다른 글
| Cross-Origin-Resource-Policy 기준 정리 (1) | 2026.05.30 |
|---|---|
| X-Content-Type-Options nosniff 기준 정리 (0) | 2026.05.27 |
| X-Frame-Options와 CSP frame-ancestors는 무엇이 다를까? 클릭재킹 방어 기준 정리 (0) | 2026.05.15 |
| Referrer-Policy는 무엇이고 어떤 값을 써야 할까? strict-origin-when-cross-origin 기준 정리 (0) | 2026.05.10 |
| 2. 일렉트론(node)에서 웹 페이지 크롤링 하기 (0) | 2021.05.22 |