When Broken Links Become Security Vulnerabilities

Are Broken Links Actually a Security Risk?

Imagine a link on your website stops working. You notice the problem, add it to your backlog, and move on. A few months later, the link starts working again. At first glance, that sounds like good news. In reality, it could mean that someone else now controls the destination.

Fortunately, this is not what usually happens. In most cases, a broken link is simply a maintenance issue. A page has been moved, deleted, or renamed. Visitors encounter an error, someone eventually fixes the link, and the story ends there.

The security risk begins when the destination is no longer merely unavailable but can be controlled by someone else. An expired domain may be registered by a new owner. An abandoned cloud resource may be claimed by another customer. A company subdomain may continue pointing to infrastructure that no longer belongs to the organization. In each case, users and systems may continue trusting the destination even though ownership has changed.

A well known example is Polyfill.io. In 2024, ownership of the widely used service changed hands while hundreds of thousands of websites continued loading JavaScript from it. Under certain conditions, visitors were redirected to malicious websites, demonstrating how quickly a trusted reference can become a security problem when control changes.

How Broken Links Become Dangerous

A broken link is only a symptom. An HTTP status code tells you whether a resource can be reached. It does not tell you whether someone else can take control of it. That is why a “404 Not Found” response is not necessarily a security issue.

A broken link becomes dangerous when the following sequence unfolds:

Trusted resource → Resource becomes reclaimable → Ownership changes → Security impact

It begins when a website continues to link to a resource after it has been removed or abandoned. This could be an external website, a JavaScript file, a cloud service, or a company subdomain that is no longer in use.

Next, the resource becomes available for someone else to claim. An expired domain can be registered again. A deleted cloud resource can be recreated. An unused service identifier may become available to another customer. None of these events is an attack on its own. They simply create the opportunity for one.

The security impact appears only if another party takes control while the original website continues to trust the destination. Depending on the type of reference, the new owner may inherit visitors, execute code in users’ browsers, receive sensitive data, or serve content from a trusted company subdomain. That inherited trust can then be abused for phishing, malware distribution, user tracking, search engine manipulation, or many other forms of attack.

Where Broken Links Become Dangerous

The previous chapter explained how broken links become dangerous. The following examples show what that looks like in practice.

Each scenario involves a different type of resource, but they all follow the same underlying pattern: a trusted destination changes hands while the original reference remains.

Expired External Domains

Imagine a company publishes a blog post that links to an external resource. A few years later, the owner lets the domain expire, but the link remains on the company’s website. Eventually, someone else registers the domain.

From a visitor’s perspective, nothing appears unusual. The URL is the same, and because it is referenced by a trusted website, many users will assume the destination is equally trustworthy.

What happens next depends on the new owner. They might publish unrelated content, advertising, affiliate pages, or phishing sites. Research from the Georgia Institute of Technology has shown that attackers deliberately re register expired domains to exploit the trust they inherit. The same study used honeypot domains to demonstrate that reclaimed domains can continue receiving tracking identifiers, application data, and traffic from malware infected systems. Separate research from the USENIX Symposium on Networked Systems Design and Implementation found thousands of malicious takeovers of abandoned cloud resources, including cases involving fraudulent TLS certificates and stolen cookies.

Automatically Loaded Resources

Ordinary links require a user to click them. Embedded resources are different because the browser retrieves them automatically whenever the page loads.

Imagine a page includes a third party JavaScript library.

If another party later gains control of the hosting domain, every visitor’s browser may automatically download and execute whatever JavaScript is served from that location. The browser does not distinguish between code served by the original owner and code served by someone else. It simply executes what it receives.

This principle is not limited to web browsers. Older versions of the npm package bignum, for example, downloaded precompiled binaries from an Amazon S3 bucket. After the bucket was abandoned and claimed by another party, installations retrieved attacker controlled binaries instead. GitHub later classified the issue as a critical supply chain vulnerability.

Not every embedded resource carries the same level of risk. JavaScript files can execute code within the context of the page that includes them. Stylesheets cannot execute JavaScript, but they can still manipulate the appearance of a page and trigger additional network requests. Iframes allow attackers to embed arbitrary content inside a trusted website while remaining isolated by the browser’s same origin protections.

Even images and fonts can be abused for tracking or reputational damage. In 2021, old embeds from the defunct video service Vidme began displaying pornography on pages belonging to major news organizations after the service’s former domain was acquired by an adult-content operator. The publications had not been hacked; their pages were still loading an external resource that was now controlled by someone else.

Subdomain Takeovers

Suppose a company creates a subdomain such as promo.example.com and points it to a cloud service or Software as a Service platform. Later, the project is retired and the cloud resource is deleted, but the DNS record is never removed.

If the service allows another customer to claim the same identifier, that customer may suddenly be able to serve content from the company’s legitimate subdomain. This type of issue is commonly known as a subdomain takeover.

A real world example illustrates the impact. Infoblox documented a dangling CNAME record under cdc.gov that pointed to an abandoned Azure resource. After reclaiming the resource, an attacker used the trusted CDC hostname to publish hundreds of pages that search engines indexed for unrelated topics, including English Premier League matches. Those pages ultimately redirected visitors to malicious content through a traffic distribution system.

Because the attacker controls a legitimate company subdomain, the potential impact can be significant. Depending on the surrounding configuration, they may inherit user trust, obtain valid TLS certificates, receive cookies scoped to the parent domain, abuse existing allowlists, or exploit authentication flows that assume the subdomain belongs to the organization.

Which Broken Links Matter Most?

Not every broken link deserves the same level of attention.

A temporary server outage is very different from an expired domain that someone else could register. Likewise, a forgotten link in an old blog post poses a very different risk than a third party script loaded on every page of your website.

Rather than treating every finding the same way, it helps to evaluate a few characteristics that determine how much damage could result if someone else gained control of the destination.

A useful way to think about this is:

Risk ≈ Reclaimability × Trigger × Capability × Inherited Trust × Exposure

While this is not a mathematical formula, it provides a practical framework for prioritizing findings.

Reclaimability

The first question is whether another party can actually take control of the destination.

Many broken links point to resources that are permanently unavailable or still belong to their original owner. In those cases, the issue is usually limited to availability.

If, however, the destination can be registered, recreated, or claimed by someone else, the situation becomes much more interesting from a security perspective. Without reclaimability, the attack chain stops before it begins.

Trigger

Next, consider how the resource is used. Does someone have to click the link, or is it loaded automatically whenever a page opens?

Resources that browsers retrieve automatically generally deserve more attention because they require no user interaction. Every page view becomes an opportunity for the resource to influence the visitor’s experience.

Capability

Different types of resources inherit different capabilities. An ordinary hyperlink primarily directs users to another location. An image can affect branding and user trust. A stylesheet can alter how a page appears. A JavaScript file can execute code within the context of the website that includes it.

The greater the capabilities granted to the destination, the greater the potential impact if ownership changes.

Inherited Trust

This is often the most overlooked factor. Some resources inherit very little trust beyond the fact that they appear on a webpage. Others inherit considerably more.

A company subdomain may be trusted by users, security policies, authentication systems, or browser cookies. An external script may already be allowed by a Content Security Policy. A long established domain may have accumulated years of backlinks and brand recognition.

The more trust the original owner has delegated to the resource, the more valuable it becomes if someone else gains control.

Exposure

Finally, consider how widely the reference is used.

A forgotten link buried in an archived article has limited reach. A shared JavaScript dependency that appears across thousands of pages has a much larger attack surface. The same applies to links embedded in documentation, customer portals, mobile applications, or other places that continue to send users to the destination long after it was created.

In practice, exposure often determines how urgently a finding should be addressed.

Putting these factors together makes prioritization much easier. An internal “404 Not Found” page on a domain you control is usually a maintenance task. An expired external domain linked from a popular page deserves investigation because it could eventually be reclaimed. A forgotten JavaScript dependency hosted on a third party domain is more concerning because it combines automatic loading with code execution. A dangling company subdomain trusted by authentication systems or browser cookies may represent an even higher priority because it inherits both technical capabilities and organizational trust.

How to Reduce the Risk

Reducing the risk starts long before an attacker becomes involved. In practice, it comes down to three things: preventing ownership changes, limiting their impact, and detecting unexpected changes early.

Prevent Ownership Changes

The first step is to prevent trusted resources from becoming reclaimable in the first place.

For domains, this means maintaining a complete inventory, centralizing ownership, enabling multifactor authentication on registrar accounts, and renewing domains before they expire. Every domain should have a clear owner, an expected purpose, and a documented renewal process. Domains should not quietly disappear because they were registered with a personal account or tied to a project that no longer exists.

The same principle applies to cloud services and Software as a Service platforms. Whenever a project is retired, ask a simple question: What still points to it? The answer may include DNS records, embedded scripts, API endpoints, documentation, or old blog posts. Removing those references should be part of the same change, not an afterthought.

Whenever possible, choose services that verify ownership of custom domains before allowing them to be configured. For example, GitHub Pages requires you to prove ownership by adding a DNS record to your domain before it will serve content for it. This makes it much harder for another GitHub account to claim an abandoned custom domain simply because a forgotten DNS record still points to GitHub’s infrastructure.

Reduce the Impact

Even with good operational practices, some external dependencies are unavoidable. The next layer of defense is limiting what those dependencies are allowed to do if they ever change hands.

Whenever practical, host stable JavaScript libraries and stylesheets yourself instead of relying on third party infrastructure. When a resource must remain external, consider using Subresource Integrity (SRI). SRI allows you to specify a cryptographic hash for the expected contents of a script or stylesheet.

src="https://cdn.example.com/library.js"

integrity="sha384-oqVuAfXRKap7..."

crossorigin="anonymous">

When the browser downloads the file, it verifies that the content matches the expected hash. If the file has been modified, the browser refuses to load it. An attacker may still control the hosting domain, but they cannot silently replace the script without also changing the hash embedded in your page.

The same principle applies to browser security policies. A Content Security Policy should allow executable resources only from the domains that are genuinely required. Avoid broad directives such as https: or unnecessary wildcard entries.

Content-Security-Policy:

script-src 'self' https://cdn.example.com

Authentication settings deserve the same level of precision. OAuth redirect URIs, postMessage origins, and similar trust relationships should reference only the exact destinations that are intended to receive them. Wildcards and overly broad allowlists make it easier for an attacker to benefit from a reclaimed resource.

Finally, scope cookies as narrowly as possible. A cookie that is valid for .example.com is automatically sent to every subdomain, including one that may later be taken over. Restricting the cookie to the application that actually needs it reduces the trust inherited by any compromised or reclaimed subdomain.

The goal is simple. If a resource ever changes hands, it should inherit as little trust and as few privileges as possible.

Monitor for Unexpected Change

Regular link checking is one of the simplest ways to identify references that deserve closer investigation. Most broken links are harmless maintenance issues, but some are the first visible sign that a trusted destination has changed or may soon change ownership. The sooner those problems are discovered, the easier they are to investigate and fix.

This is where automated link checking becomes particularly valuable. Instead of running occasional manual checks, schedule recurring scans so changes are detected as they happen. Depending on how frequently your website changes, that may mean monthly, biweekly, weekly, or even daily scans.

Dr. Link Check is designed for exactly this purpose. It crawls HTML and CSS to discover hyperlinks as well as external resources such as scripts, stylesheets, images, iframes, and other embedded content. Its primary focus is identifying broken and problematic references, but the scan also records every resource it finds, including those that are working correctly. That makes it easy to review and export a complete inventory of your website’s external dependencies for documentation, auditing, or further analysis.

Beyond ordinary HTTP errors, Dr. Link Check reports DNS failures, connection and TLS errors, redirects, blacklisted destinations, and soft errors such as parked or expired domains. Repeated scans make it possible to spot changes over time, such as a destination that changes from working, to unavailable, and back again.

Conclusion

So, are all broken links a security risk? No. Most broken links are ordinary maintenance issues. Pages are removed, services are retired, domains expire, and projects come to an end. That is simply part of running a website.

The situations worth investigating are those where a trusted destination can change hands while your website continues to point users or systems toward it. Depending on what that destination was trusted to do, the consequences can range from phishing and search engine abuse to malicious code execution or subdomain takeover.

That is why broken links deserve more than an occasional cleanup for usability or SEO purposes. They are often the first visible sign that something has changed. By monitoring them regularly, investigating unexpected changes, and treating external references as assets rather than implementation details, you can often identify potential security issues before they become security incidents.

Ultimately, the most important question is not whether a URL returns an error today. It is whether someone else could make it work tomorrow, and what your website would trust them to do if they did.