The Mixed-Content & HSTS Teardown: Spot the Broken Padlock Before It Ships
Objective: Given two real-world-realistic specimens, an HTML snippet and an HSTS header configuration, find the defect in each that would break the padlock or lock out a legitimate subdomain.
Adyen's marketing site team is finalizing a merchant-facing landing page redesign and a new site-wide HSTS policy. You're the pre-launch technical SEO reviewer checking both for exactly the mistakes this lesson warns about.
Two specimens: an HTML snippet with an embedded asset, and an HSTS header rollout plan against a list of live subdomains. Find the defect in each.
Which line in each specimen would break the padlock or lock out a legitimate subdomain, and why does it matter more than the distractors around it?
Before you start
What you'll need
- —Basic understanding of how HTTPS and the browser padlock indicator work
- —Familiarity with reading HTML head tags and HTTP response headers
- Mixed content
- an HTTPS page that loads at least one resource, image, script, or stylesheet, over plain HTTP, which breaks or hides the browser's padlock.
- HSTS (Strict-Transport-Security)
- a header that tells browsers to only ever connect to a domain over HTTPS, refusing HTTP entirely once set.
- HSTS preload
- a browser-maintained list that hard-codes HSTS enforcement before the first visit, with slow removal if a mistake ships.
Free path (everything below is enough to finish)
Free tier crawls up to 500 URLs, plenty to catch this class of pre-launch defect across a marketing site and its subdomains.
The process
Specimens to review
Review this HTML snippet from the new merchant landing page, scheduled to launch on the HTTPS domain tonight. Find the line that would break the padlock.
=== Landing page <head>, partial === <link rel="stylesheet" href="https://cdn.adyen-example.com/styles/main.css" /> <script src="https://cdn.adyen-example.com/analytics.js"></script> <script src="http://legacy-chat-widget.example.net/embed.js"></script> <link rel="canonical" href="https://www.adyen-example.com/merchants/landing" />
Specimen: synthetic, realistic
Review this HSTS rollout plan against the list of live subdomains. Find the risk before it's submitted to the preload list.
=== Planned header, all *.adyen-example.com responses === Strict-Transport-Security: max-age=31536000; includeSubDomains; preload === Live subdomain inventory === www.adyen-example.com HTTPS fully supported docs.adyen-example.com HTTPS fully supported dashboard.adyen-example.com HTTPS fully supported legacy-support.adyen-example.com HTTP only, HTTPS never configured
Specimen: synthetic, realistic
Analyze your findings
What to look for
- Protocol consistency
- Does every embedded resource on the HTTPS page also load over HTTPS, with no exceptions?
- Subdomain coverage
- If a policy applies domain-wide, does every live subdomain actually support what the policy assumes?
- Failure mode
- Does the defect degrade gracefully (a warning) or fail hard (the resource or subdomain becomes inaccessible)?
- Distractor plausibility
- Is the flagged line actually the defect, or does it just look unusual next to correctly-configured neighbors?
Make the call
The HSTS specimen lists includeSubDomains and preload alongside a subdomain that has never had HTTPS configured. What should happen before submission?
Recommendation · Priority: High
“Both specimens should be blocked from launch. The merchant landing page's legacy chat widget script must be updated to load over HTTPS before deploy, since a single HTTP resource breaks the padlock on the entire page at the exact moment merchants are evaluating trust. The HSTS preload submission should be held until legacy-support.adyen-example.com either supports HTTPS or is explicitly excluded from includeSubDomains, since preload removal is slow and the failure mode is a hard, unrecoverable connection error, not a warning.”
Common mistakes
What trips people up
Assuming a same-domain resource is automatically safe — the protocol (http:// vs https://) matters independently of which domain a resource loads from.
Treating correct header syntax as proof the header is safe to ship — a syntactically valid HSTS header can still be operationally dangerous if the subdomain inventory isn't ready for it.
Missing the domain-wide blast radius of includeSubDomains — a policy written for the main domain silently applies to every subdomain, including ones the reviewer didn't check.
Confusing a soft warning with a hard failure — mixed content shows a broken padlock (soft); an HSTS-enforced HTTP-only subdomain refuses to load at all (hard), and the review priority should reflect that difference.
Final deliverable
A pre-launch security review flagging both defects with severity, blocking the HSTS submission and the landing-page deploy until both are fixed.
See a reference example
The same pre-launch review on Flipkart's seller-onboarding microsite (illustrative) caught an identical mixed-content defect: a legacy PDF-viewer script still loading over HTTP after a subdomain consolidation. Same fix, swap the script source to HTTPS before launch.
Success criteria
You're done when you can:
- Identified the http:// chat widget script as the mixed-content defect, not the same-domain distractors
- Explained specifically why one insecure script breaks the padlock even though every other asset is HTTPS
- Identified the unconfirmed legacy-support subdomain as the HSTS preload risk, not the correctly-formatted header syntax
- Explained the hard-failure consequence (subdomain becomes completely inaccessible, not just 'less secure')
Key takeaway
A pre-launch HTTPS review has to check both the page's own resources and the domain-wide policies that will apply after launch. The mixed-content bug and the HSTS blast radius look unrelated but share the same root cause: a change that's correct in isolation but wasn't checked against every dependency it actually touches.