Permissions-Policy Checklist for Agencies Reviewing Client Websites

A Permissions-Policy checklist helps agencies review whether a site intentionally limits browser features such as camera, microphone, geolocation, payment, fullscreen, and related APIs. For many client websites, the practical question is simple: does the public response declare which browser features are allowed, or is that signal missing?

This tool checks public trust signals only. It is not a security audit, vulnerability scan, malware scan, or compliance check.

Use the Client Website Trust Check for a passive public header hygiene review on one client URL. Use the free 10-domain agency audit when the same client conversation needs a broader SSL, DNS, domain expiry, CAA, and email-authentication snapshot.

Quick answer: Permissions-Policy checklist

For agencies, a first-pass Permissions-Policy checklist should:

• Check whether the Permissions-Policy header is present.
• Record the visible policy value.
• Identify broad allow patterns.
• Identify features that are blocked by default.
• Confirm whether the site legitimately uses camera, microphone, geolocation, payment, or fullscreen.
• Route policy decisions to the developer or product owner.

The header is a public trust signal. It does not replace product-specific QA, and it does not prove what every route or embedded component needs.

What Permissions-Policy does

Permissions-Policy lets a site declare which browser features may be used by the page and by embedded frames. MDN's Permissions-Policy reference explains the header and its feature directives.

In agency terms, the header documents intent. A marketing site that never uses camera or microphone can usually restrict those features. A booking app, map-heavy local site, checkout flow, portal, or embedded widget may need more nuance.

Why agencies should review browser feature permissions

Browser feature permissions are easy to forget because they are not part of visual QA. A page may look complete while the public response still has no declared feature policy.

Review Permissions-Policy during:

• Launch QA.
• Client handover.
• App or landing-page rebuilds.
• Third-party embed review.
• CDN or framework migration.
• Care-plan technical reporting.

The right report language is factual: what was visible, what looks broad or missing, and who should review the value.

Common features to review

| Feature | Why it matters | Common policy pattern | Agency review note | |---|---|---|---| | camera | Camera access is rarely needed on marketing pages | camera=() | Confirm before allowing on apps that capture media | | microphone | Microphone access is rarely needed on standard sites | microphone=() | Ask product owner if voice features exist | | geolocation | Location may support maps, delivery, or store lookup | geolocation=() or limited origins | Confirm business need before blocking | | payment | Browser payment APIs may support checkout | payment=() or allowed checkout origins | Review with ecommerce owner | | fullscreen | Fullscreen may be needed for media, maps, or apps | fullscreen=(self) | Confirm embed and media needs | | Legacy examples | Old Feature-Policy or deprecated directives may appear | Mixed or ignored syntax | Ask developer to review current header support |

camera

Most agency client websites do not need camera access on public marketing pages. If camera is unrestricted or the policy is absent, the finding should be: "review whether camera should be restricted by policy."

Do not assume every site can block it. Some apps, identity flows, upload experiences, or product demos may need camera access.

microphone

Microphone access is similar. Many sites do not need it, but some communications products, support tools, event platforms, or browser apps may.

The agency action is to confirm intent. If nobody knows why microphone access would be allowed, assign the policy review to the developer or product owner.

geolocation

Geolocation is more common. Local business sites, store locators, booking flows, delivery tools, and map integrations may use it.

For this reason, agencies should be careful with blanket recommendations. A missing policy is a review item. A restrictive policy may be fine. A broad policy needs product context.

payment

Payment-related browser features may matter for ecommerce or checkout flows. If the client uses Shopify, Stripe, browser payment APIs, embedded checkout, or third-party payment widgets, the policy should be reviewed before changes.

Document the visible policy and ask the ecommerce or developer owner to confirm.

fullscreen

Fullscreen can be legitimate for video players, maps, dashboards, demos, and interactive tools. A restrictive baseline may work for simple sites, but apps and embeds need testing.

If fullscreen is broadly allowed or absent, treat it as a header hygiene review item, not as a final conclusion.

interest-cohort or legacy policy examples if relevant

Some older policies include directives such as interest-cohort=() or use the older Feature-Policy header. These may be legacy artifacts from previous browser behavior or hosting templates.

Agencies should not spend client time polishing obsolete syntax without developer context. Note the observed value and ask the developer whether the policy should be modernized.

Common missing or broad policy patterns

Common findings include:

• Permissions-Policy is missing.
• Policy exists but allows broad feature access.
• Policy blocks features the app actually needs.
• Header differs between hostnames.
• Header appears at the CDN but not in local app config.
• Old Feature-Policy syntax appears without a current policy.

Each finding should become a short owner-specific action.

When a site may legitimately need a feature

Legitimate feature use is common in apps and ecommerce. Examples include:

• Camera for identity verification or media capture.
• Microphone for meetings or voice input.
• Geolocation for local inventory or delivery.
• Payment for checkout.
• Fullscreen for video, maps, dashboards, or demos.

If a feature is needed, the review should focus on scope and intentionality rather than blanket blocking.

Permissions-Policy review checklist

• Check the final public URL.
• Record whether Permissions-Policy is visible.
• Record the exact value.
• Identify camera, microphone, geolocation, payment, and fullscreen directives if present.
• Ask whether the public page or app uses those features.
• Confirm whether embedded third-party content needs exceptions.
• Assign review to developer, product, ecommerce, host, or CDN owner.
• Add the finding to agency handover notes.

What Client Website Trust Check reports

The Client Website Trust Check reports whether a Permissions-Policy signal is visible in the checked public response. It treats the header as one public trust signal among HTTPS/TLS, HSTS, Referrer-Policy, CSP presence, visible cookie flags, CAA, and public metadata files.

This is useful for agency client review because it highlights missing or broad signals without pretending to know every product requirement.

What a passive check cannot know

We make a small number of public requests to the domain you submit. We do not log in, scan plugins, or crawl the site.

Some signals are only visible if the site responds normally on the public URL being checked. Sites behind WAFs, geo-blocks, or aggressive bot protection may show unknown rather than missing.

A passive public check cannot know whether a feature is required after login, inside an iframe, after consent, or on a specific route. For CertPilot's public-check boundaries, see the methodology page.

Related Resources

• Website header checklist for agencies
• Website trust signals checker
• Client website trust signals guide
• Agent-friendly web page checklist

Frequently Asked Questions

What is a Permissions-Policy checklist?

A Permissions-Policy checklist is an agency review of whether a client website declares browser feature permissions through the public Permissions-Policy header. It looks at features such as camera, microphone, geolocation, payment, and fullscreen, then routes unclear or missing settings to the right owner.

Should every website block camera and microphone?

Many public marketing sites can restrict camera and microphone, but agencies should confirm site behavior first. Apps, portals, identity flows, support tools, and embedded services may need those features. Treat broad access or missing policy as a review item rather than applying one default everywhere.

What does a missing Permissions-Policy header mean?

It means the checked public response did not expose a Permissions-Policy signal. That is a missing header hygiene signal and a recommended improvement. It does not prove what every route does or whether the app has feature checks elsewhere.

Who should decide the policy values?

The developer, product owner, host, CDN owner, and sometimes ecommerce owner may all be involved. The agency can identify the missing or broad signal, but the final policy should be tested against the site's real browser feature needs.

Can a passive check know whether geolocation is required?

No. It can only read the public response. Geolocation may be used after a click, after consent, inside an embedded map, or on another route. Agencies should confirm product behavior before recommending restrictive changes.

Is Feature-Policy the same as Permissions-Policy?

Feature-Policy is the older header name. Some sites still show legacy syntax. Agencies should document what is visible and ask the developer whether the current Permissions-Policy header should replace or complement old configuration.