Thank you for looking. This is a health tool, so a bug here can expose something a person would never choose to publish.

Use Report a vulnerability on this repository. That opens a private thread with the maintainer. Nobody else can read it, and it stays private until there is a fix to publish.

If you can't use GitHub, email the maintainer at brad@drstanfield.com. This is also the security contact for automated scanning reports.

Please do not open a public issue for a security problem. A public issue is a working set of instructions for anyone who reads it first.

A report needs the behaviour, not your record. Describe what you did, what happened, and what you expected. If a value is essential to the reproduction, use an invented one. The same rule applies to file names, which often carry a person's name and a clinic's.

The code in this repository: the browser widget, the server routes under app/, the shared logic in packages/health-core/, the command line tools in tools/, and the hosted connector at mcp.drstanfield.com.

Particularly interesting:

• Anything that lets one person read or write another person's record.
• Anything that puts a health value somewhere it should never be: a log, an error report, a public GitHub issue, an analytics counter.
• Anything that gets a request past the connector's consent screen, its origin check, or its per-connection limits.
• Anything that lets text written by a user become an instruction rather than data.

Out of scope: the Shopify storefront theme, third-party services we do not run, and reports produced solely by an automated scanner with no working reproduction.

One person maintains this. You should get a first reply within a few days. If the report is valid, the fix, the release, and the credit are all worked out with you in the private thread before anything is published. You are welcome to be named or to stay anonymous.

Health data lives in the user's own storage, not on our server. There is no server-side health database, and no API that stores a health record. If you find something that contradicts that, it is a security problem even if nothing crashed.

What the server does hold is operational, and some of it is free text a person typed, so it is worth naming rather than summarising: chat messages on the stored surfaces, kept 30 days and then blanked; anonymous product counters with no free text; reminder rows tying an email address to screening labels and due dates; feedback submissions with an email and a message; guest chat sessions; audit logs. A chat message in a health app can be a health value, which is why the main widget stores none at all.

Architecture: CLAUDE.md and docs/reference.md. What is stored and why, in the user's own words: https://drstanfield.com/pages/connector-privacy.