JavaScript in URLs: Is it Safe?

TL;DR

URLs can contain JavaScript code, but modern browsers generally won’t execute it directly due to security risks. However, there are ways this can still be exploited (e.g., through data URLs or vulnerabilities in specific applications). It’s best practice to avoid using JavaScript within URLs whenever possible.

Understanding the Problem

Traditionally, URLs were designed for identifying resources (web pages, images, etc.), not running code. However, the URL standard allows for including data directly within a URL, which can include JavaScript. The question is whether browsers will actually run that code.

Steps to Understand and Mitigate Risks

1. Direct Execution (Generally Blocked): Most modern browsers block the direct execution of JavaScript embedded in standard URLs like this:

   javascript:alert('Hello');

   This is a security measure to prevent malicious code from being run simply by clicking a link.

2. Data URLs (Potential Risk): Data URLs allow embedding small amounts of data directly into the URL. JavaScript can be encoded within a data URL:

   data:text/html;charset=utf-8,

   While not executed directly as JavaScript, this HTML snippet will run the script if the browser interprets it. Browsers are increasingly cautious about data URLs.

3. `javascript:` pseudo-protocol (Legacy Risk): Older browsers supported a `javascript:` pseudo-protocol for executing code from URLs:

   <a href="javascript:alert('Hello');">Click me</a>

   This is largely deprecated and blocked in modern browsers, but it’s important to be aware of its historical existence.

4. Vulnerabilities in Applications (Highest Risk): The biggest risk isn’t the URL itself, but how applications handle URLs. If a web application parses a URL and uses the data within it without proper sanitisation, it could be vulnerable to cross-site scripting (XSS) attacks.
   • Example: Imagine an application that takes a URL parameter and displays its value on a page. If the application doesn’t properly encode HTML entities, malicious JavaScript injected into the URL parameter could execute in the user’s browser.
5. How to Protect Yourself (and Your Applications):
   • Input Validation: Always validate and sanitise any data received from URLs before using it.
   • Output Encoding: Encode HTML entities when displaying user-provided data on a web page. This prevents the browser from interpreting malicious code as executable.

     <!-- Example in PHP -->
     <?php
     echo htmlspecialchars($_GET['param'], ENT_QUOTES, 'UTF-8');
     ?>

   • Content Security Policy (CSP): Implement a strong Content Security Policy to control the resources that your web application is allowed to load. This can help prevent XSS attacks.
   • Avoid JavaScript in URLs: The simplest solution is often to avoid using JavaScript within URLs altogether. Use alternative methods for passing data and triggering actions, such as POST requests or dedicated API endpoints.

Testing

You can test the behaviour of different browsers with sample URLs containing JavaScript (be careful when testing!). Use your browser’s developer tools to inspect network requests and console output.