Website Security FAQ covers compatibility, limits, and practical uses of HTTPS, HSTS, and security headers. Compatibility depends on TLS support, root trust, and browser enforcement, limits come from old clients and strict settings, and practical uses focus on forcing HTTPS and fixing mixed content.
For WordPress, Drupal, marketing, and front-end teams, these settings affect launch checklists, ad landing pages, and redesigns. TLS is transport encryption between browser and server. HSTS is a response header that tells browsers to use only HTTPS.
Table of Contents
- Do small sites still need HTTPS everywhere?
- How does HSTS preload protect first visits?
- What can break when you harden headers?
- Will free certificates work for every visitor?
- How do you keep old content working after moving to HTTPS?
Do small sites still need HTTPS everywhere?
Yes. CISA guidance tells operators to disable plain HTTP, enforce HTTPS plus HSTS, and preload HSTS when possible, because it blocks protocol-downgrade and cookie-hijacking attacks, according to CISA website-security guidance. That applies to blogs, portfolios, and campaign microsites, not only stores or logins.
Federal rules go further. NIST requires government-only TLS servers to use TLS 1.2, to also support TLS 1.3, and never use TLS 1.0, SSL 3.0 or SSL 2.0, according to NIST. CISA also required agencies to serve public sites HTTPS-only with HSTS within 120 days, according to CISA. Vendors and contractors operating those sites must meet the same baseline.
How does HSTS preload protect first visits?
Normal HSTS trusts the first visit, so an attacker can intercept before the browser learns the rule. Browser preload lists built into Chrome, Firefox, Safari and Edge force HTTPS before first contact, which fixes that gap, according to hstspreload.org.
Submission has strict checks. Your site must meet all of these, according to the HSTS preload requirements: Preload is hard to undo quickly, so use it only after every subdomain works on HTTPS.
- serve a valid certificate
- redirect HTTP to HTTPS
- send includeSubDomains
- send max-age of at least 31536000
What can break when you harden headers?
Headers restrict what modern browsers will do, but they do not fix server bugs. OWASP documents headers such as HSTS, CSP, X-Content-Type-Options and Referrer-Policy that limit XSS, clickjacking and sniffing flaws in modern browsers, according to OWASP. Overly strict CSP or HSTS can also block legitimate images, scripts, or subdomains.
Ramp up in stages. Mozilla recommends Strict-Transport-Security: max-age=63072000; includeSubDomains; preload plus Content-Security-Policy: upgrade-insecure-requests, with staged max-age ramp-up, according to the Mozilla TLS implementation guide. Start with a short max-age, confirm analytics, ads, embeds, and staging subdomains load, then increase. Remove HTTP-only subdomains or move them to HTTPS before adding includeSubDomains.
Will free certificates work for every visitor?
For most modern visitors, yes. Let's Encrypt certificates validate only where ISRG Root X1 and X2 are trusted, and X1 trust is now nearly ubiquitous, according to Let's Encrypt. That covers current browsers, phones, and content management hosts.
Older clients remain the limit. Systems such as Android 7.0 and earlier or unpatched systems fail validation, according to Let's Encrypt. If your audience includes older devices, kiosks, or embedded systems, test those builds directly or use a certificate chain they already trust.
How do you keep old content working after moving to HTTPS?
Use automatic upgrading for subresources. W3C defines the upgrade-insecure-requests CSP directive to rewrite insecure subresource URLs to HTTPS before mixed-content checks, according to W3C. Legacy HTTP images and scripts keep working after migration when an HTTPS version exists.
It does not rescue everything. If the HTTPS URL returns a 404, certificate error, or different file, the browser still blocks or fails the load. Inventory theme files, widgets, feeds, and ad tags for hard-coded http:// URLs, fix the source where possible, and keep upgrade-insecure-requests as a safety net during cleanup.
