Trust & policies
Security Policy & Responsible Disclosure
Last updated: 2026-09-18 · Effective: 2026-09-18 · Version 1.1.
Report a vulnerability
Email security@reservory.com to report a vulnerability. Encrypt sensitive findings with our PGP key at /.well-known/pgp-key.txt.
Acknowledgement within 2 business days. Triage outcome within 5 business days.
1. In scope
- Production
reservory.comand all*.reservory.comsubdomains. - The booking widget served from our CDN (
widget.js) and embed targets. - The Reservory JS SDK and any published npm package under the
@reservoryscope. - Public REST API endpoints under
/api/*(operator and anon-callable surfaces).
2. Out of scope
- Third-party services we rely on — report directly to them:
- Stripe: contact Stripe directly.
- Supabase → security@supabase.com
- Vercel: contact Vercel directly.
- Social engineering of employees, contractors, customers, or operators.
- Denial-of-service (volumetric, rate-limit exhaustion, resource exhaustion).
- Automated scanner output without a working proof-of-concept.
- Issues requiring physical access, rooted/jailbroken devices, or attacker-controlled MITM.
- Missing best-practice headers (HSTS preload, CSP nuances) without an exploitable impact.
- Self-XSS, clickjacking on pages without sensitive actions, and known browser issues.
3. What we're looking for
High-impact findings that align with our threat model:
- Tenant isolation bypass — cross-tenant data read or write, RLS evasion, JWT confusion.
- Authentication / authorization bypass — operator role escalation, session fixation, token leak.
- Billing tier evasion — accessing paid features from a free tenant, gift-card double-redeem, refund-without-charge.
- Server-side request forgery (SSRF), especially through webhook URLs or integration callbacks.
- Remote code execution in our hosted environment.
- SQL injection or RLS-policy logic flaws.
- Stored or reflected XSS in the dashboard or widget.
- Booking concurrency exploits — overbooking, hold-confirm races, capacity bypass.
4. Disclosure timeline
We follow a coordinated 90-day disclosure window from the date of triage confirmation. We may request an extension with mutual agreement if the fix has cross-system implications (e.g. a database migration affecting all tenants). We will not seek indefinite embargoes.
Researchers may publish their findings after the 90-day window or after we've confirmed the fix is live, whichever comes first. We'll credit you on our acknowledgments page unless you prefer to stay anonymous.
5. Safe harbor
We will not pursue legal action against researchers who, in good faith:
- Test only against accounts and tenants they own or are authorized to access.
- Stop testing and report immediately upon discovering cross-tenant data exposure.
- Make a good-faith effort to avoid privacy violations, data destruction, and service disruption.
- Do not exfiltrate, retain, or share data beyond what is strictly necessary to demonstrate the issue.
- Give us a reasonable window to remediate before public disclosure.
We consider activity under this policy to be authorized, and we will work with you to quickly resolve any unintentional violations. If a third party initiates legal action against you for activity that complied with this policy, we will make it known that your actions were authorized.
6. Testing restrictions
- Do not test against operator tenants you don't own. Use a free-tier sandbox tenant.
- Do not place real bookings against operators' live calendars.
- Do not run automated scanners that generate > 5 req/sec against production.
- Do not exploit a finding beyond the minimum proof-of-concept.
7. Contact
security@reservory.com · PGP at /.well-known/pgp-key.txt · machine-readable policy at /.well-known/security.txt.