Set a Referrer-Policy header
The Referrer-Policy header controls how much referrer information is sent when navigating from your site to another, protecting user privacy and preventing leaking sensitive URL parameters.
- Use `Referrer-Policy: strict-origin-when-cross-origin` — the recommended modern default
- `strict-origin-when-cross-origin` sends the full URL for same-origin requests, only the origin for cross-origin HTTPS, and nothing for HTTPS→HTTP
- Never use `unsafe-url` — it sends the full URL including path and query string to every external site
- Can be set via HTTP header, `<meta>` tag, or the `referrerpolicy` attribute on individual `<a>` and `<img>` elements
- Sensitive URLs (reset tokens, private IDs) in query strings can be exposed via the Referer header if policy is too permissive
Rule Details
When a user clicks a link or a page loads a resource, browsers send a Referer header to the destination server. The Referrer-Policy header controls how much of the originating URL is included in that header.
Code Example
Referrer-Policy: strict-origin-when-cross-originWhy It Matters
Without a Referrer-Policy, a password reset link such as /reset?token=abc123 is included in the Referer header when the user clicks an external link on that page, leaking the token to third parties.
Available Policy Values
| Value | Same-origin requests | Cross-origin HTTPS | HTTPS → HTTP |
|---|---|---|---|
no-referrer | Nothing | Nothing | Nothing |
no-referrer-when-downgrade | Full URL | Full URL | Nothing |
origin | Origin only | Origin only | Origin only |
origin-when-cross-origin | Full URL | Origin only | Origin only |
same-origin | Full URL | Nothing | Nothing |
strict-origin | Origin only | Origin only | Nothing |
strict-origin-when-cross-origin | Full URL | Origin only | Nothing |
unsafe-url | Full URL | Full URL | Full URL |
Recommended: strict-origin-when-cross-origin — this is the browser default as of Chrome 85+ and Firefox 87+. Set it explicitly to ensure consistent behavior across all browsers.
Server Configuration
Nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;Apache
<IfModule mod_headers.c>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>Next.js
// next.config.js
const nextConfig = {
async headers() {
return [
{
source: '/(.*)',
headers: [
{
key: 'Referrer-Policy',
value: 'strict-origin-when-cross-origin',
},
],
},
]
},
}Express.js (using Helmet)
import helmet from 'helmet'
app.use(
helmet.referrerPolicy({
policy: 'strict-origin-when-cross-origin',
})
)HTML Meta Tag (Page-level)
<meta name="referrer" content="strict-origin-when-cross-origin">Per-Element Control
Override the policy for specific links or resources:
<!-- No referrer for this external link -->
<a href="https://external.com" referrerpolicy="no-referrer">External</a>
<!-- Send full URL only to same origin -->
<a href="https://partner.com/track" referrerpolicy="origin">Partner</a>
<!-- No referrer for this image request -->
<img src="https://analytics.example.com/pixel.gif" referrerpolicy="no-referrer">What Gets Leaked Without a Policy
Consider a user on /reset-password?token=xK9mP2qR&user=42 who clicks an external link. Without a strict Referrer-Policy (opens in new tab):
Referer: https://app.example.com/reset-password?token=xK9mP2qR&user=42The third-party site receives the full URL including the password reset token.
Even with a good Referrer-Policy, placing sensitive tokens in query strings is a security smell — they may appear in server logs, browser history, and shared links. Prefer tokens in the URL path or HTTP POST bodies, and rotate tokens immediately after use.
Exceptions
- A missing or weak header should be evaluated against the live production response path, not only the framework or server config in isolation.
- Legacy integrations or embedded third-party content may require narrowly scoped exceptions, but they should be documented explicitly instead of left permissive by default.
- When multiple security headers are missing, prioritize the header that removes the highest exploitability or browser capability first.
Support Notes
- The feature is supported across the current project browser matrix.
- Baseline-compatible minimums: chrome 115, edge 115, firefox 116, safari 16.4, safari_ios 16.4.
- Add a fallback or a narrower policy note when a required project target falls outside that support range.
Verification
Automated Checks
- Inspect the effective response headers with curl, a security header scanner, or equivalent tooling against representative live responses.
Manual Checks
- Verify the browser or user-facing behavior manually in a production-like flow and confirm there is no stronger conflicting security signal.
Use with AI
Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.
Check
Verify implementation
Check whether the server sends a Referrer-Policy header and verify the value is appropriate. The recommended value is strict-origin-when-cross-origin. Check for any pages with sensitive URL parameters that could be leaked via the Referer header.
Fix
Auto-fix issues
Add Referrer-Policy: strict-origin-when-cross-origin to all HTTP responses. Configure it in your web server, CDN, or application framework. For pages with particularly sensitive URLs, consider no-referrer or same-origin.
Explain
Learn more
Explain what the Referer header contains, how a permissive Referrer-Policy can leak sensitive URL parameters to third parties, and what the difference is between the various Referrer-Policy values.
Review
Code review
Review server config, headers, forms, and integration points related to Set a Referrer-Policy header. Flag exact responses, cookies, or browser behaviors that violate the rule, and verify them against the effective production-like response.