Reporting a security problem

Reporting and the period before disclosure

• Send the report privately through the contact page, marked as a security report, rather than posting it publicly or opening a public issue.
• Describe what you found and how to reproduce it: the address, the steps, and what you expected instead. A report that can be reproduced gets fixed.
• Report the smallest detail needed. Do not include personal data belonging to anyone else in the report.
• Ask for a disclosure date if you intend to publish. Ninety days from a report is a reasonable default and is accepted here.
• Expect a direct reply, including when the report is a misunderstanding or describes intended behaviour. A substantive answer is the goal, not a form letter.

What good-faith research means

• Test only against your own accounts, your own inputs and your own devices, and only on the site itself.
• Do not access, modify, delete or exfiltrate data belonging to anyone else. If you reach data that is not yours, stop and report without copying it.
• Do not degrade the service: no denial-of-service, no high-volume automated testing and no attempts to exhaust resources.
• Do not use social engineering against the operator, the hosting provider or any third party to obtain access.
• Do not publish anything about the finding before the agreed period has passed, and never publish material that could be used against users.

Research that follows these rules is treated as a good-faith report rather than an attack, and the operator will not pursue legal action over it. Step outside them — particularly by accessing other people's data or disrupting the service — and that position does not apply.

Scope, and where a report should go instead

• In scope: the site itself, its pages, headers, and the configuration served with the static files.
• In scope: a flaw that could expose what a user types, or make a result misleading in a way that could cause harm.
• Out of scope: the underlying platform and its libraries, which should be reported upstream. Reports here are forwarded rather than fixed locally.
• Out of scope: the breach-checking service and the hash-range password service, which have their own reporting processes.
• Not a vulnerability: missing features, the absence of an account system, the lack of continuous monitoring, or a page stating a limit that is already documented in the reports.

There is no bug bounty programme and no payment for reports. Saying so before you spend time is fairer than implying otherwise.