Skip to content

Security: arth2o/secure-todo-app

Security

SECURITY.md

Security Policy

This is a client-side encrypted todo app. All data lives in the user's browser (IndexedDB), so the security model is mostly local to each install — there is no central server to compromise. Still, a vulnerability in the client (XSS, key-derivation flaw, accidental data exposure to a remote endpoint, etc.) would matter a great deal to every user.

Supported Versions

Version Supported
latest
older

Only the latest commit on the main branch receives security fixes. If you are running anything older, please update first.

Reporting a Vulnerability

Please do not open a public GitHub Issue for security bugs.

Preferred (private) channel — pick whichever you are comfortable with:

  1. GitHub Security Advisories (recommended) Open a private report at: https://github.com/arth2o/secure-todo-app/security/advisories/new This is the default private channel and does not require any extra setup. Reports stay between you and the maintainers until published.

  2. Email — for sensitive issues where GitHub is not appropriate: wand-mom-tumbling@duck.com (PGP key on request.)

What to include

  • A short description of the issue and the impact you observed.
  • Steps to reproduce, ideally with a minimal snippet or a forked repo.
  • Affected commit SHA / release tag, if known.
  • Anything about your environment that matters (browser, OS).
  • Do NOT include real passwords or production workspace data. Reproduction data should be synthetic.

What to expect

  • Acknowledgement: within 3 business days.
  • Triage update: within 7 days — confirmation, severity, and whether the report is in scope.
  • Fix / disclosure timeline: agreed with you, typically 90 days from report. Critical issues are fast-tracked.
  • Credit: with your permission, you will be credited in the advisory and in the release notes.

Scope

In scope

  • Anything that breaks the client-side encryption guarantees: wrong key derivation, predictable IV/salt reuse, AES-GCM auth-tag bypass, plaintext leakage to console/network, weak default parameters.
  • Cross-site scripting (XSS) or other code-injection vectors that could read user data from IndexedDB or sessionStorage.
  • Bypassing the workspace isolation between UUID endpoints (e.g. one workspace accessing another workspace's encrypted data).
  • Authentication / session issues (e.g. password verification accepting an empty/wrong value, redirect loops exposing URLs).
  • Any unintended network request that exfiltrates user-supplied data to a third party.

Out of scope

  • Vulnerabilities in dependencies that are already fixed upstream and we are running on the latest version. Open it there.
  • Reports against a fork / build that has been modified from this repo.
  • "The encryption could be broken if the user uses a weak password" without a concrete attack beyond brute force.
  • Theoretical findings without a proof-of-concept.
  • Missing security headers on local dev (npm run dev) — those apply only to the production build.

Security Best Practices for Users

Because the threat model is "anything on your device can read your data":

  • Use a strong, unique password (12+ chars, mixed character types). There is no recovery if you forget it.
  • Bookmark your unique workspace URL (/app/<uuid>); don't share it casually — anyone with the URL only needs the password.
  • Export backups regularly (Settings → Data Management → Export).
  • Don't paste your password into untrusted clipboard managers; the app intentionally trims it from in-memory state when you log out, but browser extensions are outside our control.
  • Clear browser data = lose tasks. Use the Export feature, not the dev tools IndexedDB panel, when moving between browsers.

Acknowledgements

Thank you to everyone who reports issues responsibly. Reporters who consent to being credited will be listed in the relevant GitHub Security Advisory and in the release notes of the patch release.

There aren't any published security advisories