Permissions-Policy 헤더 기준 정리

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Permissions-Policy 헤더 기준 정리

Permissions-Policy는 문서와 그 안의 iframe에서 어떤 브라우저 기능을 허용할지 서버가 응답 헤더로 제어하는 방법이다. 2026년 7월 4일 기준 MDN과 W3C Permissions Policy 초안을 보면 이 헤더는 카메라, 마이크, 전체화면, geolocation 같은 기능을 선택적으로 허용하거나 차단하는 데 쓰인다.

실무에서 중요한 판단은 세 가지다. 어떤 기능을 기본 차단할지, 어떤 기능을 같은 출처나 특정 서드파티 프레임에만 위임할지, 그리고 브라우저 호환성 때문에 운영 기본값으로 바로 써도 되는지다. 이 글은 공개 문서 기준으로 Permissions-Policy를 언제 쓰고 어떤 문법을 조심해야 하는지 정리한다.

Permissions-Policy는 무엇을 해결할까?

W3C 문서는 이 정책의 목적을 브라우저 기능과 API를 선택적으로 활성화하거나 비활성화하는 메커니즘으로 설명한다. 특히 자사 코드뿐 아니라 페이지 안에서 실행되는 서드파티 콘텐츠까지 포함해 예기치 않은 기능 사용을 줄이고 싶을 때 의미가 있다.

예를 들어 광고, 위젯, 임베드 지도, 사내 도구용 서브프레임이 섞인 페이지에서는 모든 프레임이 카메라나 마이크를 요청할 필요가 없다. 이런 경우 헤더로 기본 범위를 먼저 좁히고, 꼭 필요한 프레임에만 별도로 열어 주는 쪽이 관리가 쉽다.

기본 문법은 어떻게 읽으면 될까?

Permissions-Policy: geolocation=(), camera=(self), fullscreen=*

MDN 기준으로 각 지시어는 <directive>=<allowlist> 형태로 작성하고, 여러 지시어는 쉼표로 구분한다. 허용 목록은 괄호 안에 적는다.

표현	의미	해석할 때의 기준
()	상위 문서와 모든 중첩 문서에서 기능 비활성화	가장 보수적인 차단 설정
(self)	현재 문서와 같은 출처 프레임에만 허용	자사 도메인 중심 서비스에 무난한 기본값
*	모든 중첩 문맥에 허용	제어 범위를 거의 주지 않으므로 신중히 사용
(self "https://example.com")	현재 출처와 특정 외부 출처만 허용	임베드 파트너가 명확할 때 적합

MDN은 *와 ()는 단독으로만 사용하고, self는 특정 origin과 함께 조합할 수 있다고 설명한다. 반면 src는 HTTP 헤더가 아니라 iframe의 allow 속성에서만 쓰는 값이다.

헤더와 iframe allow 속성은 어떻게 역할이 다를까?

W3C 예제는 헤더가 전체 문서 계층의 상한선을 정하고, iframe allow 속성은 그 범위 안에서 특정 프레임에 기능을 위임하는 방식으로 설명한다. 즉 헤더에서 막아 둔 기능을 iframe allow만으로 무제한 복구할 수는 없다.

예를 들어 다음과 같이 응답 헤더를 보내면 geolocation은 기본적으로 모두 차단된다.

Permissions-Policy: geolocation=()

이 상태에서는 특정 iframe에 allow="geolocation"를 넣더라도 상위 정책이 막고 있으면 실제 사용은 허용되지 않는다. 반대로 헤더가 geolocation=(self "https://maps.example")처럼 상한을 열어 둔 경우에는, 해당 출처 프레임에서만 allow 속성으로 실제 위임이 가능하다.

어떤 기능을 먼저 제어하는 편이 실용적일까?

모든 지시어를 한 번에 다루기보다 사용자 권한 요청이나 개인정보 노출과 직접 연결되는 기능부터 보는 편이 현실적이다. 카메라, 마이크, geolocation, 전체화면, autoplay처럼 사용 여부가 명확한 기능이 우선순위가 높다.

기능 예시	왜 먼저 보나	실무 기본값 예시
camera, microphone	권한 요청과 직접 연결됨	필요한 프레임만 허용
geolocation	위치 정보 노출 가능성	대부분 () 또는 (self)
fullscreen	임베드 UX와 연결되지만 남용 가능성도 있음	콘텐츠 성격이 분명할 때만 제한적으로 허용
autoplay	사용자 경험 영향이 큼	미디어 프레임에만 선택 허용

MDN 문서에는 더 많은 지시어가 있지만, 기능 목록은 브라우저 구현과 함께 변할 수 있다. 운영 문서에 예시를 남길 때는 실제 서비스에서 쓰는 지시어만 좁게 기록하는 편이 유지보수에 유리하다.

 

 

브라우저 호환성은 왜 먼저 확인해야 할까?

MDN은 2026년 7월 4일 현재 이 헤더를 Baseline 기능으로 표시하지 않고, 일부 널리 쓰이는 브라우저에서 동작하지 않을 수 있다고 안내한다. 또한 experimental technology로 분류하고 있어서 운영 기본 보안 장치로 단독 의존하는 판단은 조심해야 한다.

따라서 Permissions-Policy는 있으면 더 좋은 방어선으로 보되, 핵심 보안 요구사항은 여전히 권한 체크, 서버 측 검증, 적절한 sandbox 설정, 콘텐츠 분리 구조로 함께 보완하는 편이 맞다.

Feature Policy와는 어떤 관계일까?

W3C 초안은 이 사양이 과거에 Feature Policy라는 이름으로 불렸다고 명시한다. 오래된 글이나 예제에서 Feature-Policy 헤더를 보더라도 현재 문서 기준으로는 Permissions-Policy 이름과 문법을 기준으로 읽는 편이 안전하다.

다만 레거시 문서를 유지 중인 환경이라면 실제 대상 브라우저가 어떤 문법을 인식하는지 따로 확인해야 한다. 현재 운영 기준을 정하는 문서에는 구식 이름을 기본 예제로 남기지 않는 편이 혼란을 줄인다.

적용 전에 무엇을 점검해야 할까?

점검 항목	확인 이유	실무 기준
권한이 필요한 기능 목록	불필요한 지시어 남발 방지	카메라, 위치, 오디오부터 선별
임베드 출처 목록	어느 프레임에 위임할지 결정해야 함	허용 출처를 명시적으로 관리
iframe allow 사용 위치	헤더만으로는 세부 위임이 끝나지 않음	필요 프레임에만 속성 추가
대상 브라우저 호환성	일부 브라우저에서 제한적일 수 있음	운영 브라우저 매트릭스로 사전 확인

자주 헷갈리는 질문

Q. 이 헤더만 넣으면 브라우저 권한 문제가 모두 해결될까?

아니다. 이 헤더는 기능 사용 가능 범위를 좁히는 수단이지, 서버 측 인증이나 애플리케이션 권한 모델을 대체하지 않는다.

Q. 모든 기능을 *로 열어 두면 어떤 문제가 있을까?

상위 문서가 프레임에 위임할 수 있는 범위를 과도하게 넓히게 된다. 서드파티 임베드가 많은 페이지에서는 제어 장치를 사실상 포기하는 것에 가깝다.

Q. iframe allow만 잘 쓰면 헤더는 없어도 될까?

일부 경우에는 가능하지만, 전체 문서에 공통 상한선을 두려면 헤더가 더 일관된 제어 수단이다. 특히 개발자가 직접 만들지 않은 프레임이 추가될 수 있는 구조라면 헤더가 더 중요하다.

정리

Permissions-Policy는 문서와 iframe에서 브라우저 기능 사용 범위를 좁히는 응답 헤더다. 실무에서는 모든 지시어를 다루기보다 카메라, 마이크, 위치처럼 민감도가 높은 기능부터 기본 차단 또는 제한 허용 정책을 정하는 편이 현실적이다.

2026년 7월 4일 기준 공개 문서를 기준으로 보면, 무난한 적용 순서는 기능 목록 선별, 허용할 출처 정의, 필요한 프레임에만 allow 속성 부여, 그리고 실제 대상 브라우저 호환성 확인이다. 특히 이 헤더는 유용하지만 Baseline 기능은 아니므로, 다른 보안 제어와 함께 사용하는 편이 안전하다.

참고 자료

• MDN: Permissions-Policy header
• W3C Editor's Draft: Permissions Policy