Loading…
Loading…
Paste any URL you're authorized to test. Scorifya fetches the response and shows your Permissions-Policy header alongside the rest of your security headers, so you can see which browser features are restricted.
Free tool
The Permissions-Policy header (formerly Feature-Policy) controls which powerful browser features, like camera, microphone, geolocation, and others, a page and anything it embeds are allowed to use. Without it, an embedded third-party frame or an injected script can request features your site never intended to use. A checker tells you whether a policy is set and how tight it is.
Paste any URL you're allowed to test. Scorifya fetches the response and reports your Permissions-Policy header, present or absent, so you can see whether browser features are locked down. It sits inside the broader 0 to 100 hardening score, so you see the headers around it too.
This page is written for people searching for Permissions-Policy checker—same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like—paste your URL above for a live score on your site.
Example A: no Permissions-Policy
TLS and most headers are fine, but no Permissions-Policy is sent, so the page and its embeds can request features like camera and geolocation by default.
Permissions-Policy missing
A short header that denies the features you do not use (camera, microphone, geolocation) tightens what an embed or injected script can ask the browser for. Add it even on a simple marketing site.
Example B: features locked down
A Permissions-Policy denies the browser features the site does not use, so embeds cannot request them. The remaining points are elsewhere in the header set.
Permissions-Policy set
Denying camera, microphone, geolocation, and similar features the site does not use is a one-line addition that costs nothing and closes a small but real gap.
Deny the features you do not use
Most marketing and content sites need none of the powerful features. A single line like Permissions-Policy: camera=(), microphone=(), geolocation=() denies them for the page and every embed. Add the ones your site genuinely needs back explicitly.
Scope features to your own origin when you do need them
If a page needs a feature like geolocation, grant it to your own origin only, not to embedded third parties, so a frame cannot piggyback on the permission.
Set it at one layer
Add Permissions-Policy in a single place: your web server, reverse proxy, or app framework. Setting it consistently across every response is what makes the protection reliable.
Re-scan after the header change
Headers update on the very next response after a deploy. Re-scan immediately to confirm the policy is being sent with the directives you expect.
For weights and penalties behind each category, see How Scorifya works.
Permissions-Policy is a response header that controls which browser features (such as camera, microphone, geolocation, autoplay, and payment) a page and any content it embeds are allowed to use. It replaced the older Feature-Policy header and lets you deny features your site does not need, reducing what an embed or injected script can request.
For most sites, deny the powerful features you do not use with a line like camera=(), microphone=(), geolocation=(). If a page genuinely needs a feature, grant it only to your own origin rather than to embedded third parties. The goal is to expose the smallest set of features necessary.
Permissions-Policy is the current standard and the successor to Feature-Policy. The syntax changed, so if you still serve a Feature-Policy header you should migrate to Permissions-Policy. Modern browsers honor Permissions-Policy.
Yes. Checking your Permissions-Policy (and running the full Scorifya scan) is free for any URL you're authorized to test. Pro adds higher rate limits, scheduled re-scans, watch lists with alerts, and exports.
No. Scorifya only fetches public, unauthenticated URLs. Header values can differ on authenticated routes, so test those during your own staging passes.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly—without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on config or deploying changes, you'll likely run multiple checks as you tighten things up. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.