Referrer-Policy & Permissions-Policy Checker
Sends one real HTTP GET request to a URL you choose and classifies the response's Referrer-Policy and Permissions-Policy headers into well-documented misconfiguration patterns: unsafe-url leaking the full URL on every request (even a downgrade), a missing or unrecognised Referrer-Policy, a Permissions-Policy directive with a malformed allowlist, and a wildcard allowlist on a sensitive feature like camera or microphone. Only point it at a system you own or are authorised to test.
1. Run the CLI against your site
Node.js, no dependencies to install:
node check.mjs https://example.com --jsonGet check.mjs, probe.mjs, and analyze.mjs from the repo — plain Node, nothing to install. It only ever talks to the URL you pass; nothing goes through this site.
2. Paste the JSON output here
Paste the JSON from step 1 and click Check.
Report
Raw headers checked
| Header | Value |
|---|
Common questions
Why is Referrer-Policy: unsafe-url dangerous?
unsafe-url sends the document's full URL -- including its path and query string -- as the Referer header on every outbound request this page makes, including a request that downgrades from HTTPS to plain HTTP. A query string carrying a session token, a password-reset code, or any other sensitive value is then readable by every third-party resource the page loads and by anyone who can observe that HTTP request in transit.
What happens if a Referrer-Policy value isn't recognised?
A conforming browser treats an unrecognised token as if that entry were absent. If none of the comma-separated values in the header is a real policy token, the header has no effect at all -- the browser silently falls back to its own default policy, with nothing in the response to say so.
How does a Permissions-Policy allowlist have to be written?
Per the Permissions Policy spec's structured-header-based syntax, a directive's value is either the bare wildcard *, or a parenthesised list whose items are self, src, or a double-quoted origin string -- for example camera=(self) or geolocation=(self "https://example.com"). A bare, unparenthesised origin, an unquoted origin inside the parens, or unbalanced parentheses does not match that shape, and browsers do not all handle a malformed directive the same way.
Why flag a wildcard allowlist on camera or microphone?
A wildcard (*) allowlist on a sensitive feature grants that capability to every origin the document ever embeds as an iframe, not just to the site's own origin. A third-party ad, widget, or analytics iframe added later inherits the same access automatically, with no further change to this header -- an explicit allowlist naming only the origins that should have it avoids that quiet expansion.
Does a clean report mean the site's privacy and permissions posture is fully correct?
No. This checks a specific, well-documented set of Referrer-Policy and Permissions-Policy patterns from one response -- it is not a full privacy or security audit, does not crawl other pages on the site, and cannot see a misconfiguration this tool's checks don't happen to cover (Content-Security-Policy and frame-ancestors are out of scope here -- see security-headers-check for those). Treat a clean report as evidence about these specific patterns, not a determination that the site's privacy posture is optimal.