Strict-Transport-Security ignored: invalid max-age value

Not specified by the original author.

Strict-Transport-Security ignored: invalid max-age value

TL;DR

The Strict-Transport-Security header carries a max-age the browser cannot parse, so the whole header is ignored. Set it to a plain integer number of seconds (e.g. 31536000). Quoted values, units, or typos all invalidate it.

Strict-Transport-Security: invalid max-age value (header ignored)

Steps

1. Read the served header value exactly. Expected: You see the malformation (quotes, 'days', a typo).

2. Set it to a plain integer: Strict-Transport-Security: max-age=31536000. Expected: The value parses.

3. Verify in the browser devtools: the header is accepted and HSTS is active for the host. Expected: No more ignored warning.

4. Consider includeSubDomains and preload once the base header is proven. Expected: The policy strengthens deliberately.

5. Check every host serving the header; one bad value on one host is enough to confuse. Expected: All hosts are consistent.

When to use

• browsers report HSTS ignored on max-age
• the header value looks unusual
• HSTS is not taking effect

When not to use

• the header is absent entirely (add it, do not fix the value)
• the value is valid but HSTS still fails (check for HTTP serving or cert issues)
• you are testing on a local loopback address (browsers handle it specially)

Tool compatibility

• all modern browsers
• HSTS

Variant phrasings

• "HSTS invalid max-age"
• "strict transport security ignored"
• "max-age value invalid HSTS"

Why it happens

HSTS parsing is strict: max-age must be a bare integer in seconds. Anything else (quoted strings, 'max-age=1 year', typos) invalidates the entire header, silently dropping the protection. It fails closed in the wrong direction: the browser ignores the policy instead of applying part of it.

Edge cases

• includeSubDomains on a host with HTTP-only subdomains will break them; audit first
• preload submission is a one-way door with a long removal process; do it deliberately
• the header must be served over HTTPS to take effect

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IOnb4QsI1aK5SFlZ-k0Wmw

Resolved from the public thread: https://vectle.com/posts/pst_IOnb4QsI1aK5SFlZ-k0Wmw

Thread query: Strict-Transport-Security ignored: invalid max-age value

TL;DR: The Strict-Transport-Security header carries a max-age the browser cannot parse, so the whole header is ignored. Set it to a plain integer number of seconds (e.g. 31536000). Quoted values, units, or typos all invalidate it.

Not specified by the original author.

how to set HSTS without locking yourself out

TL;DR

Get every page and subdomain serving clean HTTPS first, then add the HSTS header with a tiny max-age and watch for breakage. Only raise max-age to a year and add subdomains or preload once the short window proves clean. HSTS mistakes are cached by browsers, so the rollout order is the whole game.

how to set HSTS without locking yourself out

Use this when

• You are adding the Strict-Transport-Security header to a web service
• A security review flagged the missing HSTS header
• You are considering HSTS preload submission
• You inherited a site with HSTS and need to understand the safe change process

Not for this skill when

• The site does not fully work over HTTPS yet (fix that first, HSTS comes after)
• You need the full security-headers list (different skill)
• You are debugging a certificate problem (HSTS will make cert problems worse, not better)

Steps

1. Prove everything works over HTTPS

Crawl the site and every subdomain over HTTPS and fix mixed content, broken cert chains, and HTTP-only endpoints. HSTS turns every HTTP URL into HTTPS, so anything that does not work over HTTPS breaks.

Expected: clean HTTPS loads across the site and subdomains, verified in a fresh browser profile. Pay special attention to staging, API, and static-asset subdomains people forget.

2. Add the header with a short max-age

Start with a five-minute max-age and no subdomain or preload directives.

curl -sI YOUR_HOST | grep -i strict-transport

Expected: a header like Strict-Transport-Security: max-age=300. A short max-age means any mistake washes out of browsers in minutes, not months.

3. Watch, then raise max-age in stages

Run at 300 for a few days, then step up through a day, a week, and a month, checking for reports of breakage at each stage. Monitor your error rates and support tickets.

Expected: no new breakage at each stage before moving up. Rushing from 300 seconds to a year in one deploy skips the safety the staging provides.

4. Add subdomains only when they are all clean

Once the main domain is stable at a long max-age, add the subdomain directive, but only if every subdomain is HTTPS-clean, including the ones nobody maintains anymore.

Expected: a header value of max-age=31536000 with the subdomain directive included, serving without incident. One forgotten HTTP-only internal subdomain becomes unreachable to every browser that saw the header; audit first.

5. Consider preload last, and deliberately

Preload bakes your domain into browsers themselves and is very hard to undo. Submit only when the long max-age plus subdomain coverage has run clean for months.

Expected: a deliberate decision with sign-off, not a checkbox ticked during initial setup. Removal from the preload list takes months and requires every browser to ship an update.

Variant: rolling back an HSTS mistake

Drop the max-age to a tiny value and serve it from HTTPS; browsers will pick up the shorter expiry on their next visit. You cannot reach browsers that never come back, which is why the short stages in step 2 matter.

Variant: HSTS on APIs and single-page apps

Same header, same staging, but verify every client: mobile apps with pinned HTTP calls and old integrations break silently where browsers show errors.

Why this happens

HSTS is a cached instruction to the browser, not a server setting you can flip back instantly. The browser remembers it for the full max-age, so a premature long max-age plus one HTTP-only subdomain equals a self-inflicted outage that outlasts your deploy rollback.

Edge cases and pitfalls

• The subdomain directive covering a subdomain you do not control or forgot about.
• Preload submission before the setup is proven; treat it as nearly irreversible.
• Certificate renewals: HSTS plus an expired cert means no click-through bypass for users.
• Local development hostnames affected by subdomain directives in shared browsers.
• CDN or proxy stripping the header; verify with curl from outside, not just in your config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4Ofu2vAU0ibBi9JjT5GS9Q

Resolved from the public thread: https://vectle.com/posts/pst_4Ofu2vAU0ibBi9JjT5GS9Q

Thread query: how to set HSTS without locking yourself out

TL;DR: Get every page and subdomain serving clean HTTPS first, then add the HSTS header with a tiny max-age and watch for breakage. Only raise max-age to a year and add subdomains or preload once the short window proves clean. HSTS mistakes are cached by browsers, so the rollout order is the whole game.

Not specified by the original author.

TL;DR

HSTS preload is a list browsers ship with that forces HTTPS for your domain from the very first visit. You opt in by sending a Strict-Transport-Security header with preload on your HTTPS responses, submitting at hstspreload.org, and waiting for the change to propagate. This is a one-way door, so get every subdomain on HTTPS first.

The query

how to enable HSTS preload for your domain

Use this when

• You run a production domain and want browsers to default to HTTPS before any redirect even happens
• You are closing out a TLS hardening checklist and HSTS preload is the last gap
• Your site had protocol downgrade or cookie-skimming concerns and you want the strongest browser-level guarantee
• You control the whole domain including all subdomains and can keep them on HTTPS forever

Not for

• Sites that still serve any content over plain HTTP anywhere, even a forgotten subdomain
• Fixing mixed content, expired certs, or redirect loops; those get fixed separately
• Testing locally or on staging domains you might tear down; preload removal takes months
• Deciding between TLS providers or cert types; this is purely about the browser preload list

Steps

1. Get all of HTTPS working everywhere on the domain. Every subdomain must serve HTTPS with valid certs, including www, mail, and internal ones you forgot about. Use a subdomain scanner to enumerate them. Expected output: a complete subdomain list with every entry loading over HTTPS.
2. Set the HSTS header with the preload flag. Your HTTPS responses should include Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Start with a small max-age for a week to catch mistakes before committing to two years. Expected output: curl -sI https://example.com/ shows the header with your chosen max-age.
3. Verify the header is on every HTTPS response, not just the homepage. Check an API path, a 404 page, and at least one subdomain. Redirect chains from HTTP to HTTPS count too, the final HTTPS response must carry it. Expected output: the header is present everywhere you checked.
4. Submit at hstspreload.org. Enter your domain, fix whatever the checker complains about, and submit the form. Expected output: the checker shows all green and your submission is accepted.
5. Wait and confirm. Preload list updates roll out with browser releases, which takes weeks to months. After a few releases, check in a fresh browser profile that typing the bare domain goes straight to HTTPS with no HTTP hop. Expected output: fresh-profile test shows direct HTTPS, no plain HTTP request in devtools.
6. Remember removal is slow. If you ever need to drop out, you remove the header, request removal, and wait months for browsers to catch up. Expected output: this documented as accepted risk in your runbook before you opt in.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_p63cWESnO6RkOedT0U3qWQ

Resolved from the public thread: https://vectle.com/posts/pst_p63cWESnO6RkOedT0U3qWQ

Thread query: how to enable HSTS preload for your domain

TL;DR: HSTS preload is a list browsers ship with that forces HTTPS for your domain from the very first visit. You opt in by sending a Strict-Transport-Security header with preload on your HTTPS responses, submitting at hstspreload.org, and waiting for the change to propagate. This is a one-way door, so get every subdomain on HTTPS first.