Security policy

How to report a vulnerability

Email us at security@myhealthjournal.co.uk with:

• A description of the issue
• Steps to reproduce, in enough detail that we can verify the issue
• The impact you believe it has (data exposure, account takeover, etc.)
• Any relevant logs, screenshots, or proof-of-concept code
• Your name or handle if you'd like credit; or "anonymous" if you'd prefer not

You may also use the machine-readable version of this policy at /.well-known/security.txt (per RFC 9116).

What we'll do

• Acknowledge your report within 72 hours
• Provide a substantive response within 7 days — confirmation, pushback if we don't believe it's exploitable, or a fix timeline
• Keep you informed as we investigate and fix
• Credit you publicly (on this page) once the fix is shipped, if you wish
• Not pursue legal action against good-faith researchers working within these terms

Scope

The following are in scope for vulnerability reporting:

• The main application: myhealthjournal.co.uk and medlog-production-fbb2.up.railway.app
• The API at /api/*
• Authentication, session management, and authorization flows
• Encryption-at-rest implementation
• Any way for a user to access another user's data
• Any way to bypass our rate limits or CSRF protections
• Code injection, XSS, SQLi, SSRF, RCE
• Vulnerabilities in third-party dependencies we use

The following are out of scope:

• Reports based purely on automated scanner output without proof of exploitation
• Missing security headers that don't lead to exploitation (we know — we'll fix as we have time)
• Email configuration issues (SPF/DKIM/DMARC) — these are managed by our email provider
• Social engineering against staff, suppliers, or users
• Physical security
• Denial of service attacks of any kind — please don't run them; just describe the theoretical attack
• Issues only exploitable on outdated browsers
• Self-XSS or attacks that require the victim to paste code into their own console
• Vulnerabilities in subprocessors (Railway, Resend) — report directly to them

Rules of engagement

To stay protected by this policy, please:

• Don't publicly disclose the issue before we've had a chance to fix it. We'll coordinate timing with you.
• Don't exploit beyond what's needed to demonstrate the issue. If you can read another user's data, demonstrating with one record is enough — don't enumerate the whole database.
• Don't access, modify, or destroy other users' data. If you can show a vulnerability with a test account you control, do that.
• Don't run automated scans that affect performance for other users.
• Don't use phishing, social engineering, or physical attacks.
• Use a throwaway account for testing where possible — let us know the email so we can clean it up after.

Rewards

This program does not currently offer monetary rewards. As we grow, we may introduce a bug bounty — until then, we offer recognition and our genuine thanks.

Hall of fame

Researchers who have responsibly disclosed vulnerabilities to us:

No public disclosures yet. You could be first.

Contact

Security reports: security@myhealthjournal.co.uk
General inquiries: [contact email to be added before launch]