mitigations.md

Mitigation Strategies Analysis for preactjs/preact

Mitigation Strategy: Strictly Avoid Manual DOM Manipulation

• Description:

  1. Establish a Coding Standard: Create a clear, documented coding standard that explicitly prohibits direct DOM manipulation using methods like innerHTML, outerHTML, insertAdjacentHTML, etc., within Preact components. This is crucial because Preact relies on its virtual DOM for efficient and secure rendering.
  2. Code Review Enforcement: Implement mandatory code reviews. Reviewers should specifically check for any violations of the "no direct DOM manipulation" rule within component logic.
  3. Education and Training: Train developers on the dangers of bypassing Preact's rendering and the benefits of using JSX and the component lifecycle.
  4. Use of Linting Tools: Integrate ESLint with rules like react/no-danger (adaptable for Preact) and no-unsanitized/method to automatically detect and flag potential violations during Preact component development.
  5. Refactoring Existing Code: If direct DOM manipulation is found within existing Preact components, prioritize refactoring it to use Preact's JSX and component structure.
  6. Exception Handling (Rare and Justified Cases): If direct DOM manipulation is absolutely unavoidable within a Preact context (e.g., integrating with a legacy library that requires it and cannot be wrapped), create a dedicated, isolated Preact component for this interaction. Within this specific Preact component, implement rigorous input sanitization using a library like DOMPurify before any DOM interaction. Document the reason for this exception clearly and ensure it's isolated from the rest of the Preact application.

• Threats Mitigated:

  • Component Injection (XSS - Preact Specific): (Severity: High) - Prevents attackers from injecting malicious code by bypassing Preact's virtual DOM and rendering process. This is a Preact-specific threat because it exploits the framework's rendering mechanism.
  • Unexpected Application Behavior (Preact Specific): (Severity: Medium) - Reduces conflicts between Preact's virtual DOM and manual DOM changes, ensuring consistent rendering.

• Impact:

  • Component Injection (XSS): Risk reduction: Very High. This is the primary defense against this Preact-specific XSS vector.
  • Unexpected Application Behavior: Risk reduction: High. Improves Preact component stability.

• Currently Implemented:

  • Example: "Coding standards (section 3.2) prohibit direct DOM manipulation within Preact components. ESLint rule react/no-danger is enabled. Code reviews are mandatory."

• Missing Implementation:

  • Example: "Refactoring of LegacyPreactWidget.js is required; it uses innerHTML within its render method."

Mitigation Strategy: Prop Type Validation and Enforcement (Preact's propTypes)

• Description:

  1. Define Prop Types: For every Preact component, define propTypes to specify the expected data type for each prop. Use specific types and custom validators where possible.
  2. Custom Validators: For props requiring specific formats, create custom validator functions within Preact's propTypes.
  3. Runtime Enforcement (Development Mode): Ensure that propTypes validation is enabled in development mode. Preact will log warnings if prop types are violated.
  4. Regular Audits: Periodically review the propTypes definitions to ensure they are up-to-date.

• Threats Mitigated:

  • Component Injection (Indirectly - Preact Specific): (Severity: Medium) - Reduces the chance of unexpected data types leading to vulnerabilities within Preact's rendering.
  • Unexpected Application Behavior (Preact Specific): (Severity: Medium) - Prevents errors caused by incorrect prop values passed to Preact components.

• Impact:

  • Component Injection (Indirectly): Risk reduction: Medium. Strengthens Preact component robustness.
  • Unexpected Application Behavior: Risk reduction: High. Improves Preact component reliability.

• Currently Implemented:

  • Example: "All Preact components have propTypes defined. Custom validators are used for email and URL props in UserForm.js."

• Missing Implementation:

  • Example: "Legacy Preact components need propTypes added."

Mitigation Strategy: Minimize and Sanitize dangerouslySetInnerHTML (Preact Specific)

• Description:

  1. Avoidance as Primary Strategy: Avoid using Preact's dangerouslySetInnerHTML whenever possible. Explore alternatives like parsing HTML into a Preact-compatible structure or using Preact components for rendering.
  2. Strict Sanitization (If Unavoidable within Preact): If dangerouslySetInnerHTML is absolutely necessary within a Preact component, use DOMPurify.
     • Configuration: Configure DOMPurify strictly.
     • Regular Updates: Keep DOMPurify updated.
  3. Input Validation (Before Preact Rendering): Validate data before it's considered for use with Preact's dangerouslySetInnerHTML.
  4. Code Review and Documentation: Any use of Preact's dangerouslySetInnerHTML should be documented and scrutinized during code reviews.

• Threats Mitigated:

  • XSS via dangerouslySetInnerHTML (Preact Specific): (Severity: High) - Directly mitigates XSS through malicious HTML within Preact's rendering context.
  • Bypass of Sanitization: (Severity: High)

• Impact:

  • XSS via dangerouslySetInnerHTML: Risk reduction: Very High (with sanitization). Avoidance is best.
  • Bypass of Sanitization: Risk reduction: Medium.

• Currently Implemented:

  • Example: "Preact's dangerouslySetInnerHTML is not currently used. A policy prohibits its use."

• Missing Implementation:

  • Example: "If a future requirement necessitates its use, a detailed plan, including sanitization, must be created."

Mitigation Strategy: Secure Context API Usage (Preact Specific)

• Description:

  1. Context Scope Limitation: Identify the Preact components that need access to data. Create a context provider only at the highest level in the Preact component tree where all those components are descendants.
  2. Multiple Contexts: Create separate Preact contexts for different data categories.
  3. Data Minimization: Store only the minimum necessary data within each Preact context.
  4. Read-Only Context (If Possible): If a Preact context only needs to provide data, consider making it read-only.
  5. Code Reviews: Examine how Preact's Context API is being used during code reviews.
  6. Documentation: Clearly document the purpose and scope of each Preact context.

• Threats Mitigated:

  • Unintentional Data Exposure (Preact Specific): (Severity: Medium to High) - Prevents sensitive data from being accidentally accessed by Preact components that shouldn't have access.
  • Debugging-Related Leaks: (Severity: Low to Medium)
  • Component Injection (Indirectly - Preact Specific): (Severity: Low) If a malicious component is injected, limiting Preact context access reduces data exposure.

• Impact:

  • Unintentional Data Exposure: Risk reduction: High.
  • Debugging-Related Leaks: Risk reduction: Medium.
  • Component Injection (Indirectly): Risk Reduction: Low.

• Currently Implemented:

  • Example: "Separate Preact contexts are used for authentication (AuthContext) and UI theme (ThemeContext). AuthContext only provides a user ID."

• Missing Implementation:

  • Example: "Code review needed to ensure all Preact context providers are at the appropriate level. Documentation for AnalyticsContext needs clarification."