Threat Model for resolve (module path resolution library)

1. Library Overview

• Library Name: resolve
• Brief Description: Implements Node.js require.resolve() algorithm for synchronous and asynchronous file path resolution. Used to locate modules and files in Node.js projects.
• Key Public APIs/Functions: resolve.sync() / resolve/sync, resolve() / resolve/async

2. Define Scope

This threat model focuses on the core path resolution algorithm, including filesystem interaction, option handling, and cache management.

3. Conceptual System Diagram

Caller Application → resolve(id, options) → Resolution Algorithm → File System
                           │
                           └→ Options Handling
                           └→ Cache System

Trust Boundaries:
- Input module IDs: May come from untrusted sources (user input, configuration)
- Filesystem access: The library interacts with the filesystem to resolve paths
- Options: Provided by the caller
- Cache: Used to improve performance, but could be a vector for tampering or information disclosure if not handled securely

4. Identify Assets

• Integrity of resolution output: Ensure correct and safe file path matching.
• Confidentiality of configuration: Prevent sensitive path information from being leaked.
• Availability/performance for host application: Prevent crashes or resource exhaustion.
• Security of host application: Prevent path traversal or unintended filesystem access.
• Reputation of library: Maintain trust by avoiding supply chain attacks and vulnerabilities[1][3][4].

5. Identify Threats

Key Threats:
- Spoofing: Malicious module IDs mimicking legitimate packages, or spoofing configuration options[1].
- Tampering: Caller-provided paths altering resolution order, or cache tampering leading to incorrect results[1][4].
- Information Disclosure: Error messages revealing filesystem structure or sensitive paths[1].
- Denial of Service: Recursive or excessive resolution exhausting filesystem handles or causing application crashes[1].
- Path Traversal: Malicious input allowing access to files outside the intended directory[4].

6. Mitigation/Countermeasures

7. Risk Ranking

• High: Path traversal via malicious IDs (if not properly mitigated)
• Medium: Cache tampering or spoofing (if cache is not secured)
• Low: Information disclosure in errors (if error handling is generic)

8. Next Steps & Review

1. Implement input sanitization for module IDs and configuration.
2. Add resolution depth limiting and timeout.
3. Audit cache handling for race conditions and tampering.
4. Regularly review dependencies for vulnerabilities.
5. Keep documentation and threat model up to date.
6. Monitor for new threats as the ecosystem and library evolve[1][3].