http.permissions_policy Reviewed July 2026

Quick fix

Inventory browser capabilities genuinely required by each application and embedded origin.

What this finding means

SecuTest records whether a `Permissions-Policy` header is present. It does not judge every directive because required features vary by application. The control reduces capability exposure but does not replace browser permission prompts or iframe sandboxing.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Abuse of browser capabilities by compromised or embedded content

How the attack or failure scenario works

Permissions Policy limits features such as camera, microphone, geolocation, fullscreen, and payment APIs for the page and frames. If a script injection or untrusted iframe is present, a restrictive policy can prevent it from reaching capabilities the application never intended to expose.

Conditions and limitations

  • The application includes compromised script, XSS, or untrusted embedded content.
  • The browser feature is available in the victim's context and user permissions allow access where required.
  • No effective policy disables that feature for the page or frame.

Why it matters

Security and business impact Without a Permissions-Policy, pages and embedded content may access browser features more broadly than the application requires.

Step-by-step fix

Where to make the change

  • The outermost component emitting the public HTTP response: CDN, reverse proxy, ingress, web server, or application middleware.
  • Apply the control consistently to normal pages, redirects, error responses, and relevant subdomains.

Remediation procedure

  1. Inventory browser capabilities genuinely required by each application and embedded origin.
  2. Deny unused features by default and allow only specific trusted origins.
  3. Set the header at the public response layer and combine it with iframe `allow` and `sandbox` attributes.
  4. Test video calls, geolocation, payment, document, and embedded workflows after enforcement.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Restrictive baseline
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

Nginx
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;

Apache
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"

Verify the fix

  1. Inspect the `Permissions-Policy` response header.
  2. Use browser developer tools to confirm denied features are blocked in untrusted frames.
  3. Test required features in top-level and embedded contexts.
  4. Review the policy whenever a new third-party widget is added.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Disabling a feature globally before identifying a legitimate business workflow.
  • Using obsolete Feature-Policy syntax.
  • Assuming Permissions Policy stops an injected script from accessing ordinary application data.

Authoritative references