Vulnerability disclosure policy

Our commitment to you

If you research our systems in good faith and within this policy, we consider your research authorised. We will not initiate legal action against you for it, we will not report you to law enforcement for it, and if a third party takes action against you for research conducted under this policy, we will make it known that your activity was authorised. We will work with you openly and treat you as a colleague, not a threat.

How to report

Email [email protected] with "Security" in the subject line. Please include:

• the URL or endpoint affected, and the steps to reproduce the issue;
• what you believe the impact is;
• any proof of concept, request and response captures, or screenshots that help us confirm it quickly;
• how you would like to be credited, if at all, and how we can reach you.

Our machine-readable contact details are published at /.well-known/security.txt.

What we will do

• Acknowledge your report within 2 working days.
• Assess it, keep you informed of progress, and tell you honestly whether we can reproduce it and how serious we think it is.
• Prioritise fixes by severity. Anything that could touch health information is treated as urgent.
• Tell you when the issue is fixed, and credit you publicly if you would like that.

We do not currently run a paid bug bounty programme, so we cannot offer monetary rewards. We can offer a fast, respectful response and public credit.

Scope

In scope:

• this website, booklab.co.nz;
• the booking platform at api.booklab.nz;
• booking pages operated by Book Lab on behalf of practices.

Out of scope:

• the practice management systems our platform connects to, and any other vendor's systems. They are not ours to authorise testing against; please report issues in those products to their vendors;
• the infrastructure of our providers (Microsoft Azure, Cloudflare, SMTP2GO) beyond how Book Lab has configured it. Each runs its own disclosure programme;
• denial of service or any volumetric testing;
• social engineering, phishing or physical attacks against Book Lab, our practices or their staff;
• reports from automated scanners without a demonstrated vulnerability, and findings about the presence of rate limiting, security headers or other controls working as intended.

Rules of engagement

The systems in scope process real appointment requests for real medical practices, so these rules matter more here than on most sites:

• Use invented details, never real patient information, anywhere a form is involved, and keep test submissions to the minimum needed to demonstrate the issue. Every junk booking that gets through is deleted by hand at a clinic's front desk.
• If you encounter personal or health information at any point, stop immediately, do not copy, store or share it, and tell us what you saw. That discovery is itself the finding.
• Do not access, modify or destroy data that is not your own, and do not pivot from an initial finding into further systems.
• Do not degrade the service for patients or practices.
• Give us a reasonable time to fix the issue before disclosing it publicly. We ask for up to 90 days, we will usually be far faster, and we will agree a disclosure date with you rather than leave you waiting.

Why this page exists

Book Lab's platform is deliberately built so that the worst realistic outcome of most attacks is a junk booking request, not a data breach: nothing is stored, and no endpoint returns patient information. We still assume we have made mistakes somewhere. Responsible disclosure is part of our security programme alongside continuous automated testing and independent review, and this policy is a standing invitation to help us find what we have missed.

This policy was last updated on 28 September 2026.