In one paragraph
A missing Permissions-Policy header means the response does not declare this browser-feature allowlist. It does not give every script unrestricted camera or location access: browser defaults, user permissions, secure-context requirements, and iframe rules still apply. Disable features your application does not need, delegate necessary capabilities deliberately, and test support and embedded flows before applying a site-wide policy.
Why it matters
Permissions Policy controls whether supported browser features may be used in a document and relevant nested contexts. It can set a limit before a permission prompt or API call succeeds, reducing functionality available to unwanted code even when another control fails.
It is not a substitute for user consent, secure coding, or an origin trust boundary. A third-party script executing in your document generally shares that document's capabilities; listing its download host does not isolate the script as though it were a separate iframe.
Support varies by browser and individual directive. An unrecognised feature can be ignored, and a correctly emitted header does not prove every visitor receives the same enforcement. Review the capabilities and supported clients that actually matter to the application.
How WebAuditOS evaluates this finding
The supplied check reads Permissions-Policy on HTML responses. Any present value passes; absence fails at low severity. Non-HTML and missing responses are not graded. It does not evaluate which capabilities are denied or delegated.
The older Feature-Policy header does not satisfy the documented rule. A permissive or ineffective declared value can pass, so treat the result as header presence rather than a complete feature-security assessment.
How to fix it
- Inventory features by route and embed. Check maps, video support, payment widgets, fullscreen players, authentication, and hardware integrations. Do not copy a broad denylist over functionality you have not tested.
- Begin with capabilities you know are unnecessary. For a page with no camera, microphone, or location requirement, an illustrative header is:
Permissions-Policy: camera=(), microphone=(), geolocation=()The empty allowlist disables the named capability in the applicable top-level and nested contexts where supported. This is a scoped example, not a universal policy for every site.
- Use self or approved origins when a feature is required. For example:
Permissions-Policy: geolocation=(self "https://maps.example.com")Use the actual trusted origin and review the embedding design. Permitting an origin in the response header is not identical to granting it user permission or satisfying every iframe delegation requirement.
- Configure iframe allow attributes consistently with the parent policy. A child restriction can narrow permission but cannot widen a feature already prohibited by the parent's effective policy. Test any redirect or nested-frame chain used by the provider.
- Set the header in the application or response layer covering the intended documents. In nginx, for the illustrative denylist:
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;Check route overrides and version-specific inheritance. Avoid duplicate sources of policy that maintainers cannot explain.
- Leave obsolete experiment-specific directives out of new configuration. Do not add old interest-cohort examples as if they were a current security requirement. Check supported directive names and syntax before shipping.
- Test the real browser APIs and embedded flows in supported clients. Confirm that denied features fail as intended and approved maps, calls, or payment interfaces remain usable. A visible button is not proof that the underlying API can run.
- Inspect final public response headers, Console diagnostics, and provider guidance, then rescan. Maintain tests for the meaningful features rather than relying on a green presence-only finding.
What the fix can break
Disabling a needed capability can make an integration behave as though the user denied permission, even when the user never saw a prompt. This can break a map location button or a support call without producing a server-side error.
Payment capability changes should be based on the provider's actual API use; not every checkout mechanism uses the same browser feature. Fullscreen and autoplay also have separate browser policies and user-interaction conditions.
Unsupported directives do not create protection merely because they remain in the response text. Keep compatibility expectations explicit and do not describe the policy as universally enforced across all visitors.
Questions
Does the missing header let sites use my camera silently?
No. Browser permission and other restrictions still apply. The header adds an application-defined limit; it does not create those other safeguards.
Can an iframe allow attribute override camera=()?
Not to grant a capability already denied by the effective parent policy. Configure and test both layers together.
Why does a nearly empty policy pass?
The supplied check tests header presence, not the value's effectiveness. Review your actual feature decisions independently.
Which related checks help?
Review CSP, Referrer-Policy, and the security headers guide.