Vulnerability disclosure policy

If you have found a security problem in the platform, we want to hear about it
before anyone else does. Write to security@dfrds.com. This page is the
policy that /.well-known/security.txt points to.

What to send

Enough for us to reproduce it: the URL or endpoint, the steps, what you
expected and what happened, and the account you used if you had one. A proof
of concept is welcome; a working exploit against other people’s data is not
(see the next section). If you would like credit, say how you want to be
named.

We do not run a paid bounty programme. [REVIEW: whether to offer one.]

What we ask of you

• Test only against accounts you own, or on the sandbox at
  sandbox.dfrds.com, which is a full copy of the platform on its own
  database with payments switched off.
• Do not read, change or delete other people’s data, even if you can. If you
  reach it by accident, stop, note what you saw, and tell us.
• No denial of service, no social engineering of our staff or customers, no
  physical attacks.
• Give us a reasonable time to fix the problem before you publish anything:
  90 days from your report, or less if we agree it in writing.

Research that keeps to these rules is authorised. We will not pursue legal
action against you for it, and if a third party does, we will make clear that
you acted in good faith. [REVIEW: safe-harbour wording under the governing law.]

What you can expect from us

• An acknowledgement within 2 business days.
• An assessment and, where we agree it is a vulnerability, a target fix date
  within 10 business days.
• Updates when the fix ships, and credit on this page if you want it.
• No retaliation for a report made in good faith, including one that turns
  out to be a duplicate or not a vulnerability.

In scope

• dfrds.com and www.dfrds.com
• sandbox.dfrds.com
• The public API (/api/v1) and the MCP endpoint (/mcp)
• Email we send from dfrds.com

Out of scope

• Findings that need a compromised device or a stolen password
• Reports from automated scanners with no analysis
• Rate-limit or lockout thresholds themselves (report a bypass of them)
• Missing best-practice headers with no demonstrated impact
• Third-party services we use (Stripe, AWS, Google); report those to them

Acknowledgements

Nobody yet. Be the first.