Skip to content

Security: mdruhankarim/NoteHand

Security

SECURITY.md

Security Policy 🛡️

We take the security of NoteHand seriously. This document outlines our security policies, how to report vulnerabilities, response expectations, and our disclosure policy.


Supported Versions

Only the latest release version of NoteHand is actively supported with security updates.

Version Supported
v1.0.x ✅ Yes
v0.1.x ❌ No
< v0.1.0 ❌ No

🔒 Built-in Security Features

NoteHand implements defensive programming practices to protect user data:

  1. SVG & Media Sanitization (src/security/sanitizer.ts): Any user-imported SVG, dropped image, or pasted file undergoes validation. SVGs are parsed through a strict HTML parser and purified using DOMPurify. Elements such as <script>, <iframe, <object>, <embed>, <foreignObject>, inline event handlers (e.g., onclick, onload), and javascript: protocol links are completely stripped.
  2. Input Schema Validation (src/security/validation.ts): LocalStorage data is run through Zod schemas before being hydrated into memory. Stale, invalid, or corrupted objects are rejected, protecting the application state from local database manipulation.
  3. Strict Content Security Policy (CSP): Configured in vite.config.ts (dev) and netlify.toml/public/_headers (prod). This restricts script sources, styles, fonts, and connections to trusted domains, mitigating Cross-Site Scripting (XSS) risks.
  4. Sandbox Controls: Simulated virtual container terminals operate strictly inside client-side JS sandboxes. They do not run actual local system bash processes, preserving sandbox containment.

📢 How to Report a Vulnerability

If you discover a security vulnerability in NoteHand, please do NOT open a public issue. Doing so exposes the exploit to the public before a patch is ready.

Instead, please report security issues through one of the following methods:

  1. GitHub Private Vulnerability Reporting: Submit a draft advisory privately via the "Security" tab of our repository if you have access.
  2. Email: Contact the maintainer at karimmdruhan@gmail.com with the details of your findings.

Please include the following information in your report:

  • A descriptive title and type of vulnerability (e.g. XSS, remote execution bypass).
  • A detailed description of the vulnerability and its potential impact.
  • Step-by-step instructions to reproduce the issue (PoC script, screens, or test files).

⏱️ Response Expectations

  • Acknowledgement: We will acknowledge receipt of your report within 48 hours.
  • Investigation: We will investigate and confirm the vulnerability within 5 business days.
  • Triage & Patching: For confirmed vulnerabilities, we aim to produce a patch within 14 business days and coordinate a release.

📢 Disclosure Policy

We follow a coordinated disclosure model:

  • Maintain confidentiality of the report until the patch is released.
  • Release a security advisory along with the patched version.
  • Credit you for finding the vulnerability (unless you request anonymity).

There aren't any published security advisories