A missing secure Referrer-Policy header means the application has not explicitly defined how much of the current page URL a browser may disclose when the page loads another resource or sends a user to another location.

MDN defines Referrer-Policy as the HTTP response header that controls how much referrer information is included in requests. For most public websites and web applications, the practical baseline is:

Referrer-Policy: strict-origin-when-cross-origin

OWASP recommends explicitly sending strict-origin-when-cross-origin on responses. It preserves complete same-origin referrer information, reduces secure cross-origin disclosure to the origin, and suppresses the referrer during an HTTPS-to-HTTP downgrade.

What Does “Missing Secure Referrer-Policy Header” Mean?

The Referer request header can contain the source origin, path, and query string. The spelling is intentionally historical: the request header is named Referer, while the controlling response header uses the correct spelling, Referrer-Policy.

Modern browser behavior defaults to strict-origin-when-cross-origin when no valid policy is specified. That default reduces risk in current browsers, but relying on an implicit user-agent default creates several problems:

Is the finding always high severity?

No. The impact is contextual. A static marketing page with clean URLs usually has lower exposure than an authenticated portal whose URLs contain account references, search terms, invitation identifiers, workflow state, or other user-specific data. The finding becomes more important when pages make cross-origin requests, load third-party content, link to external domains, or expose sensitive information in paths and query strings.

For a wider review of this scanner category, see Ammune’s guide to an HTTP security header not detected.

Security and Privacy Risks of an Unsafe or Missing Policy

Full path and query disclosure

A Referer value may include the source path and query string. Under a permissive policy, a navigation or resource request can reveal details such as the page a user viewed, an internal workflow name, a search query, a document identifier, a campaign parameter, or a tenant-specific route to another origin.

Sensitive values embedded in URLs

OWASP explains that sensitive information placed in query strings can appear in browser history, server logs, proxy logs, and Referer headers, and that HTTPS alone does not eliminate this exposure. Referrer-Policy reduces one channel, but the primary remediation is to keep confidential data out of URLs.

Third-party resource visibility

Analytics services, advertising tags, fonts, images, scripts, error-reporting services, support widgets, payment providers, identity providers, embedded media, and external links may receive referrer information. web.dev recommends reviewing whether URLs contain identifying or sensitive information before choosing a policy.

Downgrade leakage

Strict policies suppress the Referer header when a secure HTTPS page requests or navigates to a less secure HTTP destination. The permissive unsafe-url directive can send the full origin, path, and query string regardless of the destination’s security level.

False trust in inbound Referer

The header is not an authentication or authorization mechanism. Nginx’s official referer-module documentation warns that a Referer value is easy to fabricate, and OWASP advises applications not to rely on the URL or referrer when making authorization decisions.

Referrer-Policy Directives Compared

The current Referrer-Policy header supports eight documented directives. The table below translates their behavior into deployment guidance.

MDN recommends selecting the strictest policy that still allows the site to operate correctly. The value should be based on actual product requirements rather than a blanket assumption that every site needs the same balance.

How to Choose the Right Secure Policy

Decision framework

1. Inventory browser-rendered documents, external links, redirects, iframes, and third-party resources
2. Identify URLs containing user, tenant, transaction, workflow, search, invitation, or recovery context
3. Remove secrets and sensitive identifiers from paths and query strings
4. List legitimate consumers of referrer information and the minimum detail they need
5. Start with strict-origin-when-cross-origin
6. Test same-origin, secure cross-origin, and HTTPS-to-HTTP behavior
7. Move sensitive sections to same-origin or no-referrer when appropriate
8. Add element-specific exceptions only when a documented integration requires them
9. Deploy at one authoritative layer and prevent conflicting duplicates
10. Monitor the effective header and integration outcomes after every release

Header, Meta Tag, Element Attribute, and Link Precedence

The HTML Standard defines an order in which referrer-policy signals are applied: a noreferrer link relationship can override other values, followed by an element’s referrerpolicy attribute, a document-level meta referrer value, and then the HTTP Referrer-Policy header.

MDN documents the meta referrer option, while the HTML Standard documents the referrerpolicy attribute for hyperlinks and external resource links. Keep exceptions rare, explicit, and testable.

How to Fix the Missing Header on Common Platforms

Generic HTTP response

Referrer-Policy: strict-origin-when-cross-origin

Apply the header to browser-rendered HTML responses, redirects, error pages, and any route that can initiate browser navigation or resource loading. Verify whether the edge, reverse proxy, application, or framework already emits a value before adding another one.

Nginx

Nginx documents the add_header directive and its always parameter for adding arbitrary response headers across response codes.

server {
    listen 443 ssl;
    server_name app.example.com;

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

    location / {
        proxy_pass http://application_backend;
    }
}

Test normal responses, redirects, authentication failures, application errors, and static files. Nginx header inheritance can change when a lower configuration block defines its own add_header directives, so inspect every relevant location.

Apache HTTP Server

Apache mod_headers provides directives to set, replace, merge, or remove response headers.

<IfModule mod_headers.c>
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Use the normal late-processing mode for production and verify that upstream applications or proxy modules do not add a second conflicting value.

Microsoft IIS

Microsoft documents adding custom HTTP response headers at the site or application level in IIS.

<configuration>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="Referrer-Policy" />
        <add name="Referrer-Policy"
             value="strict-origin-when-cross-origin" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Prefer site-specific configuration over a server-wide value when different applications have different privacy and integration requirements.

Node.js and Express with Helmet

Helmet documents the referrerPolicy configuration and uses no-referrer as its current default when Helmet is applied without an override.

import express from "express";
import helmet from "helmet";

const app = express();

app.use(
  helmet({
    referrerPolicy: {
      policy: "strict-origin-when-cross-origin",
    },
  })
);

Confirm whether the stricter Helmet default is acceptable. Explicitly configure the chosen policy so future dependency changes do not silently change the application contract.

Next.js

Next.js documents setting response headers through the headers option in next.config.js.

const nextConfig = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          {
            key: "Referrer-Policy",
            value: "strict-origin-when-cross-origin",
          },
        ],
      },
    ];
  },
};

export default nextConfig;

If a CDN or hosting platform also adds the header, decide which layer is authoritative and remove duplicate configuration.

HTML meta fallback

The HTML meta referrer element can set a document policy when server headers cannot be changed.

<meta name="referrer"
      content="strict-origin-when-cross-origin">

The response header remains preferable for centralized enforcement. A meta tag is parsed from the document and does not provide the same edge-level governance.

Per-link and per-iframe restrictions

<a href="https://external.example/"
   referrerpolicy="no-referrer">
  Open external service
</a>

<iframe src="https://partner.example/widget"
        referrerpolicy="origin">
</iframe>

Use element-level policies only for narrow, documented needs. A patchwork of exceptions is harder to audit than a strong global policy with a small number of reviewed overrides.

Setting Referrer-Policy at the CDN or Cloud Edge

Edge enforcement is useful when multiple origins, legacy applications, static sites, and error responses need one consistent policy. It also creates a risk of duplication if the origin already sets the header.

How to Test the Effective Referrer-Policy

1. Inspect the public response with curl

curl documents the -I or --head option for retrieving HTTP headers.

curl -I https://app.example.com/

curl -sS -D - -o /dev/null https://app.example.com/login

curl -sS -D - -o /dev/null https://app.example.com/not-found

Verify the main page, authentication pages, redirects, not-found responses, server errors, static pages, alternate hostnames, language routes, and cached edge responses.

2. Inspect the browser Network panel

Chrome DevTools documents viewing Response Headers and Request Headers for each network request. Confirm both the policy received by the page and the actual Referer sent on subsequent requests.

3. Test all three request relationships

4. Prototype before deployment

Chrome DevTools supports local response-header overrides. This can help teams test analytics, external links, payment redirects, identity flows, embedded resources, and application behavior before changing the production edge or origin.

5. Use a security-header scanner

Mozilla’s HTTP Observatory evaluates HTTP headers and other security configurations. Treat the scan as one input: verify real browser behavior, route coverage, and application context rather than relying only on a grade.

6. Add automated deployment checks

Validation requirements
- Exactly one effective Referrer-Policy value
- Expected value on HTML documents, redirects, and error responses
- No unsafe-url or unintended legacy value
- No CDN and origin conflict
- Same-origin behavior matches product analytics needs
- Cross-origin requests disclose only approved detail
- HTTPS-to-HTTP requests omit the Referer
- Sensitive values are absent from URLs
- Element-level overrides are inventoried and approved
- Monitoring alerts when the public header changes

Common Problems and Troubleshooting

Avoid conflicting or invalid values

Send a single approved policy unless you deliberately use the documented fallback syntax. Invalid values can cause the browser default to apply, which defeats the purpose of explicit governance. Confirm the exact wire response after all proxies and edge services process it.

Do not use Referer as access control

OWASP recommends rechecking authorization on every request rather than relying on the URL, referrer, or a request flag. Use authenticated identity, object ownership, tenant boundaries, permissions, and server-side policy.

Do not confuse Referrer-Policy with CORS

The Origin request header provides origin-level security context and does not disclose a path. CORS controls whether browser scripts can read cross-origin responses; Referrer-Policy controls the amount of source-page information sent with requests. They solve different problems.

Related Browser and API Security Controls

Referrer-Policy should be part of a broader security baseline rather than deployed alone.

What Referrer-Policy Means for APIs

Referrer-Policy is a browser privacy control. It does not authenticate an API client, authorize an object, validate a token, detect BOLA or IDOR, prevent business logic abuse, stop enumeration, inspect response data, or identify exfiltration. A secure frontend can still call an insecure API, and a protected API can still be targeted by non-browser clients that do not follow browser referrer behavior.

Where the header matters in an API application

• Browser-rendered API portals, developer portals, admin consoles, customer dashboards, and documentation sites.
• Single-page applications that navigate to external identity, payment, support, analytics, or partner services.
• Pages whose paths or query strings contain API keys, tokens, invitation values, tenant references, object identifiers, or workflow state that should be removed.
• Embedded API explorers, iframes, scripts, images, and third-party integrations with element-level referrer policies.
• Edge-delivered error pages and redirects that may not inherit application-layer security headers.

Where separate API controls are required

Use authentication, authorization, schema validation, rate controls, behavior analytics, sensitive-data detection, request and response inspection, audit evidence, and incident response. Ammune’s REST API endpoint security guidance and API sensitive-data protection strategy cover these runtime concerns.

How Ammune Complements Referrer-Policy

Ammune can complement browser-side Referrer-Policy hardening with runtime API visibility and protection. The header controls what browsers disclose about the source page; Ammune focuses on what actually happens in live API traffic.

Browser header versus runtime API security

Review Ammune’s API runtime security protection platform guide, compare API security testing with runtime monitoring, and align event delivery with the centralized SIEM log-forwarding guide.

Referrer-Policy Remediation Checklist

Common Referrer-Policy Mistakes

1. Relying only on the browser default. Send an explicit policy so the intended behavior is auditable and consistent.
2. Using unsafe-url to preserve analytics. Replace implicit full-URL referral dependencies with explicit attribution.
3. Putting secrets in URLs and expecting the header to solve it. Remove the sensitive values at the application design level.
4. Setting the header only on the homepage. Cover authenticated pages, redirects, errors, alternate hosts, and edge-generated responses.
5. Adding the value at every layer. Duplicate origin, proxy, framework, and CDN values create ambiguity and troubleshooting problems.
6. Breaking a payment or identity flow without testing. Validate external redirects and embedded integrations before enforcement.
7. Using Referer for authorization. It can be absent or fabricated and is not a trustworthy permission signal.
8. Confusing Referrer-Policy with CORS, CSP, HSTS, or CSRF protection. Each control addresses a different browser or transport risk.
9. Ignoring element-level overrides. A link, iframe, script, image, or programmatic request can intentionally apply a different policy.
10. Treating an API header grade as an API security assessment. Test authorization, business logic, data exposure, abuse, and runtime behavior separately.

Conclusion

The strongest general fix for a missing secure Referrer-Policy header is to explicitly send Referrer-Policy: strict-origin-when-cross-origin, verify it on every relevant public response, remove sensitive information from URLs, test external integrations, and document any stricter or element-specific exceptions.

The header is valuable, but it addresses one browser privacy channel. Complete application and API security also requires secure transport, content controls, authentication, authorization, sensitive-data minimization, API discovery, request and response visibility, behavior analytics, SIEM integration, and rehearsed incident response. Ammune can complement the header by providing the runtime API context that browser policy alone cannot deliver.

Frequently Asked Questions