Reflected XSS into a JavaScript string with angle brackets HTML encoded.

href Attribute XSS Using javascript: URI Scheme

Cross-Site Scripting (XSS) is often associated with injecting HTML tags or breaking out of script contexts, but a less obvious and equally dangerous variant occurs when user input is directly inserted into HTML attributes such as href. In particular, when applications fail to validate URL schemes, attackers can exploit the browser’s support for JavaScript URIs to execute arbitrary code. This technique is commonly referred to as attribute-based XSS via javascript: URLs.

In a typical vulnerable application, user input is used to populate an anchor tag dynamically. For example:

<a href="USER_INPUT">Click here</a>

If the application does not properly validate the input before inserting it into the href attribute, an attacker can supply a malicious value such as:

javascript:alert(1)

When rendered by the browser, the HTML becomes:

<a href="javascript:alert(1)">Click here</a>

At first glance, this may appear harmless because no HTML tags or scripts are explicitly injected. However, the vulnerability arises from how browsers interpret URI schemes. The javascript: scheme is a special protocol supported by browsers that allows JavaScript code to be executed directly when the link is activated. As a result, when a user clicks the link, the JavaScript engine executes the payload in the context of the current page.

This behavior turns a seemingly simple navigation attribute into a code execution vector, effectively achieving XSS without traditional HTML injection techniques. The payload itself is minimal, but its impact depends on how the browser handles the link interaction.

It is important to understand that this vulnerability is not related to angle brackets or HTML structure manipulation. Instead, it is purely a consequence of trusting unvalidated input in a URL context. Even if the application encodes characters like < and >, the attack still succeeds because no HTML parsing is required. The browser does not need to interpret new elements; it only needs to interpret the href value as a JavaScript URI.

This makes the vulnerability particularly dangerous in scenarios where user-generated content is displayed as links, such as comments, profiles, or social feeds. Since the payload is stored or reflected directly into the DOM, any user interacting with the malicious link becomes a potential victim.

The root cause of this issue is the lack of input validation and scheme restriction. Developers often assume that inserting a URL into an href attribute is safe by default, but this assumption ignores the existence of dangerous URI schemes such as javascript:. Without explicit validation, the application effectively delegates execution control to the attacker.

To mitigate this vulnerability, strict validation of user input is essential. Applications should implement an allowlist of permitted schemes, typically restricting URLs to http: and https: only. Any input that does not conform to these schemes should be rejected or sanitized before being stored or rendered.

A more robust approach involves parsing the URL using built-in APIs such as the URL constructor and explicitly checking the protocol before usage. This ensures that malformed or malicious schemes cannot bypass validation through obfuscation or encoding tricks.

Additionally, Content Security Policy (CSP) can serve as a defense-in-depth mechanism by restricting the execution of inline JavaScript and limiting allowed URL sources. However, CSP should not be relied upon as the primary mitigation, as proper input validation remains the most effective defense.

In conclusion, href attribute-based XSS demonstrates how browser features intended for flexibility can be abused when user input is not properly controlled. Even without traditional HTML injection, attackers can achieve JavaScript execution simply by manipulating URL schemes. Understanding this subtle attack vector is essential for both developers and security practitioners aiming to build secure web applications.