Find a hole. Tell us first.
We take this seriously enough to write the rules down. Safe harbor for good-faith research, a real triage clock, and credit when you find something we missed.
How to report
Two channels, both go to the same inbox:
- Use the structured form below — fills the fields we want, gives you a reference id, takes <2 min.
- Or email security@rexa.one. One thread per issue. Include endpoint + steps + impact + how you'd like credit.
Encrypted intake is on the roadmap; the PGP slot on security.txt will populate the moment we can guarantee the key is held in HSM-backed storage. Until then, send unencrypted reports — inbox is read by a small named set.
Safe harbor
We won't pursue legal action or law-enforcement referral against research that follows this policy in good faith. That means:
- You only test your own workspace and accounts you control.
- You stop and report the moment you can demonstrate impact — no exfiltration beyond minimal proof.
- You give us a fair chance to fix before disclosing publicly (see the timeline below).
- You don't degrade service availability for other customers (no DoS, no traffic amplification, no automated scanners that flood routes).
- You don't access, store, or share other customers' data — including incidentally exposed records. If you see something, document it briefly and stop.
Research that crosses these lines forfeits safe harbor — but we'll still talk before we escalate. The goal is fixed bugs, not body counts.
Scope
In scope
- rexa.one (marketing)
- app.rexa.one (customer app)
- staff.rexa.one (internal control plane)
- rexa-api.fly.dev / api.rexa.fly.dev
- iOS app — bundle id one.rexa.ios
- @rexa/* OSS packages on GitHub
Out of scope
- Sub-processors (Stripe, Klippa, PostHog, etc.) — report upstream.
- Denial-of-service, volumetric attacks, brute force at scale.
- Social engineering of staff, customers, or vendors.
- Physical access. Phishing against rexa.one mailboxes.
- Missing low-impact response headers (HSTS subdomains, X-XSS-Protection).
- Self-XSS, CSV injection in customer-uploaded files.
- Outdated software disclosure without a working exploit chain.
Triage clock
Business days, Amsterdam time. The first two apply to every report; the fix targets scale with severity.
| Step | Target |
|---|---|
| Acknowledgment | ≤ 1 business day |
| Triage + severity assigned | ≤ 5 business days |
| Fix · Critical (CVSS ≥ 9.0) | ≤ 7 days |
| Fix · High (CVSS 7.0–8.9) | ≤ 30 days |
| Fix · Medium (CVSS 4.0–6.9) | ≤ 90 days |
| Fix · Low (CVSS < 4.0) | Next available window |
| Public disclosure | By default, after fix ships + 14d. Earlier on request. |
If we miss a target, we'll tell you why and when the new ETA is. If we're silent past the SLA you can disclose; we'd rather you ping us first.
Severity rubric
We score using CVSS v3.1 base. Examples are illustrative, not exhaustive.
Cross-tenant data read or write · auth bypass · RCE on the API or workers · master-key disclosure · live PAN exposure (we don't store PANs but if you find one, it's a critical).
Vertical privilege escalation within a tenant · sensitive data leak (receipt content, audit log) · session fixation · pre-auth SSRF · admin-role takeover via single user action.
Stored XSS scoped to one user · IDORs disclosing non-sensitive metadata · CSRF where state-changing actions lack origin checks · authenticated SSRF to internal-but-low-impact endpoints.
Reflected XSS requiring unusual user behaviour · missing rate limits on non-cost-bearing routes · information disclosure where the info wasn't sensitive.
Rewards
Rexa is small and self-funded. The honest version of the rewards story:
- Public credit on the researcher acknowledgments page for any valid in-scope report.
- Swag (sticker pack + a T-shirt we'll print just for finders) shipped within a month of the fix landing.
- Cash bounties begin once we cross 100 paying workspaces. The bounty table will be published here when it lands; in the meantime, we'll log every valid report and the first cohort of researchers gets prioritised when bounties go live.
- For Critical issues, we will negotiate a one-off reward immediately, regardless of the paying-workspace count. We don't want bystanders carrying our urgency.
What we'll do
- Acknowledge your report by name within one business day.
- Tell you the assigned severity and engineer when triage lands.
- Share the fix PR (or a short technical write-up if the PR would leak details).
- Credit you on the researcher page, at the severity you reported, with the handle you chose.
- Publish a brief root-cause + remediation note on the security blog for High and Critical fixes, with your write-up linked if you publish one.
Report a vulnerability
Anything you submit lands in the security inbox with your email as Reply-To, so the triage thread is yours from the first response. Five reports per hour per IP — generous for honest research, tight enough to keep noise out.
Last updated
This policy is revised whenever we ship a meaningful change to scope, SLAs, or rewards. The version live above is from 2026-05-19. Past revisions are tracked in git at apps/web/src/app/security/disclosure/page.tsx.