Surfaced during the Cloudflare apex cutover (~10–14 days from now). Tagged post-launch.
Context
During the apex cutover for dadeda.design (cutover landed 2026-05-11), the SSL/TLS hardening step (Batch 3 of the migration) explicitly deferred enabling HTTP Strict Transport Security (HSTS).
Why deferred: HSTS tells browsers "for the next N seconds, refuse to even attempt http:// for this domain." It's a strong security commitment, but the policy is cached client-side for the full max-age (typically 1 year once stable). If anything goes wrong with the TLS cert or the apex setup within the cache window, users with cached HSTS get a hard error with no http fallback path.
For a brand-new apex cutover, this is too risky on day one. Best practice: let the cutover bake for a week or two, confirm cert renewal and edge stability, THEN enable HSTS with a short max-age first, ramp up.
Proposed plan
- Wait ~10–14 days from the cutover date (2026-05-11) to confirm no cert/edge issues have surfaced.
- Enable HSTS with a short
max-age first:
- Cloudflare zone → SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Enable
max-age: 86400 (1 day) — short enough that any rollback recovers within a dayinclude subdomains: leave OFF initially (only enable after confirming www and any future subdomains also serve over TLS exclusively)preload: OFF initially (preload submission to browser vendors is irreversible without browser-vendor cooperation; treat as a separate decision)
- Run for a week, monitor for any cert issues, browser console warnings, or visitor reports.
- Bump
max-age to 31536000 (1 year) once confident.
- Optionally consider
include subdomains and preload only if there's no future subdomain that might intentionally serve plain HTTP (highly unlikely for this site).
Decision to document at that time
Whether to opt into the HSTS Preload List (hstspreload.org). Preload is essentially irrevocable on a year+ timescale because browsers bake the list into their binaries. Decision point: would I ever want a subdomain of dadeda.design to serve plain HTTP, even temporarily? If no, preload is safe.
Acceptance
- HSTS enabled with
max-age=31536000
- A note added to
docs/adr/003-cloudflare-free-tier.md Consequences (or a new ADR if preload is involved) capturing the HSTS posture
- No visitor-reported TLS failures during ramp
Labels: post-launch, infra
Surfaced during the Cloudflare apex cutover (~10–14 days from now). Tagged
post-launch.Context
During the apex cutover for
dadeda.design(cutover landed 2026-05-11), the SSL/TLS hardening step (Batch 3 of the migration) explicitly deferred enabling HTTP Strict Transport Security (HSTS).Why deferred: HSTS tells browsers "for the next N seconds, refuse to even attempt
http://for this domain." It's a strong security commitment, but the policy is cached client-side for the fullmax-age(typically 1 year once stable). If anything goes wrong with the TLS cert or the apex setup within the cache window, users with cached HSTS get a hard error with no http fallback path.For a brand-new apex cutover, this is too risky on day one. Best practice: let the cutover bake for a week or two, confirm cert renewal and edge stability, THEN enable HSTS with a short
max-agefirst, ramp up.Proposed plan
max-agefirst:max-age: 86400 (1 day) — short enough that any rollback recovers within a dayinclude subdomains: leave OFF initially (only enable after confirmingwwwand any future subdomains also serve over TLS exclusively)preload: OFF initially (preload submission to browser vendors is irreversible without browser-vendor cooperation; treat as a separate decision)max-ageto 31536000 (1 year) once confident.include subdomainsandpreloadonly if there's no future subdomain that might intentionally serve plain HTTP (highly unlikely for this site).Decision to document at that time
Whether to opt into the HSTS Preload List (hstspreload.org). Preload is essentially irrevocable on a year+ timescale because browsers bake the list into their binaries. Decision point: would I ever want a subdomain of
dadeda.designto serve plain HTTP, even temporarily? If no, preload is safe.Acceptance
max-age=31536000docs/adr/003-cloudflare-free-tier.mdConsequences (or a new ADR if preload is involved) capturing the HSTS postureLabels:
post-launch,infra