🛡️ Sentinel: Security hardening

[iamedwardngo]

Summary

• Describe the user-facing or operational change.

Related Issues

• Closes #
• Related to #

Validation

• npm run lint
• npm run test:unit
• npm run test:coverage
• Coverage is still >= 60% for statements, lines, functions, and branches
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Tests Added Or Updated

• List every changed or added automated test file.
• If no production code changed, state that here.

Coverage Notes

• If this PR changes src/, open-sse/, electron/, or bin/, explain which tests cover the change.
• If coverage moved down in any touched file, explain why and what follow-up task will recover it.

Reviewer Notes

• Call out any risky areas, migrations, feature flags, or manual validation that reviewers should know about.

[gemini-code-assist]

Code Review

This pull request introduces server-side HTML sanitization for documentation rendering using DOMPurify and JSDOM, along with corresponding unit tests for sanitization and path traversal regexes. The review feedback highlights a security risk in the sanitizer configuration where allowing <input> tags and associated attributes could lead to phishing or UI redressing, as well as the inclusion of non-standard HTML tags. Additionally, the path traversal tests incorrectly validate local regex definitions rather than production code, violating the repository style guide which mandates using Zod schemas from src/shared/validation/schemas.ts for input validation.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Allowing the <input> tag along with attributes like type, name, checked, and disabled introduces a potential security risk (Stored XSS / Phishing / UI Redressing). An attacker could inject malicious input fields (e.g., text or password inputs) to harvest credentials or mislead users. Additionally, "nl", "te", and "bw" are not standard HTML tags and appear to be typos.

Recommendations:

1. Remove "input" from ALLOWED_TAGS and "type", "checked", "disabled" from ALLOWED_ATTR if they are not strictly required.
2. If task lists (checkboxes) are required, use a DOMPurify hook (e.g., uponSanitizeElement) to strictly enforce that any <input> element has type="checkbox" and disabled attributes, stripping any other input types.
3. Remove the non-standard tags "nl", "te", and "bw".

    ALLOWED_TAGS: [
      "h1", "h2", "h3", "h4", "h5", "h6", "blockquote", "p", "a", "ul", "ol",
      "li", "ins", "del", "em", "strong", "span", "hr", "br",
      "div", "table", "thead", "caption", "tbody", "tr", "th", "td", "pre",
      "code", "img", "details", "summary"
    ],
    ALLOWED_ATTR: [
      "href", "name", "target", "src", "alt", "title", "class", "id", "rel"
    ],

[gemini-code-assist]

There are two issues with this implementation:

1. Testing Local Definitions: The test defines LOCALE_REGEX and SLUG_REGEX locally within the test file. This means the test is only validating its own local regexes rather than the actual regexes used in the production code (e.g., in the page component), which defeats the purpose of unit testing.
2. Style Guide Violation: According to the Repository Style Guide (Rule 8), all inputs must be validated using Zod schemas from src/shared/validation/schemas.ts. Instead of using custom regexes, you should define and export Zod schemas for the locale and slug in src/shared/validation/schemas.ts, and import them here and in the production code for validation.

References

1. Always validate inputs with Zod schemas from src/shared/validation/schemas.ts.