PaperlayerView exact revision on arXiv

Source-linked AI summary

Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web

Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad, William Robertson, Christo Wilson, Engin Kirda

arXiv:1811.00918v2cs.CR

TL;DR

Websites’ heterogeneous components and client-side code create a large attack surface, while comprehensive evidence about vulnerable and outdated JavaScript libraries has been limited. The paper combines library metadata, code identification, and causal crawl analysis to study real-world usage, finding widespread vulnerability, multi-year version lag, and risky transitive inclusion patterns.

  • Problem

    Websites’ heterogeneous components and client-side code create a large attack surface, motivating a comprehensive study of vulnerable and outdated JavaScript libraries.

  • Method

    The study combines library metadata, JavaScript library identification, and website crawling that tracks causal resource-inclusion relationships.

  • Results

    More than 37% of websites use a library version with a known vulnerability, while median version lag reaches 1,177 days in ALEXA and 1,476 days in COM.

  • Takeaways & Limitations

    Transitive inclusions from advertising, tracking, and social widgets have higher vulnerability rates, and third-party composition can produce duplicate or nondeterministic library behavior.

Abstract

from arXiv · show

Web developers routinely rely on third-party Java-Script libraries such as jQuery to enhance the functionality of their sites. However, if not properly maintained, such dependencies can create attack vectors allowing a site to be compromised. In this paper, we conduct the first comprehensive study of client-side JavaScript library usage and the resulting security implications across the Web. Using data from over 133 k websites, we show that 37% of them include at least one library with a known vulnerability; the time lag behind the newest release of a library is measured in the order of years. In order to better understand why websites use so many vulnerable or outdated libraries, we track causal inclusion relationships and quantify different scenarios. We observe sites including libraries in ad hoc and often transitive ways, which can lead to different versions of the same library being loaded into the same document at the same time. Furthermore, we find that libraries included transitively, or via ad and tracking code, are more likely to be vulnerable. This demonstrates that not only website administrators, but also the dynamic architecture and developers of third-party services are to blame for the Web's poor state of library management. The results of our work underline the need for more thorough approaches to dependency management, code maintenance and third-party code inclusion on the Web.

I. INTRODUCTION

The paper examines how websites use client-side JavaScript libraries and the security risks of outdated, vulnerable, or indirectly included dependencies. Its large-scale study finds widespread vulnerability, duplicated versions, weak management practices, and ecosystem-level causes.

  • Motivation: Websites inherit client-side attack risks when third-party libraries contain vulnerabilities, making timely dependency updates important.The paper highlights XSS and related risks from vulnerable library versions, including a pre-1.6.3 jQuery vulnerability.
  • Research scope: The study is the first comprehensive analysis of JavaScript library usage and its security implications across websites.It investigates library origins, freshness, vulnerabilities, inclusion causes, remediation, and possible improvements.
  • Findings: More than a third of Alexa websites include at least one vulnerable library, while the median library version is 1,177 days older than the newest release.Vulnerable versions affect at least 36.7% of jQuery, 40.1% of Angular, 86.6% of Handlebars, and 87.3% of YUI inclusions.
  • Findings: Third-party modules and services can create transitive vulnerable inclusions, extending responsibility beyond individual website administrators.The paper specifically identifies advertising, tracking, and social widget code as sources of these inclusions.
  • Findings: 4.2% of jQuery-using Alexa websites load the same version repeatedly, and 10.9% load multiple jQuery versions in one document.Asynchronous loading can make behavior nondeterministic and leave the ultimately used version unclear.
  • Ecosystem and approach: JavaScript library management lacks reliable vulnerability databases, popular-library security mailing lists, detailed release-note information, and clear affected-version data.The study therefore constructs a catalogue of 72 libraries and uses static, dynamic, and causal inclusion analysis.
  • Remediation: Existing remediation is limited: fewer than 3% of websites could fix all vulnerable libraries using only patch-level updates, and only 2% use CDN version aliasing.The contribution summary presents these figures as evidence that current remediation strategies are ineffective or rarely used.

II. BACKGROUND

Client-side JavaScript libraries package reusable browser functionality and are commonly loaded from external files, CDNs, or third-party modules. Their broad privileges and input-handling behavior can expose websites to vulnerabilities, including XSS, especially when third parties load libraries indirectly.

  • JavaScript libraries: JavaScript libraries bundle reusable functionality that simplifies document manipulation, event handling, animation, and AJAX across browsers.jQuery is given as a prominent example of this convenience.
  • Inclusion mechanisms: Libraries may be externally hosted, copied locally, concatenated, custom-built, or minified before inclusion through script tags.CDNs also host libraries and can provide caching and version-aliasing features.
  • Third-party code: Third-party advertising, tracking, and widget scripts can load libraries without the site maintainer’s knowledge.When not isolated in a frame, these libraries operate with full privileges in the including site’s context.
  • Vulnerabilities: JavaScript libraries can introduce XSS when they accept unsanitised input and treat it as executable code or markup.The paper notes that vulnerable behavior can let attackers steal session data, initiate transactions, or place fake content on websites.
  • Vulnerabilities: Older jQuery versions could interpret strings containing HTML as markup, so crafted input such as an image tag could trigger code execution.This behavior was considered a vulnerability and was fixed.
  • Catalogue and measurement: The library catalogue supports 72 libraries, while Table I distinguishes versions available for static detection from dynamic detections observed in crawls.The table covers the 30 most frequent libraries in the Alexa crawl.

III. METHODOLOGY

The study builds a catalogue and measurement pipeline for identifying popular JavaScript libraries, their versions, and publicly documented vulnerabilities across websites. It combines manually collected metadata and code samples with static and dynamic analysis, while acknowledging coverage limitations.

  • Library selection: The researchers support 72 widely used open-source JavaScript libraries, selected from Bower, Wappalyzer, and major commercial CDNs.The selection emphasizes popular libraries because they are considered most consequential.
  • Metadata collection: Version and vulnerability metadata were assembled from GitHub, public vulnerability sources, bug trackers, blogs, and Retire.js.Systematically documented vulnerability details were obtained for 11 libraries, with affected versions inferred from documented ranges or version-specific flaws.
  • Reference catalogue: 81,027 JavaScript files were collected, reduced to 19,099 distinct reference files after deduplication and filtering.Files smaller than 996 bytes were discarded to reduce false positives from ancillary resources.
  • Vulnerability catalogue: 28.3%, 6.7%, and 6.1% of catalogued versions contain one, two, or three known vulnerabilities, respectively.Angular 1.2.0 is identified as the worst offender, with five vulnerabilities.
  • Limitations: The catalogue excludes some closed-source or poorly versioned libraries and may miss unnumbered revisions or unavailable code samples.Vulnerability assessments rely solely on publicly available documentation and do not establish exploitability or comparable vulnerability coverage across libraries.

B. Library Identification

Library identification combines exact file-hash matching with runtime fingerprinting to detect libraries despite common code modifications. Dynamic detection broadens coverage but depends on version strings and both techniques can miss heavily modified code.

  • Static detection: Static detection identifies libraries used as-is by comparing observed script hashes with 19,099 reference hashes.This approach directly matches source files against the catalogue.
  • Dynamic detection: Dynamic detection fingerprints browser JavaScript environments and queries library-specific globals or methods for version information.For jQuery, the detector checks recognized global variables and the fn.jquery attribute while rejecting missing or invalid version strings.
  • Coverage: 39 of 72 libraries can be detected dynamically because the technique requires a present version attribute.Older versions lacking version strings may therefore escape dynamic detection.
  • Coverage: Version coverage is often similar between static and dynamic detection, with dynamic detection outperforming static detection when CDN data is incomplete.The comparison is made between dynamically detected crawl versions and the static reference catalogue.
  • Limitations: The measurement results should be viewed as lower bounds because heavily modified libraries, incorrect CDN claims, or concealed version information can defeat both techniques.The authors describe the detectors as a best-effort approach rather than complete identification.

C. Data Collection

The data-collection system records causal relationships among dynamically created web resources while integrating library detection and script provenance across frames. It combines browser instrumentation, repeated frame inspection, ad annotation, and crawls of popular and randomly sampled domains.

  • Causality trees: Causality trees represent directed element-creation relationships, where an edge A →B means A causes B to load.They model scripts, images, media, stylesheets, and embedded HTML documents rather than the hierarchical DOM structure.
  • Causality trees: The example tree distinguishes documents, scripts, and other resources, while edges encode creation, line styles encode inline versus URL-loaded scripts, and colors identify document attachment.The figure’s nodes and edges are designed to expose cross-frame inclusion relationships.
  • Illustrative result: A causality tree for mercantil.com shows social widgets creating frames and multiple copies of jQuery loaded in the main document.The example illustrates how third-party widget code and repeated library inclusion appear in one causal structure.
  • Browser instrumentation: The crawler observes resource requests through the Chrome Debugging Protocol and disables caching to retain duplicate inclusions.This supports reconstruction of causal loading relationships, including resources represented by inline URL schemes.
  • Detection integration: Static detection is integrated by hashing script nodes, while dynamic detection links detected library objects and methods to the scripts that implement them.Detection code is injected into each frame because frames have separate JavaScript scopes and may contain independent library instances.
  • Detection integration: Detection runs every four seconds in each frame and is supplemented by post-hoc execution over crawled scripts, although offline detection cannot replace browser execution completely.The interval balances coverage with the impracticality of checking after every script-creation event.
  • Crawl datasets: The study crawls the Alexa Top 75k domains and 75k randomly sampled .com domains to represent popular and less popular websites.The two datasets were collected in May 2016.

D. Validation

The study validates dynamic and static library-detection methods against controlled experiments and manual inspection. Dynamic detection usually identifies library names and versions, whereas file-hash detection performs poorly on customized libraries, and URL-name heuristics produce false positives and negatives.

  • 79.2% of libraries were identified by dynamic detection with exact names and versions, while 18.6% were identified by name only.Only 2% failed identification; name-only detections were mostly older versions lacking version-reporting variables or methods.
  • 15.4% of sampled libraries were identified as jQuery using file hashes.The low rate is consistent with developers deploying customized or custom-minified library versions.
  • URL-name heuristics generated both false positives and false negatives for detecting JavaScript libraries.Scripts containing “jquery” often contained plugins rather than the library, while library files could use unrelated names.
  • Manual examination of 50 scripts from each disagreement set confirmed that heuristic-only detections were generally not the target library.Detection-only scripts usually contained additional application code or other libraries.
  • Modernizr results showed 55.3% URL overlap, 0.8% heuristic-only detections, and 44% detection-only files.The results support using more robust static and dynamic methods instead of the URL heuristic.

IV. ANALYSIS

The analysis proceeds from causality trees and JavaScript inclusion statistics to vulnerable-library risk, library age, duplicate inclusions, and remediation practices.

  • The analysis covers causality trees, JavaScript inclusion statistics, vulnerable libraries, risk factors, library age, duplicate inclusions, and remediation practices.

A. Causality Trees

The crawls characterize website complexity, script inclusion patterns, library usage, hosting sources, and causal links to advertising, tracking, and widget code. ALEXA sites are generally more complex and more dependent on external resources than COM sites.

  • Causality trees: ALEXA causality trees contain a median of 133 nodes versus 38 in COM, with larger medians for image, script, and document nodes.The 95th-percentile tree sizes are 425 for ALEXA and 298 for COM.
  • Causality trees: Median causality-tree depth is 4 inclusions in ALEXA and 3 in COM.Maximum depths reach 438 and 62, respectively.
  • JavaScript inclusion: 97% of ALEXA sites and 83.6% of COM sites contain JavaScript.Inline scripts are the most common script type, with medians of 24 and 9 per site, respectively.
  • JavaScript inclusion: 91.7% of ALEXA sites include at least one external script, with a median of 9 externally hosted scripts per site.ALEXA sites include scripts from a median of 5 external hosts, and at least 5 of the 10 most frequent hosts are advertising-related.
  • Library usage: 86.6% of ALEXA sites and 65.4% of COM sites contain at least one detected library among the 72 catalogued targets.jQuery is the most prevalent detected library.
  • Causal origins: 7.3% of ALEXA sites and 16.0% of COM sites contain a library inclusion causally related to advertising, tracking, or widget code.SWFObject and GreenSock are relatively often included by such code.

D. Vulnerable Libraries

Known-vulnerable library versions appear on a substantial share of websites, with prevalence varying by popularity, category, and library. The reported library-specific percentages are not intended as comparisons of relative library vulnerability.

  • 37.8% of ALEXA sites use at least one known-vulnerable library version, while 9.7% use two or more different vulnerable versions.The corresponding COM percentages are 37.4% and 4.1%.
  • 21% of the Top 100 ALEXA websites use a known-vulnerable library, increasing to 32.2% in the Top 1k.The vulnerable-site percentage stabilizes in the Top 5k and remains around that level toward lower ranks.
  • 52% of financial and 50% of governmental ALEXA websites contain vulnerable libraries.Parked and adult sites have the lowest reported proportions, at 24% and 19%.
  • 36.7% of jQuery, 40.1% of Angular, 86.6% of Handlebars, and 87.3% of YUI 3 inclusions are known vulnerable in ALEXA.YUI 3 is no longer maintained.
  • The library-specific vulnerable-inclusion percentages are not suitable for comparing the relative vulnerabilities of different libraries.

E. Risk Factors for Vulnerability

Vulnerability risk varies with how libraries are included and how far their versions lag current releases. Indirect, third-party, and outdated inclusions are associated with higher exposure, while the measured factors are coarse and library-specific.

  • Indirect inclusions through intermediate scripts or frames are more likely to be vulnerable than direct inclusions by the main document.
  • Ad, widget, or tracker inclusions are more vulnerable than unrelated inclusions, reaching 89% for jQuery associated with such code in COM.The authors speculate that less reputable networks or widgets on smaller COM sites may contribute.
  • 657 days is the median Angular lag for vulnerable inclusions, compared with 234 days for non-vulnerable inclusions and 398 days overall.Lag can be zero even when a branch remains vulnerable because no fixed version is available.
  • 61.4% of ALEXA sites are at least one patch version behind on an included library, while the median site lags 1,177 days behind the newest release.The corresponding COM figures are 46.2% and 1,476 days.
  • Governmental and financial ALEXA sites have median lags of 1,293 and 1,239 days, respectively.Parked and adult sites have values better than the average.
  • Median lags measured in years suggest that developers rarely update library dependencies after deploying a site.

G. Duplicate Inclusions

Websites frequently load duplicate or multiple library versions through direct and transitive relationships, complicating dependency behavior and remediation. Patch-level updates alone would eliminate vulnerabilities for only a small minority of potentially vulnerable sites.

  • 20.7% of ALEXA websites using jQuery include it two or more times, and 4.2% include the same version repeatedly in one document.The corresponding rate for COM is 17.2%.
  • At ms.gov, one jQuery 2.2.2 instance is directly included, while twelve jQuery 2.2.0 instances are injected by self-hosted scripts.The causality tree identifies the direct and transitive origins of the duplicate inclusions.
  • Mercantil.com directly references four different jQuery versions, illustrating how independently developed components can place multiple versions in one document.The authors suggest server-side templating or combined components as possible explanations.
  • Only 2.8% of potentially vulnerable ALEXA sites and 1.6% of COM sites could become vulnerability-free through patch-level updates alone.Most sites would require at least a major or minor version update, which may require code changes because of incompatibilities.

V. DISCUSSION

The discussion attributes poor library security to weak dependency management, incomplete vulnerability information, compatibility barriers, and dynamically loaded third-party code. It argues for more systematic maintenance and safer handling of external components.

  • Developers need systematic dependency management to know which libraries they use and to update dependencies beyond manually copied files or CDN links.The paper identifies configuration-based tools such as Bower and Node Package Manager as examples.
  • JavaScript vulnerability information is poorly tracked and disseminated, limiting the effectiveness of strategies that depend on developers learning about and fixing flaws.The paper notes sparse database coverage, absent security mailing lists, and incomplete release notes.
  • Patches often target only recent versions, while frequent breaking API changes make it difficult to keep older deployments secure without additional maintenance.This creates compatibility barriers for developers maintaining deployed sites.
  • Libraries loaded by advertising, tracking, or social-media components have higher vulnerability rates and may be absent from the website’s codebase.The paper recommends checking whether a library is already loaded and isolating third-party components in separate frames when feasible.
  • Existing tools detect some vulnerable libraries but may miss dependencies, inline or dynamically evaluated scripts, duplicate cached inclusions, or inclusion causes.Retire.js and Library Detector do not provide the full causal coverage used in this study.

VII. CONCLUSION

The study finds widespread use of vulnerable and outdated JavaScript libraries, with transitive third-party inclusions especially exposed and duplicate versions complicating behavior. These results support more systematic dependency management and third-party code practices.

  • More than 37% of websites use at least one library version with a known vulnerability.The study also reports that 86.6% of ALEXA Top 75k websites and 65.4% of COM websites use at least one catalogued library.
  • The median lag behind the newest available library version is 1,177 days in ALEXA and 1,476 days in COM.Some libraries still in active use are no longer maintained.
  • Transitive inclusions through advertising, tracking, or social-media code have higher vulnerability rates than direct inclusions.Content composition can also create duplicate library inclusions and potentially nondeterministic vulnerability behavior.
  • Remediation is hindered by a lack of backwards-compatible patches and scarce vulnerability information.
  • The findings highlight the need for more thorough and systematic JavaScript library inclusion and dependency management.
Loading 1811.00918v2…