Coordinated vulnerability disclosure

Last updated: 3 June 2026

BookOS welcomes good-faith security research. This page describes how to report a suspected vulnerability in the BookOS platform and what to expect from us in return. The machine-readable version of this policy is published at /.well-known/security.txt per RFC 9116.

1. Scope

The following are in scope for testing:

• bookos.io and all *.bookos.io subdomains we operate;
• the BookOS REST API (under /api);
• customer subdomains that we host on behalf of salons (do not attempt to modify or exfiltrate live customer or end-customer data — create your own test tenant);
• our public OAuth and webhook endpoints.

The following are out of scope:

• third-party services we integrate with — please report those directly to their vendor (contact us if you need clarification on whether a system is in scope);
• denial-of-service, volumetric, or load testing of any kind;
• social engineering of BookOS staff, customers, or vendors;
• physical attacks on BookOS personnel or property;
• reports based solely on automated scanner output without a working proof of concept;
• self-XSS or vulnerabilities requiring an already-compromised browser, device, or account.

2. How to report

Email security@bookos.io. Where possible, encrypt sensitive payloads with our PGP key published at /.well-known/pgp-key.txt (coming soon). Please include:

• a clear description of the issue and its impact;
• step-by-step reproduction instructions and any required proof-of-concept code;
• the affected URL(s), endpoint(s), or component(s);
• your name or handle for credit (optional — you may remain anonymous).

3. Rules of engagement (safe harbour)

We will not pursue legal action against, or report to law enforcement, researchers who in good faith:

• make a good-faith effort to avoid privacy violations, destruction of data, and disruption to our service;
• use only test accounts and test data they themselves created;
• do not exfiltrate data beyond the minimum necessary to demonstrate the vulnerability;
• give us reasonable time to remediate before public disclosure (see Section 5);
• comply with this policy and with applicable law.

This safe-harbour statement does not waive third-party rights, and we cannot authorise actions against third-party systems. Always operate within the law of your jurisdiction.

4. Our commitments

• We acknowledge receipt of valid reports promptly.
• We provide an initial triage and severity assessment within a reasonable timeframe, typically within ten business days.
• We give credit (with consent) in our security acknowledgements page once the vulnerability is remediated.
• We do not currently operate a paid bug-bounty programme. We may offer swag or other tokens of appreciation at our discretion.

5. Coordinated disclosure timeline

We follow ISO/IEC 29147 coordinated-disclosure principles. We aim to remediate critical and high-severity issues within 30 days, and medium / low within 90 days. Please give us at least 90 days from initial report (or until a fix is deployed, whichever is sooner) before public disclosure. We are happy to coordinate joint disclosure and CVE assignment where appropriate.

6. Hall of fame

Researchers who have responsibly disclosed valid issues are credited here once their finding is remediated, with their consent. (No credits yet — you could be the first.)