The Hidden Risk Behind Broken Links

When security teams think about vulnerabilities, broken links rarely make the list. They are typically dismissed as an SEO nuisance, something for the marketing team to clean up. But broken links represent a genuine, exploitable attack surface that threat actors actively scan for and weaponize. A dead link is not just a poor user experience. It is a dangling pointer that an attacker can redirect toward their own infrastructure. If your website references a resource that no longer exists, whoever claims that resource next controls what your users see, execute, or trust. This is not theoretical. It has been exploited at scale, against major organizations, and the barrier to entry is remarkably low.

Subdomain Takeover via Dangling CNAMEs

The most dangerous class of broken link vulnerability is subdomain takeover through dangling CNAME records. Here is how it works: your organization provisions a subdomain like blog.example.com and points it via CNAME to a third-party service, say a cloud hosting provider, a SaaS platform, or a CDN. Later, the account on that third-party service is decommissioned, but the DNS CNAME record is never removed. The subdomain now resolves to a service endpoint that no longer has an owner. An attacker can then create an account on that same third-party provider, claim the endpoint, and serve arbitrary content under your subdomain. Because the subdomain is under your root domain, browsers will trust it. Cookies scoped to the parent domain are sent to the attacker. SSL certificates can be issued for it via automated CA validation. In 2020, researchers found over 400 vulnerable subdomains across Microsoft-owned domains alone. Companies like Starbucks, Uber, and Slack have all had subdomain takeover reports submitted through bug bounty programs. The pattern is always the same: a DNS record pointing to a service that was deprovisioned without cleaning up the DNS entry.

Expired Domains in Outbound Links

Your website likely links to dozens or hundreds of external resources: partner sites, documentation, tools, references, vendor pages. When any of those domains expire, they become available for re-registration. Attackers actively monitor domain expiration feeds and snap up domains that have significant inbound link profiles. Once they control the domain, they can serve phishing pages designed to look like the original resource. Your users click a link on your trusted website and land on an attacker-controlled page. Because the link originated from your site, the user has no reason to suspect anything is wrong. This is particularly devastating for financial services, healthcare, and government websites where trust is paramount. We have seen expired partner domains re-registered and turned into credential harvesting pages within days of the domain dropping. The attack is cheap, roughly ten dollars for a domain registration, and the payoff from a well-targeted phishing campaign can be enormous.

Broken CDN References and Script Injection

When your HTML references JavaScript files, CSS stylesheets, or fonts from a CDN or external host, and that reference breaks, you have a script injection vulnerability waiting to happen. If the CDN account expires, the hosting bucket is deleted, or the specific path is no longer claimed, an attacker can register the same bucket name or account and serve malicious scripts in place of your original resources. This is a supply chain attack delivered through link rot. The browser will execute the attacker's JavaScript with full access to your page's DOM, cookies, and any sensitive data the user has entered. A single broken script reference to an unclaimed S3 bucket or GitHub Pages endpoint can compromise every visitor to your site. Subresource Integrity (SRI) hashes mitigate this for scripts and stylesheets, but they are not universally adopted, and they do not cover all resource types. If you reference an external image, iframe, or font without SRI, you are exposed.

404 Pages That Leak Information

Broken links generate 404 responses, and those 404 pages themselves can be a security concern. Default error pages from web frameworks often expose server version information, technology stack details, and sometimes internal paths or debug information. Every broken link on your site is an invitation for a crawler to hit your 404 handler. If that handler leaks information, you are giving attackers free reconnaissance data at scale. Beyond information leakage, 404 pages that do not properly sanitize the requested URL path can be vulnerable to reflected cross-site scripting. If the requested path is echoed back in the error page without encoding, an attacker can craft a malicious URL that executes JavaScript when a user follows it. This turns every broken link into a potential XSS vector if your error handling is not airtight. Custom error pages with minimal information disclosure and proper output encoding are essential.

Trust Erosion and Phishing Enablement

Broken links systematically erode the trust signals that help users distinguish legitimate sites from malicious ones. When users encounter dead links on your website, they become conditioned to unexpected behavior. They learn that clicking links on your site sometimes leads to error pages or unfamiliar destinations. This conditioning is exactly what phishing attackers exploit. A user who is accustomed to broken experiences on your site is less likely to notice when a link takes them somewhere truly dangerous. Furthermore, broken links in email communications are particularly hazardous. If your automated emails, newsletters, or notification messages contain broken links, users learn to distrust your communications. When an attacker sends a phishing email that impersonates your brand, the recipient has already been trained to expect inconsistency.

How to Scan and Monitor for Broken Links

Effective broken link monitoring requires more than a one-time crawl. Links break continuously as external sites change, domains expire, and services are decommissioned. You need automated, recurring scans that check every link on your site and alert you when something dies. Start by crawling all internal and external links across your entire web presence. For each broken link, assess the security risk: is it a CNAME pointing to a claimable service? Is it a script or stylesheet reference? Is it a link to a domain that has expired and is available for registration? Prioritize fixes based on risk, not just SEO impact. At BlackSight, our broken link scanner checks every outbound and internal reference, identifies dangling DNS records, and flags expired or available domains in your link profile. We run these checks on a schedule so you catch newly broken links before attackers do. Combine broken link scanning with DNS monitoring to detect dangling CNAME records, and use certificate transparency logs to spot unauthorized certificate issuance for your subdomains.

Building a Defensive Process

Preventing broken link exploitation requires process discipline. When decommissioning any service, always remove the associated DNS records first. Maintain an inventory of all subdomains and the services they point to, and audit it quarterly. For outbound links, implement monitoring that alerts when linked domains change ownership or expire. Use Subresource Integrity for all externally hosted scripts and stylesheets. Configure your 404 pages to return minimal information without echoing user input. Treat your link inventory as a security asset, not a marketing concern. Every broken link is a potential foothold, and your security posture is only as strong as your weakest dangling reference.