Skip to content

Fix HSTS Max-Age Value Configuration

DodaTech Updated 2026-06-26 2 min read

In this tutorial, you'll learn about Fix HSTS Max. We cover key concepts, practical examples, and best practices.

The HSTS max-age value determines how long the browser remembers to enforce HTTPS on your domain. A value that is too short offers little protection because users remain vulnerable each time the HSTS policy expires. A value that is too large makes it impossible to quickly revert mistakes. Getting the max-age right is critical for security and operational flexibility.

Wrong

The max-age is set to a very low value or an unsupported value.

Strict-Transport-Security: max-age=60
add_header Strict-Transport-Security "max-age=60" always;

The browser only enforces HTTPS for 60 seconds. After that, the user is vulnerable to SSL stripping on the next visit. Someone watching the user's traffic within that window can still execute a downgrade attack.

Another common mistake is setting an excessively large value:

Strict-Transport-Security: max-age=99999999999999999

Some servers reject or truncate unrealistically large max-age values, and browsers may silently clamp them.

Use max-age=31536000 (1 year), which is the minimum required for HSTS preload eligibility.

Strict-Transport-Security: max-age=31536000
add_header Strict-Transport-Security "max-age=31536000" always;
Header always set Strict-Transport-Security "max-age=31536000"

Express with helmet:

app.use(helmet.hsts({
  maxAge: 31536000,
}));

The browser enforces HTTPS for one year. During this time, all requests to the domain are upgraded to HTTPS automatically by the browser, even if the user types http:// in the address bar.

Prevention

  • Use max-age=31536000 (1 year) for production deployments to ensure preload eligibility.
  • During testing, use a short max-age like max-age=300 (5 minutes) so you can quickly see changes.
  • Increase max-age gradually: start with a few hours, then days, then weeks, then the full year.
  • Never set max-age to 0 while in production, as this tells browsers to disable HSTS, making users immediately vulnerable to downgrade attacks.
  • The maximum practical max-age is 63072000 (2 years). Values above this are unnecessary and may cause issues in some implementations.
  • Document the max-age value and the date you set it so you know when browsers will stop enforcing it.

DodaTech Tools

Doda Browser shows the HSTS max-age value for any domain in its security info panel. DodaZIP's header audit tool checks that max-age meets the minimum threshold for preload eligibility. Durga Antivirus Pro uses max-age=31536000 for all its cloud service domains and audits the value monthly.

FAQ

### What is the recommended HSTS max-age value for production?

The recommended max-age for production is 31536000 seconds (1 year). This is the minimum value required by the HSTS preload submission process. Some security guides recommend 63072000 (2 years) for maximum protection, but 1 year is the industry standard for most deployments.

Can I change the max-age after deploying HSTS?

Yes, but browsers will not see the new value until the previous max-age expires. If you deployed with max-age=31536000, the browser caches that value for one year. To revert faster, you can set max-age=0 to signal browsers to disable HSTS, but this should only be done in controlled situations.

What happens if I set max-age to 0?

Setting max-age=0 tells browsers to remove the domain from their HSTS list. This is useful when you need to disable HSTS for maintenance or if you are migrating away from HTTPS. However, if the browser has cached a longer max-age from a previous response, setting max-age=0 on a subsequent response will remove it.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro