Skip to main content

Referrer-Policy.

Security Headers & TLS Config

Controls what URL data is leaked to third-party sites when users click links

What does this check test?

The `Referrer-Policy` header controls how much URL information is included in the `Referer` header when navigating away from your site or loading external resources. Policies range from `no-referrer` (send nothing) to `unsafe-url` (send the full URL including path and query string). Common recommended values include `strict-origin-when-cross-origin` (sends only the origin to cross-origin requests, full URL to same-origin) and `no-referrer-when-downgrade` (omits referrer on HTTPS-to-HTTP transitions).

Why does it matter?

URLs frequently contain sensitive data: session tokens in query parameters, search queries revealing user behavior, internal path structures, and even authentication tokens in password reset links. Without a Referrer-Policy, clicking any outbound link or loading any third-party resource leaks the full URL to that third party. This can expose private information to analytics providers, advertisers, and potentially malicious sites. Setting a restrictive referrer policy limits this data leakage.

Who is affected?

Every web application should set a Referrer-Policy, especially those that include sensitive data in URLs (search queries, user IDs, tokens, internal paths). SaaS applications, healthcare platforms, and financial services face regulatory requirements around data leakage that make this header essential. Even if your URLs contain no sensitive data today, setting a restrictive policy is a proactive defense against future leaks.

Where does this apply?

The `Referrer-Policy` header should be set on all HTML page responses. It can also be set on individual elements using the `referrerpolicy` attribute (e.g., on `<a>`, `<img>`, or `<script>` tags) for more granular control. Configure it at the server, CDN, or application middleware level for global coverage.

How to fix it

For most applications, `strict-origin-when-cross-origin` provides a good balance of security and functionality.

Nginx

nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Node.js / Express

js
const helmet = require('helmet');
app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }));

Django

python
SECURE_REFERRER_POLICY = 'strict-origin-when-cross-origin'

Flask

python
@app.after_request
def set_headers(response):
    response.headers['Referrer-Policy'] = 'strict-origin-when-cross-origin'
    return response

Next.js

js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [{ key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' }]
    }];
  }
};

Spring Boot

java
http.headers().referrerPolicy(ReferrerPolicyHeaderWriter.ReferrerPolicy.STRICT_ORIGIN_WHEN_CROSS_ORIGIN);

more sensitive applications, consider `no-referrer` or `same-origin`. You can also set it per-element in HTML

html
<a href="https://external.com" referrerpolicy="no-referrer">Link</a>
Test by inspecting the `Referer` header in your browser's network tab when navigating to external sites.

References

AppVet checks Referrer-Policy automatically

Run a free security scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit