Permissions-Policy builder, generate the header from reports
Generate a Permissions-Policy header from the reports browsers send. Grant camera, payment, and other features to your pages and frames, then deploy.
Last update:
The Permissions-Policy builder writes a Permissions-Policy header from your own reports. This header tells the browser which features, such as the camera, geolocation, or the payment sheet, your pages and the frames they embed may use. You pick the reports to learn from, start from a preset or your own policy, grant each feature to the pages and frames that use it, and copy the headers.
The builder lives under each website, in the sidebar, as Builders > Permissions-Policy, next to the CSP builder and the Connection-Allowlist builder. It works on every plan, and every website role can use it. For what the three builders share, refer to Builders.
Review every grant, and deploy in report-only first
The builder grants each feature to the pages and frames that browsers reported using it. Anyone who knows your reporting endpoint can send reports to it, so a granted feature is not proof that your pages use it. Review the grants before you deploy, starting with the features granted to another origin. A policy from the API or the MCP tool applies the same defaults with no review, so check it the same way.
Always deploy a new policy with the Permissions-Policy-Report-Only header first. Switch to Permissions-Policy only once a week or more of reports shows that nothing your pages need would be blocked.
What the Permissions-Policy builder produces
The builder ends with two response headers, ready to paste into your server or content delivery network (CDN) configuration. A Reporting-Endpoints header points reports at your website's CentralCSP endpoint. A Permissions-Policy-Report-Only header carries the policy, or Permissions-Policy once you switch to enforce mode.
Each feature in the policy reads one of three ways. () denies it everywhere, self grants it to your own pages, and a quoted origin grants it to a frame from that origin:
Permissions-Policy-Report-Only: camera=(), geolocation=(self), payment=(self "https://pay.example.com")The builder writes no report-to parameter in the policy. Its reports go to the endpoint named default, which the Reporting-Endpoints header declares next to centralcsp. Refer to The default endpoint.
The builder does not save or deploy anything, and unlike the CSP builder it does not grade the policy. It gives you the headers, and you add them to your site. Each export, the headers as TXT or the review table as CSV, is recorded in the audit log.
How it works
The builder works in four steps. Each step reuses the answer of the one before it.
- Period: Choose which days of reports to learn from, up to the last 30.
- Starting policy: Start from a preset, by default one that denies every listed feature, or paste the policy you send today.
- Review features: Grant or reject each feature, for your own pages and for each frame origin. Every row starts decided for you: what your pages and frames used is granted, and noise and features only a third-party script reached for start rejected.
- Deploy: Pick report-only or enforce mode, and copy the headers.
The defaults keep working what your pages and frames used in the period, and deny the rest of the catalog.
Where the data comes from
The builder reads two report types your website already collects:
- A Permissions-Policy violation report, sent when one of your pages uses a feature the policy blocks. It becomes a grant to
self. - A
potential-permissions-policy-violationreport, sent when an iframe'sallowattribute asks for a feature. It becomes a grant to that frame's origin.
The Permissions Policy reports page shows the same data, as its Violations and Potential views. For why the Potential view matters before you enforce, refer to Check Potential before you enforce.
Why there is no detected policy
A CSP report carries the policy that produced it, so the CSP builder can detect the policy you serve. A Permissions-Policy report never carries the served policy. The builder cannot see what you send today, so it starts from a preset, or from the policy you paste. The review then adds what your site was reported using.
For how the builder turns reports into grants, flags noise, and writes the header, refer to Builder decision rules.
Use it from the API and the MCP server
The REST API builds the same policy without the wizard. The Build a recommended Permissions-Policy endpoint takes an optional period and an optional starting policy, and returns two header values: policy for the Permissions-Policy header and reportingEndpoints for the Reporting-Endpoints header. Without a starting policy, it denies every listed feature, then grants back what your pages and frames used, with noise and third-party-only features left out. Refer to the API reference.
The Model Context Protocol (MCP) server exposes that endpoint as the build_recommended_permissions_policy tool.
Next steps
Builder decision rules
The rules the CSP builder follows to turn violation reports into sources, flag noise, detect the policy you serve, and fill in the CentralCSP baseline.
Get started
Build a Permissions-Policy from your reports. Pick a period and a preset, grant each feature to your pages and frames, then deploy in report-only mode.