Frontend Beauty
ESC

Type to search the knowledge base.

HTTPS and Mixed Content

TLS everywhere, HSTS, and mixed active/passive content blocks that break modern browsers.

beginner3 min read
  • security
  • https
  • mixed-content
  • hsts
  • tls

HTTPS authenticates the server (via certificates) and encrypts the channel so network attackers can’t silently read or modify page content. Mixed content is when an HTTPS page loads HTTP subresources — browsers block active mixed content and may upgrade or warn on passive.

Docs: MDN Mixed content, web.dev Why HTTPS, HSTS.

Why FE still cares

  • Service workers, geolocation, many APIs require secure contexts.
  • Cookies with Secure only flow over HTTPS.
  • CSP upgrades and preload lists assume HTTPS.
  • SEO and browser UI (padlock) expectations.

Mixed content types

Kind Examples Browser behavior
Active scripts, xhr/fetch, websockets, CSS Blocked on HTTPS pages
Passive images, audio, video Often auto-upgraded or warned/blocked depending on browser 
<!-- breaks / blocked on https://app.example -->
<script src="http://cdn.example/app.js"></script>
<img src="http://cdn.example/a.png" alt="" />

Fixes

  1. Use https:// URLs everywhere.
  2. Scheme-relative //cdn.example/x inherits page scheme — prefer explicit https.
  3. Content-Security-Policy: upgrade-insecure-requests to rewrite http subresources.
  4. Fix CMS content that stores absolute http links.
  5. HSTS so users never stay on http accidentally.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Only enable HSTS preload when all subdomains are HTTPS-ready.

Local development

localhost is a secure context. Other LAN IPs may not be — use localhost tunnels or trusted dev certs for SW testing.

Certificate UX

Users hitting cert errors should not be told to “click through” in product docs. For apps, pinning is rare on the web (public key pinning deprecated); rely on public CA ecosystem + CAA DNS records at the ops layer.

Interview out-loud

“HTTPS provides confidentiality and server authenticity. Mixed active content like http scripts on https pages is blocked. I serve all assets over HTTPS, consider upgrade-insecure-requests, and set HSTS carefully.”

Reviewer prompts

  • What is the asset (session, PII, money movement)?
  • What is the attacker capability (web, XSS, network, dependency)?
  • Which control fails closed if misconfigured?
  • Is the server still enforcing authz?
  • Any new third party, iframe, or URL sink?

Residual risk note

Browser controls reduce likelihood and impact; they do not eliminate bugs. Prefer defense in depth: safe defaults in code, strict headers, and monitoring (CSP reports, auth anomaly alerts). When product pressure weakens a control, write down the accepted risk and a revisit date.

Content inventory

Scan HTML/CSS/JS for http:// subresource URLs in CMS content and email-derived templates. Add a CI grep for src="http:// and url(http:// on first-party code. For legacy JSON content, run a one-off migrator that rewrites asset URLs to https or protocol-relative carefully (prefer https).

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides