Unsafe JQuery Plugin

ID

javascript.unsafe_jquery_plugin

Severity

low

Resource

Injection

Language

JavaScript

Tags

CWE:116, CWE:79, NIST.SP.800-53, OWASP:2021:A2, PCI-DSS:6.5.3, jquery

Description

When a jQuery plugin allows user-supplied input to be interpreted as HTML or used in dynamic HTML construction without proper sanitization, it can lead to a Cross-Site Scripting (XSS) vulnerability.

A common example is when a plugin accepts options (such as selectors or content) and directly passes them to JQuery methods such as jQuery() (often aliased as $()) or .html(). If options are not sanitized, malicious input can result in a classical DOM-based XSS vulnerability.

Rationale

This detector looks for JQuery plugins that accept user-supplied input and directly pass it to JQuery methods that could interpret the input as HTML.

A typical unsafe pattern flagged by this rule might look like:

// Vulnerable JQuery plugin
$.fn.copyText = function(options) {
  // DANGEROUS: may evaluate `options.sourceSelector` as HTML
  var source = $(options.sourceSelector),
      text = source.text();
  $(this).text(text);
}

options.sourceSelector is not properly sanitized before being passed to jQuery(options.sourceSelector). If the plugin is called with options depending on external input, an attacker may pass malicious input as HTML with JavaScript handlers to launch a XSS attack. For example:

<div id="unsafe">Hello <img src="x" onerror="alert('Hacked')"></div>

Remediation

The plugin should use methods that do not interpret input as HTML, such as jQuery.find, which always treats the argument as a CSS selector:

$.fn.copyText = function(options) {
  // SAFE: will not evaluate `options.sourceSelector` as HTML
  var source = $.find(options.sourceSelector),
      text = source.text();
  $(this).text(text);
}

Alternatively, the plugin can validate that the options field used matches a given pattern via regular expression test.

Best practices for developing JQuery plugins include:

  • Guard against unsafe inputs where dynamic HTML construction is not intended.

  • Prefer APIs that do not interpret input as HTML unless absolutely necessary, and sanitize any user-supplied data before use.

  • If needed, always document plugin options that could lead to XSS, making it clear when the client is responsible for sanitizing input.

Configuration

This detector does not have any configurable parameters.

References