Missing Referrer-Policy and Permissions-Policy Headers

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Security Misconfiguration / Missing HTTP Headers
Typical Severity Medium
OWASP A05:2021 – Security Misconfiguration
CWE CWE-693 – Protection Mechanism Failure
Also known as Missing Feature-Policy, Missing Privacy Headers, Referrer Leakage
Affected systems All web applications and sites served over HTTP/HTTPS
Relevant standards W3C Referrer Policy (W3C Rec), W3C Permissions Policy (W3C Spec), RFC 7231 §5.5.2

Overview

Two distinct but complementary HTTP response headers govern information leakage and browser feature access in modern web applications:

  • Referrer-Policy controls how much referrer information (the full URL of the originating page) the browser includes in the Referer request header when navigating away or loading sub-resources. Without an explicit policy, browsers fall back to their own default — typically sending the full URL to third-party destinations, which may include tokens, session identifiers, or other sensitive path components.
  • Permissions-Policy (formerly Feature-Policy) is a declarative mechanism that lets a site restrict or allow which browser APIs and hardware features — such as the camera, microphone, geolocation, payment handler, or USB access — can be used by the page itself or by embedded iframes. Without this header, all features permitted by the browser's defaults remain available, increasing the attack surface exposed to third-party scripts or malicious iframes.

Sensagraph automatically detects the absence or weak configuration of both headers during passive HTTP response analysis.

How it works

Referrer-Policy

When a user clicks a link or a page loads an external resource (image, script, stylesheet), the browser attaches a Referer HTTP header to the outbound request. The value included depends on the active Referrer-Policy. Without a restrictive policy:

  • The full URL — including query parameters such as ?token=abc123&user=42 — is sent to the third-party server.
  • Analytics providers, CDN operators, and advertising networks can log these URLs, potentially capturing authentication tokens, password-reset links, or personally identifiable information encoded in the path.
  • Server access logs at third-party destinations permanently record the leaked URLs.
  • Cross-origin requests initiated by injected scripts or XSS payloads can exfiltrate navigation context via the referrer field.

The browser default for cross-origin navigations is currently strict-origin-when-cross-origin in most modern browsers, but this is not guaranteed across all browsers and versions, and the header should be set explicitly to enforce a predictable policy.

Permissions-Policy

Without a Permissions-Policy header, the browser applies its built-in defaults, which typically allow the top-level page to access many powerful APIs upon user consent, and may allow iframes from the same or cross-origin to inherit those permissions. This creates the following risks:

  • Third-party scripts (e.g., analytics, advertising, widgets) included on the page can request access to the camera, microphone, or geolocation API, subject only to user consent prompts — prompts that may be social-engineered or presented in a misleading context.
  • Malicious or compromised iframes may attempt to invoke payment APIs, USB access, or screen capture if not explicitly denied.
  • Supply-chain attacks that introduce malicious third-party JavaScript can exploit unrestricted feature access to harvest sensitive data.

Business impact

The absence of these headers has direct operational, compliance, and reputational consequences:

  • Privacy and compliance risk: Referrer leakage of URLs containing user identifiers or session tokens may constitute a personal data breach under GDPR (Article 32) and similar regulations, potentially triggering mandatory breach notifications and regulatory fines.
  • Authentication token exposure: Password-reset links, magic-login URLs, and OAuth state parameters embedded in URLs can be harvested by third-party servers from the Referer header, enabling account takeover without credential theft.
  • Expanded attack surface: A missing Permissions-Policy header means a successful XSS attack or supply-chain compromise gains access to all browser APIs allowed by defaults, dramatically increasing the potential impact of such incidents.
  • User trust and legal liability: Regulatory frameworks such as PCI DSS and ISO 27001 increasingly reference secure header configuration as a baseline control. Auditors may flag their absence as a finding requiring remediation.

How to fix it

Referrer-Policy

  1. Add an explicit Referrer-Policy response header to all HTTP responses. The recommended value for most applications is strict-origin-when-cross-origin, which sends only the origin (scheme + host) on cross-origin requests and the full URL on same-origin requests: 
    Referrer-Policy: strict-origin-when-cross-origin
  2. For applications that must not leak any referrer information to third parties (e.g., healthcare, financial), use no-referrer or same-origin: 
    Referrer-Policy: no-referrer
  3. Avoid unsafe-url or omitting the header entirely on applications that encode sensitive data in URL parameters.
  4. For granular per-link control, the referrerpolicy HTML attribute can override the header on individual anchor or iframe elements.
  5. Configure the header at the web server or reverse proxy layer (Apache, Nginx, CDN) rather than relying on application code to ensure consistent coverage across all responses.

Permissions-Policy

  1. Audit which browser features your application genuinely requires and deny all others by default. A deny-by-default baseline: 
    Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=()
  2. Allow features only for the specific origins that need them: 
    Permissions-Policy: geolocation=(self "https://maps.example.com")
  3. Restrict embedded iframes from inheriting permissions by setting the allow attribute explicitly on each <iframe> element: 
    <iframe src="..." allow="payment 'none'"></iframe>
  4. Combine with a Content Security Policy (CSP) to prevent unauthorised script execution that could attempt to invoke restricted APIs.
  5. Regularly review and update the policy as the application's feature set and third-party integrations evolve.

References

Frequently asked questions

Referrer-Policy controls how much URL information the browser sends in the Referer request header when navigating to or loading resources from other origins, protecting against URL-based data leakage. Permissions-Policy is a separate mechanism that restricts which browser APIs (camera, microphone, geolocation, payment, etc.) the page and its embedded iframes are allowed to use, reducing the feature-level attack surface.

For most applications, strict-origin-when-cross-origin is the recommended balance: it sends the full URL for same-origin requests (enabling server-side analytics) while sending only the origin (scheme + hostname) for cross-origin requests. Applications that must not disclose any referrer to external parties should use no-referrer or same-origin.

Neither header absence is directly exploitable in the same way as injection vulnerabilities, but they facilitate indirect attacks. Referrer leakage can expose authentication tokens and PII in third-party server logs, enabling account takeover. A missing Permissions-Policy amplifies the impact of XSS or supply-chain attacks by leaving powerful browser APIs unrestricted and accessible to malicious scripts.

Permissions-Policy is the standardised successor to the earlier Feature-Policy header. Feature-Policy used a different syntax and was experimental. Modern browsers support Permissions-Policy; Feature-Policy support is being phased out. Applications that still send Feature-Policy headers should migrate to the Permissions-Policy syntax.

A strict policy such as no-referrer will remove all referrer data from outbound requests, which may affect traffic-source attribution in analytics platforms that rely on the Referer header. The strict-origin-when-cross-origin value is typically a workable compromise: it preserves the origin information that analytics tools need while preventing full URL leakage, including any sensitive query parameters.