Fixing Strict Transport Security without guessing

When Strict Transport Security fails, the fix is usually mundane: emit a correct Strict-Transport-Security header on the HTTPS responses that matter. SlaySlop's check "Checks whether browsers are instructed to keep future requests on HTTPS." Guessing looks like flipping CDN checkboxes until one URL looks better in a single browser.

I also care that the writeup stays scannable. Name the host. Name the change. Name the rescan. Crawlers and humans both benefit from concrete nouns.

Outcome of a non-guessing fix

Launch hosts send an HSTS instruction that matches your intent (max-age, optional includeSubDomains/preload tokens). Certificates on those hosts still look valid. A rescan shows the Strict Transport Security row updated. SEO or security copy on the site no longer claims a header you do not ship.

Boundaries

Scanning is read-only. You apply the fix in origin or CDN configuration with normal change control. Permission required to test. Not a pentest. Not a preload submission walkthrough unless that is explicitly your project.

Do not "fix HSTS" by renewing a certificate alone. SSL certificate "Reviews certificate validity and public trust signals." is a sibling. TLS configuration "Inspects the public transport configuration and supported connection behavior." is a sibling. CSP and frame protection remain separate.

Happy path fix loop

1. List failing hosts from the report (www, apex, checkout, app).
2. Confirm SSL certificate is healthy enough that sticky HTTPS is not cruelty.
3. Decide directives intentionally: max-age, includeSubDomains only with inventory, preload only with a real plan.
4. Apply the header at the layer that actually generates the response (origin app, reverse proxy, or CDN rule).
5. Verify with curl on each host path you care about.
6. Rescan in SlaySlop.
7. Update any public security copy so it matches reality.

# After deploy, permissioned hosts only
curl -sI "https://www.example.com/" | rg -i 'strict-transport-security'
curl -sI "https://example.com/" | rg -i 'strict-transport-security'

fix_hsts_ticket:
  hosts: []
  intended:
    max-age:
    includeSubDomains: yes|no
    preload: yes|no
  change_location: origin|cdn|proxy
  rescan: pass|fail

Pitfalls

Setting the header only on / while APIs differ. Enabling includeSubDomains to silence a checklist. Shipping HSTS on HTTP responses and expecting browsers to learn from them the way they learn from HTTPS. Declaring victory without a rescan. Keyword-stuffing a blog post about HSTS while checkout still lacks the header.

Related next step

After HSTS passes, reread SSL certificate and consider CSP on the same hardening pass. Soft links: Strict Transport Security, security product. Soft close: keep verification in a permissioned SlaySlop scan so the public header story stays next to SEO and uptime.

What I refuse to invent

I do not invent prices, customer counts, or scan durations. I do not invent check names that are not on slayslop.com. I do not turn a read-only public finding into exploit steps. When the glossary sentence is narrow, the article stays narrow: observe the public signal, fix the config that produces it, rescan with permission, and keep sibling checks labeled as siblings.