Vulnerability Disclosure Policy

HoneyDolly welcomes reports of genuine security vulnerabilities. This page sets out how to report one, what we consider in scope, and the terms under which a reward may be paid. It is the only statement of those terms; anything said elsewhere does not override it.

How to report

Send your report to security@honeydolly.com. A useful report contains:

1. The affected URL, endpoint, or feature.
2. Step-by-step instructions to reproduce the issue.
3. A proof of concept, and a description of what an attacker can actually achieve.
4. Any accounts, IP addresses, or timestamps you used, so we can match your testing against our logs.

We aim to acknowledge reports within five working days.

Scope

In scope: honeydolly.com, its subdomains, and the HoneyDolly API.

The following are not accepted as qualifying vulnerabilities. They are frequently produced by automated scanners and, on their own, do not demonstrate a security impact:

• Missing or misconfigured HTTP headers (including X-Frame-Options, Content-Security-Policy, and Referrer-Policy) without a working attack that uses their absence.
• Clickjacking on pages that do not perform authenticated state-changing actions.
• Raw output from automated scanners, with no proof of concept.
• Self-XSS, or issues that require the victim to paste code into their own browser.
• Missing rate limits, absent a demonstrated impact.
• SPF, DKIM, DMARC, or other DNS configuration opinions.
• Reports of outdated software versions without a working exploit against our deployment.
• Social engineering of our staff or users, physical attacks, and denial-of-service or volumetric testing.
• Vulnerabilities affecting only unsupported or end-of-life browsers.

Rules for testing

While researching, you must not:

• Access, modify, or delete data belonging to any account other than your own test accounts.
• Extract or retain personal data. If you encounter it, stop and tell us immediately.
• Degrade, disrupt, or overload the service, or run denial-of-service tests.
• Use social engineering against our staff, users, or suppliers.

Use your own test accounts. If demonstrating an issue genuinely requires more access than that, contact us first and we will arrange it.

Assessment and rewards

We pay rewards for vulnerabilities that we assess as critical. The following terms apply to every report:

• Severity is determined by HoneyDolly, based on demonstrated impact against our production configuration — not by the severity stated in the report, nor by a scanner’s rating. Our assessment is final.
• A report must be received and verified before any reward is considered. We do not make payments in advance of a report.
• We do not pay in exchange for non-disclosure. A reward recognises the work of finding and reporting an issue; it is not a payment for silence. Any report accompanied by a demand for payment as a condition of disclosure, or by a threat of publication, falls outside this policy and will be handled accordingly.
• Only the first report of a given issue is eligible. Duplicates, and issues already known to us or already scheduled for a fix, are not rewarded.
• One reward per underlying issue, regardless of how many endpoints or pages it affects.
• Reports that do not meet the criticality bar receive our thanks and, where warranted, a fix — but no payment.

Disclosure

Please give us a reasonable opportunity to remediate before publishing. We will not set an arbitrary embargo, and we will tell you when a fix has shipped. We ask only that you do not publish details that would put our users at risk while an issue is still exploitable.

Safe harbour

If you make a good-faith effort to follow this policy while researching, we will not pursue or support legal action against you in connection with your research, and we will treat your activity as authorised. If a third party brings action against you for research conducted within this policy, we will make that authorisation clear.