Tough-cookie is a battle-tested JavaScript library providing robust RFC6265-compliant cookie parsing and management for Node.js. It offers a full-featured cookie jar implementation suitable for handling cookies in HTTP clients and servers. Examining versions 1.1.0 and 1.2.0 reveals a relatively short development cycle focused on incremental improvements and bug fixes. While the core functionality remains consistent, moving from 1.1.0 to 1.2.0 ensures developers benefit from the latest refinements and stability enhancements. Both versions share identical dependencies including vows for testing and async for asynchronous operations, signalling a concentrated effort on optimizing existing features rather than introducing major architectural changes. The library's BSD-3-Clause license promotes open-source contributions and flexible integration into diverse projects. Maintained by Jeremy Stashewsky for Salesforce Engineering, tough-cookie has a strong industry backing with clear versioning and a well defined usage. Developers should update to the newest version to ensure they take advantage of possible bugfixes and security improvements, even if the changelog is not extensive. Using the latest version is best practice to have a stable and predictable behaviour of the cookie parser of your applications.
All the vulnerabilities related to the version 1.2.0 of the package
ReDoS via long string of semicolons in tough-cookie
Affected versions of tough-cookie
may be vulnerable to regular expression denial of service when long strings of semicolons exist in the Set-Cookie
header.
Update to version 2.3.0 or later.
Regular Expression Denial of Service in tough-cookie
Affected versions of tough-cookie
are susceptible to a regular expression denial of service.
The amplification on this vulnerability is relatively low - it takes around 2 seconds for the engine to execute on a malicious input which is 50,000 characters in length.
If node was compiled using the -DHTTP_MAX_HEADER_SIZE
however, the impact of the vulnerability can be significant, as the primary limitation for the vulnerability is the default max HTTP header length in node.
Update to version 2.3.3 or later.
tough-cookie Prototype Pollution vulnerability
Versions of the package tough-cookie before 4.1.3 are vulnerable to Prototype Pollution due to improper handling of Cookies when using CookieJar in rejectPublicSuffixes=false
mode. This issue arises from the manner in which the objects are initialized.