Permissions-Policy 헤더가 실제로 제한할 수 있는 것

짧게 말하면

Permissions-Policy는 사이트가 특정 브라우저 기능에 대한 접근을 제한할 수 있게 해 주는 HTTP 응답 헤더입니다. 카메라, 마이크, 위치 정보, 전체 화면, 결제, 센서, 그리고 더 작은 API들의 긴 목록이 여기에 포함됩니다.

이것은 일반적인 개인정보 보호막이 아닙니다. 모든 추적을 막거나, 쿠키를 차단하거나, 네트워크 요청을 방지하거나, 서드파티 JavaScript를 안전하게 만들지는 않습니다. 이 헤더가 잘할 수 있는 일은 더 좁지만 여전히 가치가 있습니다. 자체 페이지와 임베드된 프레임에서 사용할 수 있는 브라우저 기능을 줄이는 것입니다.

이 점이 중요한 이유는 현대 웹사이트가 분석 스니펫, 미디어 임베드, 채팅 위젯, 동의 관리 도구, 광고 스크립트, 지도, 결제 흐름, 내부 실험으로 이어 붙여져 있기 때문입니다. 이러한 구성 요소 대부분은 강력한 기기 API에 접근할 필요가 없습니다. 좋은 정책은 이를 명확히 합니다.

이미 프로덕션에서 헤더를 검토하고 있다면, 실제 응답을 직접 확인하는 작업과 함께 진행하세요. 프로덕션에서 리디렉션과 HTTP 헤더를 디버깅하는 작은 도구 모음 가이드는 여기에서 중요한 습관을 다룹니다. 설정 파일에 적힌 대로가 아니라, 브라우저가 실제로 무엇을 받는지 확인하는 것입니다.

Permissions-Policy가 제어하는 것

이 헤더는 이름이 지정된 브라우저 기능에 대한 접근을 제어합니다. 브라우저 API가 변하기 때문에 정확한 목록은 시간이 지나며 달라지지만, 일반적인 지시문에는 다음이 포함됩니다.

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• 오래된 논의에서의 interest-cohort, 현재는 대부분 역사적인 항목

지시문은 특정 기능을 아무에게도 허용하지 않거나, 현재 출처에 허용하거나, 선택한 출처에 허용할 수 있습니다. 예를 들면 다음과 같습니다.

Permissions-Policy: camera=(), microphone=(), geolocation=(self)

이는 카메라와 마이크가 문서 및 그 안의 중첩 브라우징 컨텍스트에서 비활성화되고, 위치 정보는 동일 출처에만 허용된다는 뜻입니다.

더 허용적인 예는 다음과 같습니다.

Permissions-Policy: geolocation=(self "https://maps.example"), fullscreen=(self "https://video.example")

이는 자체 출처와 이름이 지정된 지도 제공업체 하나가 위치 정보를 사용할 수 있게 하고, 자체 출처와 동영상 제공업체가 전체 화면을 요청할 수 있게 합니다.

정책은 브라우저가 평가합니다. 어떤 기능이 허용되지 않으면, 해당 API를 사용하는 JavaScript는 실패하거나 사용할 수 없는 것처럼 동작해야 합니다. 정확한 실패 방식은 API에 따라 다릅니다. 때로는 promise가 reject됩니다. 때로는 기능이 단순히 사용할 수 없는 것처럼 보입니다.

자체 페이지에서 제한할 수 있는 것

퍼스트파티 페이지에서 Permissions-Policy는 가드레일로서 가장 유용합니다. 실수로 추가되었거나 예상치 못한 코드의 영향 범위를 줄여 줍니다.

예를 들어 마케팅 페이지에는 마이크, 카메라, Bluetooth, USB, 모션 센서, 결제 API가 필요하지 않을 가능성이 큽니다. 이러한 기능을 전역적으로 거부할 수 있습니다.

Permissions-Policy: camera=(), microphone=(), bluetooth=(), usb=(), payment=(), accelerometer=(), gyroscope=(), magnetometer=()

이것이 페이지의 모든 스크립트를 신뢰할 수 있게 만드는 것은 아닙니다. 다만 태그 관리자 실험, 손상된 의존성, 붙여 넣은 위젯이 제한된 API를 호출하려고 할 때, 브라우저가 접근을 허용하지 않아야 한다는 의미입니다.

기여자가 많은 팀에서는 이것이 유용한 기본값입니다. 논의를 막연한 신뢰에서 명시적인 기능 권한으로 옮깁니다. 향후 어떤 기능이 정말로 카메라를 필요로 한다면, 누군가는 정책을 변경하고 그 이유를 설명해야 합니다.

그것은 바람직한 종류의 마찰입니다.

iframes에서 제한할 수 있는 것

이 헤더는 임베드된 콘텐츠 주변에서 특히 유용해집니다.

브라우저는 이미 iframes를 별도의 브라우징 컨텍스트로 취급하지만, 임베드된 서드파티 콘텐츠도 정책과 iframe 속성이 허용한다면 강력한 기능을 요청할 수 있습니다. Permissions-Policy는 부모 페이지가 상한선을 설정할 수 있게 해 줍니다.

예를 들어 페이지에 동영상 플레이어, 지원 위젯, 지도가 임베드되어 있다면 모든 프레임에 모든 기능 접근을 줄 필요가 없습니다. 전체 화면은 동영상 프레임에만, 위치 정보는 지도 프레임에만 허용할 수 있습니다.

이해해야 할 두 계층이 있습니다.

1. HTTP Permissions-Policy 헤더는 문서에 대한 정책을 설정합니다.
2. iframe allow 속성은 특정 기능을 프레임에 위임할 수 있지만, 부모 정책이 허용하는 범위 안에서만 가능합니다.

간단한 iframe은 다음과 같을 수 있습니다.

<iframe src="https://video.example/embed/123" allow="fullscreen"></iframe>

헤더가 전체 화면을 완전히 거부한다면 iframe 속성은 그 거부를 재정의할 수 없습니다. 헤더가 해당 출처에 대해 전체 화면을 허용한다면 iframe 속성은 이를 위임할 수 있습니다.

이 계층 구조는 헤더를 사용할 가치가 있는 이유 중 하나입니다. 플랫폼 또는 보안 팀이 사이트 전체의 경계를 설정할 수 있게 하면서도, 제품 팀이 필요한 특정 임베드를 활성화할 수 있게 해 줍니다.

제한할 수 없는 것

여기에서 팀들이 이 헤더를 과대평가하는 경우가 있습니다.

Permissions-Policy는 콘텐츠 보안 정책을 대체하지 않습니다. 어떤 스크립트를 로드할 수 있는지 결정하지 않습니다. 스크립트가 네트워크를 통해 데이터를 보내는 것을 막지 않습니다. HTML을 정리하지 않습니다. XSS를 방지하지 않습니다. 폼 스팸을 차단하지 않습니다. 폼 악용이 문제라면 이 헤더가 아니라 문의 양식이 가장 큰 스팸 취약점인 이유에서 설명한 메커니즘부터 시작하세요.

또한 쿠키 거버넌스를 대체하지도 않습니다. 쿠키, local storage, 동의, 서드파티 임베드, 브라우저 추적 방지는 별개의 문제입니다. 개인정보 보호 제어를 폭넓게 검토하고 있다면 쿠키 환경은 별도로 살펴볼 필요가 있습니다. 실질적인 변화는 2026년에 쿠키에 무엇이 바뀌었고 무엇을 해야 하는가에서 다룹니다.

가장 중요한 점은 Permissions-Policy가 서드파티 JavaScript를 비공개로 만들어 주지 않는다는 것입니다. 서드파티 스크립트를 퍼스트파티 페이지에 로드하면, 일반적으로 그 스크립트는 다른 브라우저 제약과 보안 헤더의 적용을 받으면서도 페이지 권한으로 실행됩니다. 카메라 접근을 거부하는 것은 좋습니다. 하지만 그 스크립트가 DOM 콘텐츠를 읽거나, 사용자 행동을 관찰하거나, 허용된 네트워크 요청을 보내는 것을 막지는 않습니다.

이를 위해서는 다른 제어가 필요합니다. 신중한 벤더 선정, CSP, sandboxed iframes, 적용 가능한 경우 Subresource Integrity, 데이터 최소화, 그리고 지루하지만 필요한 검토가 필요합니다.

합리적인 기본 정책

모든 사이트에 맞는 보편적인 헤더는 없지만, 대부분의 콘텐츠 및 마케팅 사이트는 제한적으로 시작할 수 있습니다.

합리적인 첫 단계는 다음과 같습니다.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), accelerometer=(), gyroscope=(), magnetometer=(), screen-wake-lock=()

그런 다음 사이트가 실제로 사용하는 것만 다시 추가하세요.

예를 들면 다음과 같습니다.

• Payment Request API를 사용하는 상점은 payment=(self)가 필요할 수 있습니다.
• 위치 찾기 기능은 geolocation=(self) 또는 신뢰할 수 있는 지도 출처가 필요할 수 있습니다.
• 회의 앱은 camera=(self)와 microphone=(self)가 필요할 수 있습니다.
• 동영상 중심 사이트는 fullscreen=(self "https://trusted-video.example")가 필요할 수 있습니다.

중요한 것은 체크리스트에서 거대한 정책을 복사해 놓고 끝났다고 여기는 것이 아닙니다. 기능 인벤토리에서 시작하세요. 어떤 페이지에 어떤 브라우저 기능이 필요합니까? 어떤 임베드에 위임이 필요합니까? 어떤 기능이 요청된다면 놀라운 일입니까?

기능을 깨뜨리지 않고 배포하는 방법

다른 프로덕션 헤더와 마찬가지로 의도적으로 배포하세요.

1. 기능 사용 현황 파악

코드베이스에서 getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB, wake lock API 같은 브라우저 API 호출을 검색하세요.

그런 다음 서드파티 임베드를 확인하세요. 동영상, 지도, 결제, ID 제공업체의 문서에는 필요한 iframe allow 값이 언급되는 경우가 많습니다.

2. 위험이 낮은 환경에서 시작

스테이징에 제한적인 헤더를 추가하고 핵심 사용자 흐름을 테스트하세요. 브라우저 콘솔 메시지에 주의를 기울이세요. 브라우저는 기능이 permissions policy에 의해 차단될 때 이를 보고하는 경우가 많습니다.

3. 필요한 경우 페이지별 정책 사용

제품에 매우 다른 유형의 페이지가 있다면 하나의 전역 정책을 강제하지 마세요. 블로그, 결제, 지도 페이지, 동영상 룸은 아마 서로 다른 기능을 필요로 할 것입니다.

대부분의 웹 서버, 프레임워크, edge 플랫폼은 경로별로 조건부 헤더를 설정할 수 있습니다. 한 기능 때문에 전체 사이트의 정책을 약하게 만드는 것보다 이 방식이 더 깔끔한 경우가 많습니다.

4. 실제 응답 검증

헤더는 CDN, reverse proxy, 앱 서버, middleware에 의해 추가되거나, 덮어써지거나, 중복되거나, 제거될 수 있습니다. browser DevTools 또는 command-line 도구로 최종 응답을 확인하세요.

임베드된 컨텍스트도 테스트하세요. 최상위 페이지가 올바르게 보인다고 해서 iframe이 의도한 위임을 받았다는 보장은 없습니다.

5. 예외 문서화

허용된 모든 기능에는 소유자와 이유가 있어야 합니다. 6개월 뒤 아무도 왜 geolocation이 더 이상 페이지에 나타나지 않는 벤더 도메인에 열려 있었는지 기억하지 못하게 되기 전까지는 관료적으로 들릴 수 있습니다.

흔한 문법 실수

현대적인 헤더 문법은 간결하지만 조금 틀리기 쉽습니다.

기능을 거부하려면 빈 괄호를 사용하세요.

Permissions-Policy: microphone=()

현재 출처에는 self를 사용하세요.

Permissions-Policy: geolocation=(self)

특정 외부 출처에는 따옴표로 감싼 출처를 사용하세요.

Permissions-Policy: fullscreen=(self "https://video.example")

레거시 동작을 의도적으로 지원하는 것이 아니라면 오래된 Feature-Policy 예제에 의존하지 마세요. 이전 헤더는 다른 문법을 사용했으며, 오늘날 설계의 기준으로 삼아서는 안 됩니다.

또한 브라우저 지원은 지시문마다 다르다는 점을 기억하세요. 어떤 브라우저는 헤더를 지원하지만 특정 기능 지시문은 지원하지 않을 수 있습니다. 이는 정상입니다. 이 헤더를 유일한 개인정보 보호 또는 보안 제어가 아니라, 심층 방어 수단으로 취급하세요.

<!-- tool-cta:start -->

💡 시도해 보세요: Get Headers로 Permissions-Policy가 의도한 대로 전달되고 있는지 확인하세요. 이 도구는 서버가 보내는 원시 응답 헤더를 보여줍니다.

<!-- tool-cta:end -->

실질적인 개인정보 보호 가치

Permissions-Policy의 개인정보 보호 가치는 사이트를 익명으로 만들거나 추적기 없는 상태로 만드는 데 있지 않습니다. 그렇지 않습니다.

그 가치는 민감한 브라우저 기능에 대한 접근을 좁히는 데 있습니다. 위치, 카메라, 마이크, 기기 센서, 로컬 하드웨어 API, 결제 흐름은 강력합니다. 대부분의 페이지에는 이것들이 필요하지 않습니다. 많은 임베드된 구성 요소는 이를 요청할 수 있어서는 안 됩니다.

이는 실제 개선입니다. 불필요한 프롬프트를 줄이고, 필요 없는 기능 노출을 제한하며, 새 기능이 출시될 때 팀이 검토할 수 있는 구체적인 산출물을 제공합니다.

이 헤더의 가장 좋은 형태는 지루합니다. 기본적으로 제한적이고, 사용자에게 보이는 기능이 요구하는 곳에서만 완화되며, 일반적인 릴리스 프로세스의 일부로 테스트되는 것입니다.