BuildNot yet confirmed elsewhere1 publisher2 min readPublished
A Green Link Report Says Nothing About Whether Your HTTPS Page Renders
Mixed content is the failure most likely to break a secure page, and it answers 200, so status-code checkers pass it. A Merlonix post argues the fix is protocol inspection, not more fetching.
The Engineer · Build desk
What happened
- A broken-link checker grades <a href> targets by HTTP response: 4xx, 5xx, timeouts, connections that never open.
- Mixed content, an http:// subresource on an https:// page, returns a healthy 200 when fetched, so a status-based scan waves it through.
- The Merlonix post lists four routes in: third-party embeds, absolute CDN URLs, migrations that leave http:// baked into content, and a relaxed CSP.
- Merlonix says its free checker adds a second pass that reads subresource protocols and lists the exact insecure URLs.
Why it matters
- constraint A clean link report cannot serve as a release gate for a secure page: it bounds where link targets point, and says nothing about whether the page renders or executes.
- exposure The defect can land on a page nobody on your side deployed to, because a vendor edited its own snippet, which puts ownership of the break outside your repository.
- decision Anyone whose subresources are mounted at runtime has to pick a second detection surface or write the blind spot down as accepted, because the served-HTML pass will keep coming back empty.
- capability Report-only CSP converts this from something a human squints at in a console into an inventory that arrives on its own, before enforcement can break anything.
The asymmetry inside mixed content is what makes it expensive to diagnose. A passive resource leaves an artifact: a missing image is something a human notices and reports [6]. Active resources leave nothing in the page. A stylesheet refused on the security boundary renders the page unstyled, and a blocked script means the JavaScript that depended on it silently does not run, with no 404 anywhere to grep for [5]. The ticket arrives as "the form does nothing", and the first thing anyone reads is code that is working correctly.
Nothing in a link checker's design reaches this. It walks `href`, fetches the target, reads the status [4]. The insecure subresource lives in `src` or a stylesheet `link`, it genuinely exists, and it returns 200 [1]. So a status-code tool is not failing at its job here; it is answering a different question and getting graded on this one.
Passive resources also make reproduction unreliable. Browsers attempt the `https://` variant first and only block when that variant is absent [6], which means the same hardcoded `http://` markup renders fine behind an asset host that serves both schemes and breaks behind one that does not [11]. Per the Merlonix post, the padlock stops being clean either way, with the address bar dropping to "Not fully secure" [7].
The post's own tool is candid about its ceiling, and the ceiling matters. It reads the HTML the server sends, so subresources injected later by client-side JavaScript remain visible only in the browser console, where the `Mixed Content:` warnings are logged [2][9]. For a page that mounts its widgets at runtime, the scan's mixed-content coverage of those widgets is zero [12]. That is not an argument against running it. It is an argument for knowing which half of the rendered page it saw, which is the same discipline the post is asking of link checkers.
This is a single source, published by the outfit whose free checker it recommends [2]. The mechanism it describes, though, does not require trust: open a secure page with a hardcoded plaintext script and the console will say so [9].
What to watch
- Whether Merlonix adds rendered-page inspection, which is the only way its scan reaches subresources injected after the server response.
- Whether CSP report-only endpoints get wired into the same report, turning a one-off scan into a running inventory of insecure subresources.
- Any change to browser auto-upgrade behaviour for images, video and audio, which would move those failures between silent repair and visible breakage.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption
- Insufficient
- Hype gap+25
- Incentives85
- Confidence52
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Mixed content is an http:// subresource loaded by an https:// page; the subresource usually returns a healthy 200 when requested directly, so a checker grading links on HTTP status passes it.
ReportedSupportedSource: Merlonix post republished on dev.to2 sources— create a free account to open themView cited source - [2]
The free broken-links checker described in the post does both halves in one scan: it reports link targets that error or time out, and separately reads the page's <img>, <script>, stylesheet and <iframe> subresources and flags every one loaded over http:// on an https:// page with the exact insecure URLs; it reads the HTML the server sends, so resources injected later by client-side JavaScript still need the browser console.
ReportedSupportedSource: Merlonix post republished on dev.to2 sources— create a free account to open themView cited source - [3]
Every one of the listed mixed-content sources ships green through a broken-link check, because every one of those URLs answers 200.
ReportedSupportedSource: Merlonix post republished on dev.to2 sources— create a free account to open themView cited source - [4]
A broken-link checker walks the <a href> links on a page, fetches each target, and flags the ones that return a 4xx, a 5xx, a timeout, or a connection that never opens.
- [5]
Active mixed content (a <script>, a stylesheet <link>, or an <iframe> over http://) is blocked outright by the browser on a secure page: the dependent JavaScript silently does not run, or the page renders unstyled, with no 404 anywhere.
- [6]
Passive mixed content (<img>, <video>, <audio> over http://) is auto-upgraded to https:// by modern browsers, and blocked if the secure version does not exist, leaving a missing image whose http URL returns a good 200.
- [7]
Either way the padlock stops being a clean padlock: the address bar drops to "Not fully secure".
- [8]
The post lists four routes by which mixed content arrives: a third-party embed hardcoding an http:// script URL, a CDN or asset host referenced by absolute http:// URL, a protocol migration that leaves absolute http:// URLs baked into content, a theme or a database field, and a Content-Security-Policy relaxed away from upgrade-insecure-requests to ship one widget.
- [9]
The browser console logs "Mixed Content:" warnings for every upgraded or blocked resource and the padlock panel reports that the page is not fully secure; the console also catches resources injected by client-side JavaScript, which a static scan of the served HTML cannot see.
- [10]
Content-Security-Policy-Report-Only with block-all-mixed-content, or the reporting directives, will report every insecure subresource without breaking anything, so they can be found before enforcement.
- [11]
Because passive auto-upgrade succeeds only where an https variant of the resource exists, identical hardcoded http:// markup renders correctly behind an asset host that serves both schemes and breaks behind one that does not, making reproduction a property of the host rather than the page.
- [12]
A scanner that parses only the HTML the server sends reports zero mixed content for subresources mounted at runtime by client-side JavaScript.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toA Broken-Link Check Counts 404s. The Resource That Breaks Your Padlock Returns 200.
1 article · August 24, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.