BillKitSecurity
How to report a vulnerability in BillKit, what happens after you do, and the rules that keep good-faith research safe for you.
Reporting a vulnerability
Email security@billkit.eu. Do not open a public GitHub issue, post in a discussion, or email general support about a vulnerability: those are read by more people than need to see it.
A useful report has:
- what is affected: the host, endpoint, SDK and version, or CLI version;
- the steps to reproduce it, and the request ids (
X-Request-Id) of the requests involved; - what an attacker gains, as concretely as you can state it;
- whether you have shared it with anyone else, and any date you intend to publish.
Write in English. Send it unencrypted if that is what you have; do not hold back a report for want of a key.
What happens next
| Stage | Target |
|---|---|
| Acknowledgement | Within 3 business days of your report, from a person, with a reference for the thread. |
| Initial assessment | Within 7 business days: whether it reproduces, whether it is in scope, and a severity. |
| Updates | At least every 7 days while it is open, whether or not there is news. |
| Fix | Critical and high severity issues are worked on until fixed. The aim is a fix in production within 30 days of the assessment for those, and within 90 days for the rest. |
| Disclosure | Coordinated with you. Unless agreed otherwise, you are free to publish 90 days after your report or once a fix has shipped, whichever comes first. |
Business days are Monday to Friday, excluding public holidays. These are targets for a small team, stated so you can hold us to them; they are not a contractual SLA.
When a fix ships, it is recorded in the API changelog, or in the affected
package’s CHANGELOG.md and release notes, with credit to you if you want it. Where customer data
was exposed, affected account owners are notified directly, as data protection law requires.
Scope
In scope:
- the API at
api.billkit.eu, the console atapp.billkit.eu, the embedded checkout atjs.billkit.eu, the hosted billing portal (on BillKit’s domain or on a customer’s custom domain), and this site; - the six SDKs and the
billkitCLI, including the installers and the release signatures, in the versions that receive security fixes under the deprecation policy: the latest major version, and the previous major version for 12 months after a new major ships; - webhook signing and delivery.
Out of scope:
- Mollie, and any other third party BillKit uses. Report those to the vendor;
- denial of service, load testing, and anything else that needs a high volume of requests;
- social engineering, phishing and physical attacks;
- automated scanner output with no demonstrated impact, such as missing headers, TLS cipher preferences, or SPF and DMARC policy;
- vulnerabilities in a dependency with no path to exploitation through BillKit.
Safe harbour
If you act in good faith within the rules below, BillKit will not pursue or support legal action against you for your research, and will not report you to law enforcement. If a third party takes action against you for research that followed these rules, we will make it known that your activity was authorised.
The rules:
- Test only against accounts you created. Use test mode wherever the issue reproduces in it.
- Do not access, change or delete data that belongs to another account. If you reach some by accident, stop, do not keep a copy, and say so in your report.
- Do not move real money. Do not use payment details that are not yours.
- Stay inside the rate limits, and stop when asked.
- Give us a reasonable time to fix the issue before you publish it, as described above.
There is no bug bounty programme. Reports are thanked and, with your permission, credited, but not paid.