HTTPS and Mixed Content for Service Sites

A service site can look finished—certificate installed, contact form on HTTPS, green cues in the address bar—while a leftover http:// image or stylesheet quietly undermines that protection. That gap is called mixed content: a secure page that still requests insecure subresources. Browsers increasingly upgrade or block those requests, which can hide a hero photo, break a form script, or leave visitors on a page that is only partly encrypted.

web.dev’s guidance is blunt: protect every website with HTTPS, even when the site does not process payments. MDN explains why partial HTTPS fails: any resource fetched over HTTP can be viewed or modified on the path between the visitor and the server. For a firm that asks for names, emails, and project briefs, that is not a theoretical edge case. It is the integrity of the page that collects the inquiry.

---

Why “we have a certificate” is incomplete

web.dev’s Why HTTPS matters article (Kayce Basques) lists three practical reasons that apply as much to a local consultancy site as to a bank:

1. Integrity — HTTPS makes it harder for attackers—or intrusive middleboxes—to alter HTML, scripts, images, or cookies in transit. Injected ads and rewritten scripts are the concrete failure modes.
2. Privacy — Unprotected requests can reveal what pages and resources a visitor loads. Aggregate browsing patterns can expose sensitive interests even when no password is typed.
3. Platform access — Many browser features that service sites eventually want (geolocation prompts, service workers, media capture) expect a secure context.

The misconception web.dev calls out is still common in redesign briefs: “We only need HTTPS once we take cards.” Every unprotected request can leak behavior. Contact forms, booking embeds, and CMS admin sessions make the stake obvious—but marketing pages deserve the same baseline.

MDN’s Transport Layer Security overview frames HTTPS as the defense against a manipulator-in-the-middle: someone who sits on the path and can read or change traffic. That framing is useful when explaining the work to a non-technical owner. The certificate is not decoration; it is the channel that keeps the page you published the page they see.

---

What mixed content actually is

MDN defines mixed content as a securely loaded page that then fetches resources over HTTP (or another insecure protocol). Scripts are especially dangerous because they can rewrite any part of the page. Images and other passive assets still carry risk: an attacker can swap a product photo, change a button’s apparent label, or use the request itself for tracking.

web.dev’s What is mixed content? article uses the older active/passive vocabulary:

• Passive (historically “optionally blockable”) — images, video, audio. Lower interaction with the rest of the page, still spoofable and trackable.
• Active (blockable) — scripts, stylesheets, iframes, and other executable or structural resources. Interception can mean full page control, stolen sessions, or redirects.

Modern browser behavior, summarized by MDN’s mixed-content page, is stricter than the old “warn but load” model:

Resource type	Typical browser behavior on an HTTPS page
Images, audio, video (upgradable)	Auto-upgrade http → https when possible; fail if HTTPS is unavailable
Scripts, stylesheets, fonts, XHR/fetch, many iframes (blockable)	Block the insecure request
Mixed downloads (save link from HTTPS to HTTP)	Expected to be blocked by default

That table is why a “secure” service page can still look broken after a host migrates to HTTPS: a blocked script kills the form; a failed image upgrade blanks the case-study strip; a font request over HTTP never arrives.

What goes wrong on real service sites

1. Hard-coded CMS media URLs — The page is HTTPS, but the WYSIWYG still embeds http://oldcdn…/hero.jpg.
2. Third-party widgets — Chat, maps, or booking scripts loaded from HTTP endpoints that never offered TLS.
3. Theme leftovers — Stylesheets or webfonts referenced with absolute http:// paths after a domain move.
4. False confidence — The document padlock is present while DevTools quietly lists upgraded or blocked requests.

---

How to find and fix mixed content

web.dev’s Fixing mixed content guide starts with the browser: open the HTTPS page, watch the console (and Chromium’s Issues panel) for upgrades and blocks, and list every offending URL with the page that requested it. Searching the codebase or CMS for http:// in asset attributes (src, href on stylesheets, CSS url()) catches what a single stroll may miss. Ordinary navigation links to other HTTP pages are usually not mixed content—they open a new context—though gallery scripts that load an href into an on-page lightbox can turn an anchor into a mixed-content request.

The durable fix, shared by MDN and web.dev, is straightforward:

1. Serve all first-party content over HTTPS.
2. Rewrite asset references to https:// or to scheme-relative / root-relative URLs.
3. Prefer HTTPS versions of third-party resources; host a copy yourself when licensing allows; otherwise remove the asset.
4. Revisit the original page and confirm the warnings are gone.

Bridge tactics while you clean up

For sites with many legacy URLs, both MDN and web.dev document the Content-Security-Policy directive upgrade-insecure-requests. It tells the browser to rewrite insecure subresource (and some same-origin navigation) URLs to HTTPS before the request leaves the machine. If the HTTPS version does not exist, the request fails—preserving security rather than falling back to HTTP.

That directive is a migration aid, not a substitute for fixing source. MDN is explicit that it does not replace Strict-Transport-Security (HSTS), which protects visitors who arrive via third-party HTTP links from SSL-stripping attacks. Pair cleanup with HSTS only after you are confident the whole site answers correctly on HTTPS.

For larger properties, web.dev recommends CSP reporting (Content-Security-Policy-Report-Only with a report endpoint) so real visits surface remaining insecure loads without requiring a manual crawl of every URL.

---

Limitation: auto-upgrade is not a free pass

Browsers that auto-upgrade images buy you time; they do not absolve hard-coded HTTP. If the asset is not available on HTTPS, the upgrade fails and the image vanishes. Older browsers may still load passive mixed content that modern ones upgrade or block—web.dev notes that fixing the source protects those visitors too. And CSP upgrades fail closed: a missing HTTPS counterpart breaks the resource rather than silently loading HTTP.

The tradeoff is intentional. Partial encryption that still ships scripts over HTTP is worse than a visible failure that forces a fix.

---

Practical takeaways for your next website

1. Treat HTTPS as site-wide, not form-only — Certificate on the apex and every subdomain that serves pages or assets.
2. Audit with DevTools after go-live and after CMS imports — Upgrades and blocks are the checklist; silence is the goal.
3. Rewrite asset URLs at the source — Relative paths and https:// beat hoping the browser will patch your markup.
4. Use upgrade-insecure-requests as scaffolding — Helpful during migration; remove the need for it by cleaning references.
5. Add HSTS only when HTTPS is solid — It locks visitors onto TLS; do not enable it while mixed content or certificate errors remain.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].