This document is written in plain English. If anything is unclear, contact [email protected].
In short: If you find a security weakness in VipLIMS, email [email protected]. Do not access other laboratories' data, do not disrupt the service, and do not try to trick people. If you act in good faith and follow this policy, we will not take legal action against you. We acknowledge reports within 3 working days. We do not currently offer a bug bounty.
Version 1.0. Effective date: 13 October 2026.
1. Why this policy exists
VipLIMS holds laboratory and patient data for laboratories around the world. We welcome reports from anyone who finds a weakness, and we want reporting it to be simple and safe.
2. How to report
2.1 Email [email protected]. The same contact, together with a link to this policy, is published in machine-readable form at /.well-known/security.txt, following RFC 9116. If the two ever differ, security.txt is correct.
2.2 We do not currently publish an encryption key. If your report includes sensitive detail, send a short first message without it, and we will arrange a secure way to share the rest.
2.3 Please include:
- a description of the issue and the impact you think it has;
- the steps needed to reproduce it, including any URLs, requests or screenshots;
- the date and time you tested, and the account you used;
- how you would like to be credited, if at all.
2.4 Please do not include real patient data in your report. If you came across any, tell us what kind of data it was and where, without copying it.
3. Scope
| In scope | Out of scope |
|---|---|
| The VipLIMS app and its API at viplims.com/app and viplims.com/api | Third-party services we use, such as Cloudflare, Google, Stripe and PayPal; report issues to them directly |
| The public website at viplims.com | Denial-of-service and load testing |
| Sign-in, two-step verification and session handling | Social engineering, phishing or physical attacks against our staff, users or providers |
| Separation between laboratories | Reports from automated scanners without a demonstrated impact |
| Encryption, access control and the audit trail | Missing best-practice headers or settings with no realistic security impact |
| Report generation, exports and file uploads | Issues that need an already compromised device or browser |
4. Rules for testing
To stay within this policy, you must:
- use only accounts you created yourself, for example a test laboratory signed up for this purpose with synthetic data only;
- never access, change or delete data belonging to another laboratory. If you find you can reach another laboratory's data, stop immediately, do not look further, and report it;
- not carry out denial-of-service attacks or any testing that degrades the service for others;
- not use social engineering, phishing or physical access;
- not use automated tools at a volume that affects other users;
- keep any data you obtain confidential, and delete it once you have reported the issue;
- give us a reasonable time to fix the issue before disclosing it to anyone else.
5. Safe harbour
5.1 If you make a good-faith effort to follow this policy, we will:
- consider your research authorised by us, including for the purposes of the Computer Misuse Act 1990;
- not take legal action against you, or report you to law enforcement, for that research;
- work with you to understand and fix the issue quickly.
5.2 If a third party takes legal action against you for activity that followed this policy, we will make it known that your actions were authorised by us.
5.3 This safe harbour does not cover activity that breaks the rules in section 4, that causes harm, or that breaks the law in a way we cannot authorise. We cannot authorise testing of systems that belong to others.
6. What you can expect from us
| Step | Our commitment |
|---|---|
| Acknowledgement | Within 3 working days of your report |
| Initial assessment | Within 10 working days: whether we can reproduce the issue and how serious we think it is |
| Updates | We keep you informed while we work on a fix, at least every 30 days |
| Fix and disclosure | We tell you when the issue is fixed and agree a disclosure date with you. Unless we agree otherwise, we ask you to wait until it is fixed or 90 days after your report, whichever is sooner |
| Credit | With your permission, we thank you by name in the changelog |
If the issue affects laboratory data, we will also meet our obligations to notify affected laboratories under our Data processing agreement.
7. Rewards
We do not run a bug bounty and cannot pay for reports. We are grateful for every responsible report and will credit researchers who want it.
8. Related information
- How we protect data: Trust
- Rules for all users: Acceptable use policy
- Service incidents: Status
- How we handle the personal data in your report: Privacy policy