Permissions-Policy vs Security Headers: What Each Layer Does
https://vulnify.app/blog/permissions-policy-vs-security-headers

Security headers protect transport and content execution; Permissions-Policy restricts browser features like camera and geolocation. Learn how they differ and when to test both on Vulnify.

Teams often run one header scan, see a green score, and assume browser security is "done." In practice, modern sites need several complementary layers. Content-Security-Policy reduces script injection risk. HSTS enforces HTTPS. Permissions-Policy limits powerful browser features. They overlap in spirit but not in mechanism. This article separates the layers so you know which control fixes which risk—and which Vulnify tools to run for each. Why Teams Confuse These Headers Security header checklists often lump every response header into one score. Permissions-Policy never appears on older lists, so teams assume a passing grade covers browser features. CSP and Permissions-Policy also share syntax-like directives, which invites copy-paste errors. Separating transport (HSTS), content execution (CSP), feature gates (Permissions-Policy), and session state (cookies) keeps remediation tickets assignable to the right owners. Security Headers: Transport and Content Boundaries Classic security headers answer questions like "force HTTPS," "prevent clickjacking," and "restrict where scripts may load." The security headers analyzer reviews common baseline headers in one pass: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options or frame-ancestors, X-Content-Type-Options, Referrer-Policy, and related values. Drill into specifics when templates differ: CSP checker for directive-level XSS defenses HSTS checker for preload readiness and max-age strength Cookie security checker for Secure, HttpOnly, and SameSite on session cookies These controls shape how documents load and how sessions behave. They do not, by themselves, decide whether geolocation or payment APIs are available to embedded third parties. Permissions-Policy: Browser Feature Gates Permissions-Policy (formerly Feature-Policy) declares which powerful features the current document and embedded frames may use: camera, microphone, geolocation, payment, USB, fullscreen, and more. A restrictive policy reduces impact when a third-party script goes rogue or when an iframe should never access sensors. Wildcards and missing policies are common findings. Marketing pages that embed maps, chat widgets, and video players accumulate permissive defaults unless someone audits them. The Permissions-Policy analyzer parses live headers, flags legacy Feature-Policy values, and highlights directives that leave sensitive features too open. Side-by-Side Comparison Force HTTPS and block downgrade — use HSTS ( HSTS checker ) Block inline script or untrusted origins — use CSP ( CSP checker ) Prevent clickjacking — use frame-ancestors or X-Frame-Options ( headers analyzer ) Disable camera on checkout pages — use Permissions-Policy ( Permissions-Policy analyzer ) Harden session cookies — review Set-Cookie flags ( cookie checker ) Testing Order That Works Run the headers analyzer on production templates (home, auth, checkout, embed-heavy pages). Deep-dive CSP and HSTS where scores diverge between templates. Run Permissions-Policy on pages with iframes, chat, maps, or WebRTC. Fix cookie flags on authenticated flows. Rescan after CDN or platform changes—edge configs often strip or duplicate headers. Platform stacks cache headers differently. WordPress, Shopify, and Joomla each have plugin paths that inject headers. After plugin updates, rerun the same trio: headers analyzer, CSP checker, Permissions-Policy analyzer. Feature-Policy Legacy and Migration Older sites may still emit Feature-Policy headers alongside or instead of Permissions-Policy . Browsers prefer the modern name, but duplicated or conflicting directives confuse audits. The Permissions-Policy analyzer flags legacy syntax so you can consolidate on one header during your next hardening sprint rather than maintaining two parallel policies forever. Checkout, Auth, and Embed-Heavy Pages Not every page needs the same feature gates. Checkout flows should disable camera, microphone, and payment APIs unless your product genuinely uses them. Login pages rarely need geolocation. Support chat embeds often require specific feature allowances—document intentional exceptions instead of site-wide wildcards. Run separate analyzer passes on templates that include third-party iframes; a strict homepage policy does not protect checkout if checkout inherits permissive defaults from a theme. CDN and Edge Header Duplication When both origin and CDN append headers, browsers apply combined rules in ways that surprise developers. You may see duplicate CSP values or a Permissions-Policy stripped at origin but injected at edge. Test customer-facing URLs exactly as browsers load them, not only origin-direct admin hostnames visible to engineers. Mapping Findings to Compliance Questionnaires Missing CSP or weak HSTS supports OWASP A05 security misconfiguration storylines in vendor reviews. Permissions-Policy gaps rarely appear on legacy checklists yet, but they demonstrate mature browser-side hardening when you need to differentiate from checkbox compliance. Export analyzer output when responding to customer security assessments. WordPress, Shopify, and Joomla Considerations Plugins inject inline scripts that complicate CSP while chat widgets demand selective Permissions-Policy exceptions. Shopify themes may add checkout scripts you did not author. Joomla extensions sometimes set conflicting headers at the PHP layer. Test one representative page per template type rather than assuming one homepage scan covers the whole property. Common Header Mistakes This Combination Catches Teams often deploy HSTS on the apex but forget www, set CSP report-only forever without enforcing, or copy a permissive Permissions-Policy from a blog template onto checkout. Running analyzers per template surfaces those mismatches. Another frequent gap: secure cookies on the app while marketing iframes load third-party scripts without CSP nonces—Permissions-Policy and CSP together reduce blast radius when either layer slips. Staging vs Production Header Parity Teams often harden staging first, then discover production CDN rules strip Permissions-Policy entirely. Schedule a production URL pass after every edge configuration change, not only after application deploys. Screenshot analyzer output from staging and production side by side when auditors ask for evidence—parity gaps are easier to fix before launch than during an incident. Treat missing feature restrictions on checkout the same severity as missing HSTS on login. Do Not Stop at Headers Headers reduce blast radius; they do not replace vulnerability testing. Follow header work with the website vulnerability scanner for injection and exposure findings. Read common website security mistakes for patterns that headers alone cannot fix. Start on Vulnify Tools and save baseline screenshots of header output when you pass audits—evidence helps when regressions appear later. Frequently Asked Questions Is Permissions-Policy the same as Content-Security-Policy? No. CSP controls which resources (scripts, styles, images) may load. Permissions-Policy controls which browser features (camera, geolocation, payment) the page and its frames may use. Do I need both CSP and Permissions-Policy? Most production sites benefit from both. CSP reduces XSS impact; Permissions-Policy limits damage if a third-party widget or iframe misbehaves. Why does my header scan pass but Permissions-Policy is missing? Many baseline header checks focus on CSP, HSTS, and framing. Permissions-Policy is a separate header that must be tested explicitly with a Permissions-Policy analyzer. Can a CDN change my Permissions-Policy? Yes. Edge platforms may add, strip, or override headers. Test both CDN-facing URLs and origin-direct URLs when they differ. Should I use Permissions-Policy on API-only subdomains? If browsers render HTML or host embedded docs on those hosts, yes. Pure JSON APIs consumed only by non-browser clients benefit less, but admin portals on the same subdomain still need feature restrictions. What is a good starter Permissions-Policy? Start restrictive: disable camera, microphone, geolocation, and payment on pages that do not need them. Loosen only for templates with maps, WebRTC, or payment SDKs—and document each exception in your security baseline. How do report-only headers help? CSP Report-Only and Report-To endpoints show what would break before you enforce. Permissions-Policy lacks identical report-only support in all browsers, so test feature restrictions in staging with real embeds before enforcing in production. Related Guides Pre-Launch Security Checklist (8 Free Checks) WAF and CDN Detection: What It Means for Your Scans CAA Records Explained for Site Owners