Security & Vulnerability Disclosure

Last updated: 8 April 2026

TriageHealth processes sensitive health data on behalf of individual users. We take that responsibility seriously and we welcome reports from security researchers. This page is also published in machine-readable form at /.well-known/security.txt.

How to report

Send vulnerability reports to info@triagemethod.comwith the subject line “Security report”. Please include as much of the following as you can:

• A clear description of the issue and the impact you believe it has
• Steps to reproduce (URLs, payloads, request bodies, screen recordings if helpful)
• The date and time you tested, so we can correlate with our logs
• Whether the issue has been disclosed to anyone else
• How you would like to be credited (or not credited) in our acknowledgements

Our response commitments

TriageHealth is operated by a small team. We aim to acknowledge reports within 5 business days, confirm our assessment within 10 business days, and ship a fix as quickly as the severity warrants. For critical issues we will prioritise the fix and keep you updated on progress; for lower-severity issues we will let you know our expected timeline when we triage.

Scope

In scope:

• The production application at www.triagehealth.com and triagehealth.com
• The marketing site at triagemethod.com
• Any dependency vulnerability that materially affects the above

Out of scope (please do not test):

• Denial-of-service attacks — we'd rather you tell us about a weakness than prove it by knocking us offline
• Social engineering of our team or our users
• Physical attacks against our infrastructure
• Spam or content-injection in user-controlled fields that has no security impact
• Issues that require a fully compromised end-user device to exploit
• Missing security headers that have no demonstrated impact — if you find a real bypass, that is in scope
• Self-XSS that requires the victim to paste attacker-controlled code into a console
• Vulnerabilities in third-party services we rely on — please report those to the vendor directly

Safe harbour

If you make a good-faith effort to comply with this policy, then to the extent permitted by applicable law we will:

• Not pursue or support any legal action against you in connection with your research
• Work with you to understand and resolve the issue
• Recognise your contribution publicly, with your permission, once a fix has shipped

“Good-faith effort” means:

• Only test against your own account or accounts you have explicit permission to test
• Do not access, modify, or delete data belonging to other users
• Do not exfiltrate any user data beyond what is necessary to demonstrate the issue — redact any personal information in screenshots and reports
• Stop testing as soon as you discover the issue and report it
• Give us a reasonable opportunity to investigate and fix the issue before public disclosure

Our security posture

At a high level, TriageHealth is built with the following controls in place:

• All traffic is served over TLS with HSTS enforced
• Health data is encrypted at rest by our managed database provider
• Secure, HTTP-only session cookies with CSRF protection on mutating endpoints
• Rate limits on authentication and cost-bearing endpoints
• Audit logging of sensitive operations
• GDPR Article 17 (right to erasure) implemented end-to-end
• Point-in-time database recovery and a documented disaster recovery runbook tested on a regular cadence
• Strict Content-Security-Policy and other hardening response headers (X-Frame-Options, COOP, CORP, Permissions-Policy)
• Automated dependency auditing and secret-scanning on every change

We intentionally do not publish a detailed technical inventory of our infrastructure on this page. If you need more information to assess a specific risk, mention it in your report and we will share what we can.

Acknowledgements

Researchers who have helped us harden TriageHealth (with their permission) will be listed here.

None yet — be the first.