Security & Responsible Disclosure

People trust HEAL with information about their recovery, so security is part of how we build every feature, not an add-on. We collect as little as we can, keep the most sensitive things sealed, limit who can reach what, and keep records of privileged access. This page describes the protections we have in place today. Where something is a plan rather than a fact, we say so. No system is perfectly secure, and we don’t claim certifications we don’t hold.

The website, member apps, API and staff console are served only over HTTPS, using TLS, so data moving between your device and HEAL is encrypted. Our API also sends standard security headers that tell browsers to apply additional protections, and only accepts browser requests from HEAL’s own web addresses.

Your workbook answers and the private notes on your mood check-ins are encrypted with AES-256-GCM, with a fresh random value for every record, before they are written to our database. The key is held only by the HEAL API and is never sent to apps, staff tools, logs or analytics. If someone obtained a copy of our database without the key, they would see only ciphertext.

This is not end-to-end encryption: the API holds the key so it can show you your own entries. Staff tools never retrieve workbook content, and it never appears in notifications, logs, analytics or background jobs. See our Law Enforcement Requests page for what this means for legal process.

Share links you create for chosen answers expire (after 7 days by default, and never more than 14), can be revoked at any time, and record how many times they were viewed.

• Hashed passwords. Accounts are managed with Better Auth. Passwords are stored only as salted one-way hashes — never in plain text — and must be at least 8 characters.
• Email verification. You must verify your email address before you can sign in. Changing your email requires a confirmation sent to your current address and a verification of the new one.
• Password reset works only through a single-use link sent to your verified email.
• Sessions last up to 30 days and are refreshed while you use HEAL. Signing out ends a session, and HEAL can end all of an account’s sessions, for example after a moderation action.
• Bot and abuse protection. Sign-up and password-reset requests are protected by Cloudflare Turnstile bot checks, account and other sensitive endpoints are rate-limited per network address, and we can block abusive network sources.

HEAL staff and trained volunteers use a separate staff console, not the member app. Access is role-based — administrator, moderator, reviewer and host — and each role can reach only the tools it needs. Authorization is checked on the server for every request, not just hidden in the interface, and members’ private records are invisible to other members.

Privileged actions, such as moderation decisions, account changes, provider review decisions and downloads of provider-review evidence, are recorded in an audit log of who did what and when. Staff tools are built so that they never select workbook answers or check-in notes.

Files that should never be public — such as evidence gathered when we review treatment providers, and attachments to bug and problem reports — are kept in private storage buckets, separate from the public bucket used for things like images on our website. Private files can only be opened by authorized staff through short-lived links, and every download of provider-review evidence is logged.

HEAL runs on US-based infrastructure from established providers, listed with what each one does on our Service Providers page. We give each provider only the data it needs. Secrets such as encryption keys and API credentials are kept in our hosts’ environment configuration, not in our source code.

• Rules that matter — such as who can approve a provider listing, or which steps a help request can move through — are enforced by the server and covered by automated tests.
• We aim to apply security updates to our software dependencies promptly, prioritizing known vulnerabilities by severity.
• We aim to review changes that touch authentication, authorization or sensitive data with particular care before release.
• We intend to commission independent security testing as HEAL grows, and to update this page when we do.

If we learn of a security incident, we will act to contain it, investigate what happened and what data was involved, fix the cause, and keep a record of the incident and our response. Where appropriate we will involve outside experts and law enforcement.

If a breach affects your information, we will tell you without unreasonable delay, explaining what happened, what information was involved, what we are doing and what you can do. We intend to meet or exceed the notification requirements that apply to us, including:

• the FTC Health Breach Notification Rule, which applies to many health apps that are not covered by HIPAA and requires notice to affected people, the FTC and in some cases the media, generally within 60 calendar days of discovery;
• state breach-notification laws in every state where affected members live, some of which set shorter deadlines or require notice to the state attorney general; and
• where they apply, the notification duties of the GDPR and UK GDPR, including notifying the relevant authority within 72 hours of becoming aware of a reportable breach.

We will notify you by email to the address on your account, and by a notice in the app or on this site where appropriate.

• Use a strong, unique password for HEAL — a password manager makes this easy — and don’t reuse a password from another site.
• Sign out when you use HEAL on a shared or public device, and don’t let the browser save your password there.
• Lock your phone and computer with a passcode, fingerprint or face unlock, especially if you use the mobile or desktop app.
• Be wary of messages asking for your password or sign-in links. HEAL will never ask for your password by email, phone or message.
• Think before sharing workbook pages: share links work for anyone who has them until they expire or you revoke them.

If you think someone has accessed your account, reset your password and tell us at support@teleheal.com.

We welcome reports from security researchers and anyone else who finds a weakness. Please email security@teleheal.com with:

• a description of the issue and the affected address, app or component;
• steps to reproduce it, including any proof-of-concept;
• the impact you believe it has; and
• how you’d like to be credited, if at all.

Please don’t include other people’s personal data in your report. If you need to share something sensitive, tell us and we will arrange an encrypted channel.

We plan to publish a machine-readable /.well-known/security.txt file pointing to this policy and contact address; until it is live, this page is the authoritative source.

In scope

• teleheal.com and www.teleheal.com (the website)
• app.teleheal.com (the member web app)
• api.teleheal.com (the HEAL API)
• admin.teleheal.com (the staff console)
• the official HEAL mobile apps for iOS and Android, and the HEAL desktop app

Out of scope

• services run by our providers (for example Vercel, Railway, Cloudflare, LiveKit, Resend, Expo or Google) — please report to them directly;
• denial-of-service or volumetric attacks, and findings that require them;
• social engineering, phishing or physical attacks on HEAL staff, volunteers, members or offices;
• reports from automated scanners without a demonstrated, exploitable impact;
• missing best-practice headers or settings without a demonstrated impact, clickjacking on pages with no sensitive actions, and self-XSS;
• rate-limit or brute-force findings that only show an attempt is possible, and issues that need a rooted or jailbroken device or an outdated browser.

• Test only with your own accounts. Create test accounts and use only those. Never access, change, download or delete another member’s data. If you accidentally see someone else’s data, stop, don’t keep a copy, and tell us immediately.
• No disruption. No denial-of-service, load testing, spam, or anything that degrades HEAL for members. Never join, disrupt or listen in on a live meeting you weren’t invited to.
• No social engineering of members, volunteers or staff, and no posting test content where real members will see it — especially on the help board.
• Go no further than you need. Use the minimum access needed to show the issue; don’t pivot to other systems or keep access open.
• Keep it confidential. Give us reasonable time to fix the issue before telling anyone else about it, and coordinate any public write-up with us.
• Follow the law. Comply with all applicable laws, and don’t test from a sanctioned country or on behalf of anyone who is.

If you make a good-faith effort to follow this policy, we will consider your research authorized. We will not bring legal action against you, or ask law enforcement to investigate you, for that research — including under the Computer Fraud and Abuse Act, the DMCA’s anti-circumvention provisions or similar state laws, or for breach of our Terms of Use to the extent those terms would otherwise prohibit the research. If someone else brings a legal claim over activity that followed this policy, we will make it known that your actions were authorized.

This safe harbor does not cover activity that breaks the rules above, harms members, or violates the law, and we cannot authorize testing of systems owned by others. If you’re unsure whether something is allowed, ask us first at security@teleheal.com.

We aim to:

• acknowledge your report within 3 business days;
• give you an initial assessment within 10 business days;
• keep you informed as we work on a fix, and tell you when it is resolved; and
• fix critical and high-severity issues as quickly as possible, normally within 30 days, and other issues within 90 days.

These are goals, not guarantees; we are a small team and will be honest with you if something takes longer. With your permission, we will thank you by name on a security acknowledgements page once the issue is fixed.

HEAL is a free community and does not currently offer payment or rewards for vulnerability reports. We hope to start a bounty program in the future and will update this page if we do. Please don’t make a report conditional on payment; demands for payment in exchange for not disclosing an issue are not good-faith research and are not covered by safe harbor.