Security Policy

Relevant source files

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

• SECURITY.md
• README.md
• package.json
• src/Parser.ts
• src/Tokenizer.ts
• src/Parser.spec.ts

The security policy for htmlparser2 outlines the protocols for maintaining the integrity of the parser, supporting versioning, and reporting potential vulnerabilities. As a fast and forgiving HTML/XML parser, security is managed through a combination of strict version support and a coordinated disclosure process via external partners.

This policy applies to the core parser implementation, including its streaming interfaces and DOM handling ecosystem. For more information on the project's general capabilities, refer to the README.md.

Sources: README.md:1-10, SECURITY.md:1-5

Vulnerability Reporting

The htmlparser2 project utilizes Tidelift for security vulnerability coordination. This ensures that potential threats are analyzed and resolved before public disclosure, minimizing the risk of exploitation for downstream consumers.

Reporting Process

When a security vulnerability is identified, it should not be reported via public GitHub issues. Instead, users are directed to the Tidelift security contact. Tidelift acts as the intermediary to coordinate the fix and subsequent disclosure.

Supported Versions

Maintenance and security updates are strictly limited to the current major version of the package. Users are responsible for keeping their installations updated to the latest release to ensure they receive security patches.

Support Category	Policy
Supported Versions	Only the current version is supported.
Update Strategy	Users MUST update to the latest release.
Legacy Versions	Not supported for security patches.

Sources: SECURITY.md:3-5

Technical Security Considerations

The parser includes several architectural features and configurations that impact security, particularly regarding how data is processed and sanitized.

Error Handling and State Safety

The Parser class implements strict state checks to prevent illegal operations during the parsing lifecycle. For instance, calling .write() or .end() after the parser has already finished results in a thrown error, preventing potential state-based attacks or memory corruption issues.

// src/Parser.ts:639-642
write(chunk: string): void {
    if (this.ended) {
        this.cbs.onerror?.(new Error(".write() after done!"));
        return;
    }
    // ...
}

Sources: src/Parser.ts:639-646, src/Parser.spec.ts:16-25

Input Sanitization and Special Tags

Security is influenced by how the parser handles sensitive HTML tags like <script>, <style>, and <title>. In standard HTML mode, these are treated as special tags where the content is considered text-only, preventing the execution of nested HTML tags unless xmlMode is explicitly enabled.

Option	Impact on Security/Parsing	Default
xmlMode	Disables special treatment for <script>/<style>.	false
decodeEntities	Decodes entities like &amp; to &.	true
lowerCaseTags	Normalizes tag names to prevent case-obfuscation.	true (in HTML)

Prototype Pollution Prevention

The parser explicitly handles sensitive keys to prevent prototype pollution. For example, the project includes tests to ensure that tags named <__proto__> are parsed correctly as standard elements without affecting the JavaScript object prototype.

Sources: src/Parser.spec.ts:208-212

Summary

htmlparser2 maintains security through a coordinated reporting channel via Tidelift and a strict "current version only" support policy. Architecturally, it mitigates common parsing risks through state validation, prototype pollution tests, and controlled handling of special tags like <script>. Users must remain on the latest version to ensure protection against newly discovered vulnerabilities.

Sources: SECURITY.md:1-10, package.json:1-15