Security Headers on a Redirect Domain

Michel Bardelmeijer is Tech Lead and Sales at redirect.pizza, where he helps DevOps and IT teams solve domain redirect challenges at scale. Michel has guided organizations like SD Worx, Zurich Airport and Harvard through complex redirect scenarios involving thousands of domains.

Have questions about bulk redirects, HTTPS migrations, or domain consolidations? Connect with Michel on LinkedIn or reach out to the redirect.pizza team.

Your security scan just came back. The old campaign domain, the one that only forwards to your new site, is missing six security headers. Six tickets for a forwarder? Hang on.

Most of those headers tell a browser how to handle the content it loads, and a redirect delivers none. The browser reads the new address and moves on. On that hop, only two of the six do any work: Strict-Transport-Security and Referrer-Policy. The other four are homework for the destination.

Here's why the scanner flags all six anyway, and how to send the right two without running your own server.

For the mechanics behind every redirect type, start with URL redirects explained.

Header for Security Headers on a Redirect: Two Matter, Four Don't, with six tiles of which two are highlighted

Key Takeaways

Four of the six headers do nothing on a redirect. Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and Permissions-Policy act on content the browser renders or runs, and a followed redirect delivers none.
Two headers act on the hop itself. The browser honors Strict-Transport-Security on any valid HTTPS response and applies Referrer-Policy to the request that follows.
Read the scan per header, not per grade. A missing HSTS header on the redirect is a real finding. The four document headers belong on the destination.
Preloading is no longer the default advice. hstspreload.org recommends HSTS but advises against preloading. Ramp max-age up in stages and treat preload as a commitment.
The certificate comes before any header. Without a valid one on the old hostname, any browser that remembers its HSTS policy hits a wall instead of a door.

Most security headers protect a page. A redirect never renders one.

Line up the six headers every scanner asks for, and you'll notice what most of them have in common:

Content-Security-Policy. Where scripts, styles and frames may come from.
X-Frame-Options. Whether this page may sit inside someone else's frame.
X-Content-Type-Options. Don't second-guess the declared content type.
Permissions-Policy. Which browser features the page may use.
Referrer-Policy. What the next site learns about where the visitor came from.
Strict-Transport-Security. Stop using plain HTTP for this hostname.

Five of the six are written for content the browser renders or runs. The sixth, HSTS, protects a hostname. A redirect response isn't a document, and that decides which headers matter on it. A 301 may carry a body, and the HTTP specification describes a short note with a link to the new address. The browser reads the Location header, drops that body without rendering it and moves on. Anything that only makes sense for a rendered page is never evaluated.

One of the five, Referrer-Policy, still acts on the redirect, because it shapes the request that comes next. More on that below.

On a 301, the browser reads two headers and ignores four

Put the six next to a redirect the browser follows on its own, a 301, 302, 303, 307 or 308, and the list splits cleanly in two.

Header	On the redirect the browser follows	Where it belongs
Strict-Transport-Security	Read and enforced, on any response received over valid HTTPS	On the HTTPS responses of the redirect hostname itself
Referrer-Policy	Read, and applied to the request the browser makes next	On the redirect response, whenever you care what referrer information the next request carries
Content-Security-Policy	Nothing to govern, because no document is rendered here	On the response that delivers the page
X-Frame-Options	Not evaluated, the framing check runs on the final response	On the document you want to keep out of frames, or CSP frame-ancestors
X-Content-Type-Options	Not evaluated on the hop the browser follows	On the content response, next to the right Content-Type
Permissions-Policy	No document, so no feature policy is set at this hop	On the response that delivers the document

The order is in the web standards: the fetch standard processes the redirect, and the HTML standard applies its framing and content policies to the final response it renders. RFC 6797 has the browser process HSTS on any response received over HTTPS, redirects included. For a preload submission, hstspreload.org even requires the header on the redirect itself, not on the page it lands on.

X-Frame-Options is the one people argue about. Chrome, Firefox and Safari all evaluate it on the response that renders the document, not on the redirect that led there. A framing rule on the redirect hop protects nothing. The same rule on the destination protects the page a visitor actually sees.

So on a redirect-only hostname, a finding about the other four describes the destination, not this response. API calls and other resource loads bring their own rules, including CORS.

The scanner is grading a page that doesn't exist

A scanner grades whatever the hostname sends back. Ask a redirect domain for its homepage and you get a 301, so the 301 gets the grade.

securityheaders.com is upfront about it in its FAQ. The R grade means the site responded with a redirect, and the scanner offers a link to follow it and grade the destination instead. A Qualys finding of the type HTTP Security Header Not Detected can list X-Content-Type-Options and Strict-Transport-Security as missing. On a 301, the first half of that finding is noise. The second half is the header the redirect should send on its HTTPS response. Over plain HTTP, browsers ignore it.

So a report like that is half right. A missing Content-Security-Policy on a redirect is true, and fine, because there's no document here for a policy to govern. A missing Strict-Transport-Security on the same response is worth acting on. Adding the full set to a redirect to close the report changes nothing for the visitor. It buries the two headers that do something under four that don't.

Before you resolve or escalate a finding, check the first response yourself instead of the grade:

curl -sS -D - -o /dev/null https://old.example/summer

That sends a GET, prints the response headers and doesn't follow the redirect. Certificate verification stays on. During a staged HSTS rollout the interesting lines look like this:

HTTP/2 301
location: https://shop.example/offer
strict-transport-security: max-age=300
referrer-policy: strict-origin-when-cross-origin

The five-minute max-age there is a test value, not a setting to leave in place. Then request the destination separately and grade that response on the full list. A 301 on the apex doesn't prove every path behaves the same way, so check the paths that do return pages, error pages included.

Where a scan does point at something real is the certificate. A scanner that can't complete the HTTPS handshake with the redirect domain is reporting a real problem. Every visitor who arrives over HTTPS hits the same one: no certificate on the old name, or an expired one.

What this looks like in a real portfolio

Digip ran into that from the client side. It manages about 8,000 domains for its clients, and its registrar partner only offered redirects over HTTP. Anyone who typed https:// in front of a redirected client domain got a browser security warning. That was tolerable on domains that weren't security sensitive. For a hospitality client with more than 1,500 hotel domains, it wasn't. When the partner confirmed HTTPS redirects weren't on its roadmap, Digip turned to redirect.pizza. Two years on, not a single downtime incident has turned into a client ticket.

For security teams that inventory every hostname the company owns, the practical fix is a tag. Hostnames that only redirect get the short list. Hostnames that serve a page get the full one. The certificate question is covered in why HTTPS redirects break, the HSTS question in redirecting a domain that used HSTS.

A scanner can't tell a redirect from a homepage, so it runs the homepage checklist. You can add all six headers to a 301 and close the ticket, but a Content-Security-Policy on a response that never renders anything protects nothing. It's decoration, and it makes the two headers that matter harder to find. My rule for a redirect-only hostname is short: a valid certificate, HSTS, and a referrer policy somebody chose on purpose. Then spend the afternoon on the destination, where the other four actually run.

Michel Bardelmeijer, Tech Lead at redirect.pizza

Referrer-Policy decides what the destination learns, and it isn't the redirect

The browser reads Referrer-Policy from a redirect response and applies it before it follows the Location header. That makes it the one document header worth sending from a hostname that never renders anything. What it controls is easy to get wrong. Picture a visitor clicking a link in a publisher's article:

publisher.example/article → old.example/summer → shop.example/offer

A click from publisher.example/article via old.example/summer to shop.example/offer, with the publisher's page as referrer

The referrer comes from the publisher's page, not from the redirect. Passing through old.example doesn't make old.example the referrer. A visitor who types the old address in the address bar sends no referrer at all.

What the destination actually receives

With HTTPS all the way and the browser default of strict-origin-when-cross-origin, the destination receives https://publisher.example/ and not the full article URL. Browser privacy settings can trim it further. Two values are worth knowing:

strict-origin-when-cross-origin when origin-level attribution across sites is useful. This is what browsers apply when nothing else is set.
no-referrer when the next request should carry no Referer header at all.

What Referrer-Policy doesn't touch

It never edits the Location header. Say your redirect points at a URL with utm_source, an email address or a customer ID in the query string. That information travels along, whatever the referrer policy says. Query forwarding is a separate decision, and on an old campaign domain it's worth a look.

Sending the header explicitly makes your intent readable. Leaving it out doesn't mean the browser has no policy, and no policy on the redirect can restore referrer information that was already stripped upstream. Unlike HSTS, Referrer-Policy is also processed on a plain HTTP redirect. And cross-origin means what the browser says it means: a different scheme, hostname or port, whether or not both sites belong to your company.

HSTS is the other one, and preload is no longer the advice

HSTS on a redirect domain does the same job it does on a site. Once the browser holds the policy, it rewrites http:// to https:// before the request leaves the machine, and it won't let anyone click through a certificate error. The plain HTTP hop is where an attacker would work, so removing it is the point.

The header only counts over HTTPS, and a redirect response carries it fine. No 200 OK page needed. Introduce it in stages. hstspreload.org's deployment recommendations start at max-age=300, five minutes, then move to a week and a month, with each stage running its full max-age before the next. The recommended values carry includeSubDomains, so check the subdomains first, internal ones included.

Preload is where the advice has changed, and plenty of tutorials haven't caught up. hstspreload.org now says it plainly: HSTS is recommended, HSTS preloading is not. Chrome and Safari already upgrade HTTP navigations on their own, so preloading only adds something when that upgrade fails against an active attacker. The same page asks projects that offer an HSTS switch not to ship the preload directive by default. What preloading still buys you, and what a removal costs, is in redirecting a domain that used HSTS.

Each domain needs its own policy

HSTS follows hostname rules, not redirect destinations. A policy on old.example does nothing for shop.example just because the first points at the second. They're separate domains, so each needs its own certificate and its own header. What the old name still needs after that, and for how long, is in retiring a domain without breaking it.

The exception: a frame redirect is a page, so it needs the full set

A frame redirect isn't a 301. It's a page.

A frame redirect, sometimes called a masked redirect, answers with a 200 and an HTML document. That document loads the destination inside a frame, so the address bar keeps the old name. The moment a hostname serves a document, every header on the list is back in play. X-Frame-Options or CSP frame-ancestors now decides whether someone else can wrap your framed page in their own. Content-Security-Policy governs the wrapper. X-Content-Type-Options and Permissions-Policy apply again. The destination may refuse to be framed at all, which stops the masked redirect from working.

The same goes for anything else on the hostname that renders: a meta refresh page, a parking page, a custom 404. The rule isn't "redirect domains don't need headers". The rule is "responses without a document don't need document headers". So check what the hostname actually returns. Afterwards, the address bar gives it away: a followed redirect ends on the destination address, a frame redirect keeps the old one.

Be strict one hop later, on the destination

The headers that get skipped on the redirect aren't optional. They belong one hop further.

The page the visitor lands on is where Content-Security-Policy stops injected scripts, where X-Frame-Options or frame-ancestors stops clickjacking, where Permissions-Policy keeps the camera off. Moving a domain doesn't remove that responsibility. It moves it to the destination hostname, which needs its own HSTS policy too.

The destination owns CSP, framing, and permissions

Cookies still ride along

A Set-Cookie header on a 301 is stored by the browser, subject to the usual cookie rules. A redirect domain that sets cookies is rare. If a legacy setup does it, ask whether the cookie is still needed. Then give its scope and its Secure, HttpOnly and SameSite flags the same scrutiny as on any page. Two headers and a certificate make a redirect correct, not automatically harmless.

Sending the two that matter without running your own server

A redirect domain on a DNS-level service has no nginx config to put headers in. The service has to send them for you, and it should send the right ones.

On redirect.pizza every hostname gets a certificate once its DNS records are verified, renewed automatically, which settles the one requirement that isn't a header. Automatic HTTPS runs on every plan, Free (Margherita) included.

HSTS with your own max-age

Enable HSTS at team level or per domain, and the HTTPS redirect response carries Strict-Transport-Security. The documented default is max-age=31536000, and you can adjust max-age and add includeSubDomains or preload. Preload stays off unless you add it, which is exactly what hstspreload.org asks of any tool with an HSTS switch. Start with your own short max-age, and only add preload once you've decided to pursue it. The directive signals consent to preloading. It doesn't put the domain on the list. With HSTS on, an HTTP request is upgraded to HTTPS on the same hostname first, before the redirect to the destination runs. That's the order the preload list asks for, if you ever do submit.

Referrer-Policy per hostname

Referrer-Policy is a setting too, since February 2026, at team level with an override per hostname. Set it wherever you want to decide what the destination sees, including hops between two of your own domains.

Framing protection and a firewall

Prevent foreign embedding adds X-Frame-Options: DENY, at team level or per domain. Read the frame redirect section before you flip it. On a plain 301 it's harmless and unread. On a frame redirect it's the header that keeps your masked page out of someone else's frame.

From Business (Quattro Stagioni) up, a web application firewall on the OWASP Core Rule Set checks the requests arriving at the redirect service. It blocks the ones matching common attack patterns, and blocked requests show up in the analytics view. That guards the redirect layer. The destination website still needs its own protection.

When the forwarder only speaks HTTP

A domain that forwards over plain HTTP only is a different story. There's no HTTPS response, so there's no HSTS, and the hop itself is open to anyone on the path. A Referrer-Policy can still be read from an HTTP redirect, but that's the smaller problem here. And if a browser still remembers an HSTS policy from when the site was live, it gets a certificate wall instead of a redirect. Registrars differ on what they support, so check what yours actually serves on the source hostname.

The checklist for redirect-only hostnames

Five checks. The first one isn't a header, it's the crust the rest sits on.

Confirm the hostname serves a valid certificate and answers HTTPS before the redirect happens.
Send Strict-Transport-Security on the HTTPS redirect response. Ramp max-age through five minutes, a week and a month, and leave preload alone unless you've decided to commit.
Decide what referrer information the next request should carry, and send Referrer-Policy to match. strict-origin-when-cross-origin is what browsers apply by default, and a sane floor.
Check what the hostname actually returns, on more than one path. A 301 needs nothing more. A frame redirect, parking page or custom 404 is a document and gets the full set.
Move the document headers to the destination, and give the destination its own HSTS policy. The redirect domain can't do that for it.

Five checks for redirect-only hostnames, starting with a valid certificate before the redirect happens

Try redirect.pizza on your own domains

A certificate for every domain, HSTS on the redirect, a referrer policy where it counts. Set up in minutes, with a few DNS records and no server of your own.

Get started for free

Frequently Asked Questions

Not on a redirect the browser follows. A redirect response may carry a body, but the browser reads the Location header and moves on without rendering it. A policy on that hop is never applied to anything. Put the policy on the response that delivers the page. The exception is a frame redirect, which serves an HTML page and therefore does need one.

Because the scanner grades the redirect response against the same list it uses for pages, and a redirect response legitimately lacks the document headers. Split the report. Whether the hostname serves valid HTTPS, whether it sends Strict-Transport-Security and what it sends as Referrer-Policy are all worth acting on. The four document headers describe a page this response never rendered, so record that and move on to the destination.

Not on a redirect the browser follows. Chrome, Firefox and Safari evaluate X-Frame-Options on the response that renders the document, so a header on the redirect hop does nothing. It does work on a frame redirect, because that's a real page. That's where an option like redirect.pizza's prevent foreign embedding earns its keep.