HSTS explained for small businesses.

What does it do?

When a visitor types yourdomain.com.auinto the address bar, the browser's first guess is plain HTTP. Most sites redirect that first hit to HTTPS, but the very first request still leaves the browser as cleartext. An attacker sitting between the visitor and the rest of the internet (a hostile wifi network, a compromised router) can hijack that request and serve their own version of your site. HSTS removes the window. The first time a browser visits over HTTPS, your server returns a Strict-Transport-Security header. From that point on, the browser will not try HTTP again for your domain, even if the user types http:// explicitly.

The header has three optional pieces: max-age (required, the lifetime in seconds), includeSubDomains (extends the policy to every subdomain), and preload (signals that you consent to being added to the browser-shipped preload list). The presence of preload alone does not preload your domain; you have to submit it separately at hstspreload.org.

The protection lasts for the number of seconds you specify inmax-age. A typical production policy of one or two years means the protection survives across browser restarts, OS updates, and roughly every realistic gap in regular use.

Why it matters

Picture a Sydney creative agency that does paid Google search ads. The ads point to https://agency.com.au, but the site does not return an HSTS header. A targeted attacker sets up a captive-portal lookalike on a hotel wifi network the agency's founder uses. The first request from the founder's laptop is an HTTP one, intercepted before the redirect to HTTPS can fire. The attacker serves a clone of the agency's login page, captures the founder's CMS credentials, and changes the home page to a phishing landing pointing at clients. The clean-up costs the agency two days of lost ad spend and a fortnight of awkward client calls. A correctly configured HSTS header, ideally with preload, would have made the captive-portal trick a connection-refused error in the browser.

HSTS is also one of the checkbox items on most cyber insurance forms and supplier security questionnaires. The questions are usually phrased as "does every web property enforce HTTPS for all visitors?". Answering yes when you do not have an HSTS header is technically false. Setting the header takes about two minutes; getting caught answering wrong on the questionnaire costs you the renewal discount.

How to set it up

HSTS is one header. Configure it on your web server, your CDN, or your hosting platform.

• A conservative starting policy for the apex only:

Strict-Transport-Security: max-age=2592000

• The production target once you are confident:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• For Nginx, add the header inside the HTTPS server block.
• For Cloudflare, switch on Strict Transport Security in the dashboard and choose a max-age.
• For Vercel or Netlify, set the header in your config file.

Test from a fresh incognito window. Hit your site once over HTTPS, close the window, then try http://yourdomain.com.au. The browser should redirect internally without ever sending a request to port 80. The DevTools network tab will show the redirect type as 307 (HSTS).

Common mistakes

• Turning on includeSubDomains before every subdomain is HTTPS-ready. Anything still on HTTP becomes unreachable.
• Setting a tiny max-age like 60 seconds. The protection lapses before the next visit.
• Preloading a domain you do not control across every subdomain. Removal from the preload list takes weeks.
• Forgetting to keep the HTTP-to-HTTPS redirect in place. The first visit always needs it.

How AttackEdge checks it

The AttackEdge scan reads the HSTS header on every detected host, flags missing or short policies, missing includeSubDomains on production hosts, and lets you know whether your domain is preload-eligible. Full methodology on /what-we-check, alongside the rest of the security-header set including CSP.