The request your redirect never sees
Almost every site with a certificate does the same thing: answer port 80 with a 301 to the https:// address. That is correct, and you should keep it. It just happens one request too late.
When somebody types example.com into the address bar, follows a link from an old email, or opens a bookmark from years ago, the browser has no reason to assume HTTPS. It opens a plain HTTP connection and asks for the page. Your redirect answers — but the question was already sent in the clear, across whatever network the visitor happens to be on: a café, an airport, a hotel, a captive portal, a home router nobody has updated.
Anyone positioned to read that request is also positioned to answer it. Instead of relaying your 301, they serve their own copy of your site over HTTP and quietly proxy everything to you over HTTPS. The visitor sees a page that looks right, minus a padlock almost nobody checks, and types a password into it. This is called SSL stripping, and it is a downgrade attack aimed at precisely the request your redirect exists to fix.
HSTS removes that request from the world. Once the browser has seen the header, it rewrites http://example.com/... to https://... internally, before anything leaves the device. There is no plaintext request to intercept, and no certificate warning the visitor can click through.
What the header says
Strict-Transport-Security: max-age=31536000 is the whole thing in practice. Three settings can appear in it, and they differ enormously in how much they commit you to.
max-age is the only required one: how many seconds the browser should remember that this host is HTTPS-only. 31536000 is a year. The clock resets on every response, so an actively visited site keeps a full year in front of it permanently, while a site nobody visits eventually forgets.
includeSubDomains extends the rule to every name under yours — www, api, shop, staging, and the one you forgot about. It is genuinely stronger, because a cookie set on a parent domain can be attacked through any subdomain of it. It is also the setting that breaks things, because it applies to hosts you may not control and may not have certificates for.
preload asks for your domain to be compiled into browsers themselves, so HTTPS-only applies before a visitor has ever been to your site. It requires includeSubDomains and a long max-age, and it is very hard to reverse.
One rule underlies all three: the header only counts on an HTTPS response. Browsers deliberately ignore it over plain HTTP, because honouring it there would let anyone on the network pin a domain they do not own.
Why we send max-age only
The preset on cdn.com.tr sends max-age=31536000 and nothing else. That is a deliberate default rather than a limitation, and it is worth understanding what the other two settings would commit you to.
includeSubDomains reaches names that are not in front of you on the page where you enabled it: a legacy mail. host on an old server, a status. page, an internal tool on a subdomain that has answered plain HTTP for years. The moment a browser has the rule, every one of those becomes unreachable in that browser — not a warning, a hard failure — and removing the header does not fix it, because the browser already wrote the rule down.
preload fails in the same direction, only slower: withdrawal is a submission to a third-party list followed by a wait for browser releases to ship, measured in months.
A one-year max-age on the hostname you are actually serving gives you the entire security benefit for that hostname from the first visit onwards. The stronger flags are worth adding later, deliberately, once every name under your domain has been inventoried and moved to HTTPS. Start where you can be certain rather than where you can be sorry.
The checklist before you switch it on
HSTS is not risky. Enabling it on a site that is not ready is. Work through this first.
Every page loads over HTTPS. Not just the homepage: the admin area, the API, upload endpoints, webhook targets, old campaign URLs. Anything that only works on port 80 stops working for everyone who has seen the header.
The certificate is valid and renews itself. Under HSTS an expired certificate is no longer a warning a visitor can dismiss — it is a wall. Certificates on cdn.com.tr are issued and renewed automatically, which is exactly the property HSTS assumes you have.
Mixed content is gone. Scripts, stylesheets, images and iframes referenced with http:// should already be fixed; HSTS only makes their failure louder.
You know what your subdomains are doing. Not because you are enabling includeSubDomains today, but because you will want to eventually, and the inventory is the actual work.
Your HTTP-to-HTTPS redirect stays in place. HSTS protects browsers that have seen the header; the redirect catches everyone else. They are not alternatives to each other.
Turning it on
In the panel, open Delivery rules → Security presets. The "Security setting" field is a multiselect of the edge presets that apply to the account: pick Hsts and save. The page lives at /management/cdn/advanced-management.
The setting is per account, so a hostname that is not ready yet can simply wait on an account of its own instead of holding up the ones that are.
Once saved, the edge adds the header to HTTPS responses for that account and only to HTTPS responses — a plain HTTP request still gets your redirect, with no header attached, which is the behaviour the specification requires. Nothing about your origin changes: there is no header to add in nginx, Apache or your framework, because the edge is where the visitor-facing answer is decided.
Verifying it in ten seconds
Ask for the headers and look for the one line. Two results matter, and the second one is the check people skip.
The header belongs on HTTPS responses and nowhere else
# should print: strict-transport-security: max-age=31536000
curl -sI https://example.com/ | grep -i strict-transport
# should print nothing at all
curl -sI http://example.com/ | grep -i strict-transportWhat the browser remembers
The command line tells you what you are sending. The browser is where the header actually does its work, and it is worth confirming once that the rule landed.
Visit the site over HTTPS, then open a new tab and type the bare hostname. The address bar should jump straight to https:// — the rewrite happens inside the browser, so there is no request on the wire to be intercepted and no redirect to follow. Chrome exposes what it has stored at chrome://net-internals/#hsts, including the expiry, which is useful when you are testing rather than guessing.
Two habits save confusion here. Test from a browser profile that has never visited the site when you want to see first-visit behaviour, and remember that a browser which learned the rule before you changed anything will keep acting on it — which is the subject of the next section.
Rolling back, and what rollback cannot do
Deselect Hsts in the same multiselect and save. The edge stops sending the header immediately, and any browser that never saw it behaves normally from then on.
What does not happen is the part that surprises people: browsers that already recorded the rule keep enforcing it until their max-age runs out. Turning the preset off does not reach into them. With a one-year max-age, a visitor who saw the header yesterday will keep forcing HTTPS for a year regardless of what your server says now.
The specification does provide a wind-down for that case — serving the header with max-age=0 tells a browser to forget the rule the next time it visits over HTTPS. It only works while the site is still reachable over HTTPS, and it has to keep going out until the browsers you care about have come back, so it is a planned retreat rather than a switch.
Which is why the checklist matters more than the rollback plan. The realistic failure is never "HSTS was wrong for us"; it is "one URL only worked over HTTP and we found out afterwards". Fixing that URL is almost always the faster way back.
Where HSTS sits among your other protections
HSTS does exactly one thing: it removes the plaintext request. Being clear about that is worth it, because "we have HSTS" sometimes gets said as though the security question has now been answered.
It is not a certificate — it assumes a valid one and makes an invalid one fatal. It is not encryption; TLS does that, and HSTS only guarantees TLS is what gets used. It inspects nothing, so it stops no injection, no exploit and no malicious payload: that is a WAF. It counts nothing, so brute force and scraping remain rate limiting work. And it says nothing about who may reach you, which is where country and ASN blocking comes in.
What makes it worth five minutes is the ratio. One header, one setting, no ongoing maintenance — and an entire class of downgrade attack stops being possible against your visitors.
Frequently asked questions
Is HSTS enough on its own?
No, and it is not meant to be. HSTS guarantees the connection is encrypted; it says nothing about what travels over it. A request carrying SQL injection arrives just as safely over HTTPS as over HTTP. It belongs next to a valid certificate, a WAF, rate limiting and sensible access rules — not instead of them.
Does HSTS replace my HTTP to HTTPS redirect?
No. Keep the redirect. HSTS only applies after a browser has seen the header at least once over HTTPS, so every first-time visitor, every new device and every crawler still arrives on port 80 and needs the 301. The two cover different halves of the same problem.
Does it cover my subdomains?
Not with this preset. It sends max-age only, so the rule applies to the exact hostname that served the response. Covering subdomains requires includeSubDomains, which is a much larger commitment: it takes effect in the browser immediately and cannot be withdrawn from there, so every name under your domain has to be on working HTTPS before you consider it.
Should I submit my domain to the HSTS preload list?
Only after HTTPS everywhere has been boring for months. Preloading puts your domain inside the browser, so it protects even a visitor's very first request — but removal means a submission to a third party and a wait for browser releases, so a mistake lasts a long time. A one-year max-age gives you most of the benefit and keeps a path back.
Does HSTS protect somebody's very first ever visit?
By itself, no — that is the one gap it leaves. The first visit is what teaches the browser the rule, and it is protected by your redirect and a valid certificate rather than by HSTS. Preloading is the only way to close that gap, which is why the list exists.
Will it affect performance?
Marginally in your favour. The header is a few dozen bytes, and once a browser has it, every http:// link to your site is rewritten inside the browser instead of costing a round-trip to your redirect. Visitors who previously arrived through a 301 skip it entirely.