Security Policy

Relevant source files

The following files were used as context for generating this wiki page:

• SECURITY.md
• THREAT_MODEL.md
• INCIDENT_RESPONSE.md
• CONTRIBUTING.md
• Readme.md
• package.json

The Cheerio security policy defines the framework for identifying, reporting, and remediating vulnerabilities within the library and its associated ecosystem (including htmlparser2 and css-select). As a server-side HTML/XML parsing library for Node.js, Cheerio emphasizes protection against malicious input that could lead to resource exhaustion, data corruption, or enablement of client-side attacks.

This policy establishes clear boundaries between the library's responsibilities and those of the calling application. While Cheerio ensures internal parsing logic is secure against threats like prototype pollution and ReDoS, it explicitly requires applications to handle sanitization before rendering output in a browser context.

Sources: SECURITY.md:46-52, THREAT_MODEL.md:9-12, INCIDENT_RESPONSE.md:3-6

Threat Model and Trust Boundaries

Cheerio operates within a server-side Node.js environment. The security architecture distinguishes between untrusted data provided by users and the trusted environment provided by the runtime and calling application.

Trust Classifications

Boundary	Type	Description
Untrusted	Input Markup	All HTML, XML, or strings passed to load(), loadBuffer(), or manipulation methods.
Untrusted	CSS Selectors	External selectors that could trigger pathological backtracking in the engine.
Trusted	JS Runtime	Assumed correct, unpatched Node.js or compatible environment.
Trusted	Calling App	Responsible for sanitizing Cheerio's output before browser rendering.
Trusted	Underlying Parsers	parse5 and htmlparser2 are considered part of the managed ecosystem.

Sources: THREAT_MODEL.md:14-27, THREAT_MODEL.md:48-52

Data Flow and Boundary Diagram

The following diagram illustrates how untrusted markup enters the system and where the security responsibility shifts back to the developer.

Vulnerability Scope

Cheerio maintainers prioritize vulnerabilities that involve asymmetric resource consumption or corruption of the JavaScript environment.

In-Scope Vulnerabilities

• Denial of Service (DoS): Crafted input causing disproportionate CPU or memory consumption (e.g., ReDoS, quadratic parsing, exponential entity expansion).
• Prototype Pollution: Modification of Object.prototype or built-in prototypes via parsed content.
• XSS Enablement: Serializer defects that produce output materially more dangerous than input (e.g., incorrect attribute escaping).
• Unexpected Code Execution: Paths leading to eval or Function execution of attacker-supplied content.
• Information Disclosure: Leaking data from the runtime environment during serialization/parsing.

Sources: SECURITY.md:46-52, THREAT_MODEL.md:29-37

Out-of-Scope (Non-Vulnerabilities)

• Unsafe rendering: Failure to use a dedicated sanitizer (like sanitize-html) before browser rendering.
• API Misuse: Passing attacker-controlled strings as property names or unsanitized objects as options (CWE-20).
• Resource Exhaustion (Symmetric): Legitimate large inputs (e.g., 500MB file) consuming expected memory.
• Supply Chain: Third-party dependencies outside the immediate ecosystem (CWE-1357).

Sources: SECURITY.md:54-58, THREAT_MODEL.md:39-50

Reporting and Disclosure Process

Public GitHub issues must not be used for reporting security vulnerabilities. The project uses a coordinated disclosure model.

Reporting Channels

1. Primary: Tidelift security contact for coordinated disclosure.
2. Secondary: GitHub Private Vulnerability Reporting if the primary channel is unresponsive.

Sources: SECURITY.md:13-20

Incident Response Lifecycle

Maintainers follow a structured response plan with target timelines based on severity.

Severity and Response Targets

Severity	Definition	Update Cadence	Target Fix
Critical	Active exploitation / RCE / Supply-chain compromise	Daily	< 7 days
High	Easily exploitable DoS / Prototype Pollution	Every 3 days	< 14 days
Medium	Unusual configuration required / Limited impact	Weekly	Next Release
Low	Defense-in-depth / Theoretical risks	As needed	Scheduled

Sources: INCIDENT_RESPONSE.md:10-14

Supported Versions

Security updates are only provided for the latest release on the 1.x branch.

Version	Supported
1.x	✅ Yes
< 1.0	❌ No

Sources: SECURITY.md:5-10, package.json:3

Summary

Cheerio maintains a robust security posture focused on its role as a server-side parser. By identifying clear trust boundaries and maintaining a formal incident response plan, the project protects users from internal logic flaws like prototype pollution and DoS. However, users are reminded that Cheerio is not a sanitizer; ultimate responsibility for preventing XSS in browser environments rests with the calling application's implementation.

Sources: THREAT_MODEL.md:48-52, INCIDENT_RESPONSE.md:3-6