This page says how to report a security problem in Beloplan, what you can expect from us, and the rules we ask good-faith researchers to follow. Reports are welcome from anyone, customer or not.
Reporting
How to report a vulnerability#
Write to security@beloplan.be. The same address, with our policy and the languages we read, is published in machine-readable form in security.txt.
Please do not use the support address for this, and do not post the details publicly before we have had a chance to fix the problem.
What to include
- What the problem is, and where it is: the address of the page or endpoint, and the product (web application, phone app or API).
- The steps to reproduce it, or a proof of concept that works. A short working demonstration is worth more than a long description.
- What an attacker could do with it, as far as you could establish without going further than these rules allow.
- The time you tested, and the address you tested from, so we can find it in our logs.
- How we can reach you, and whether you want to be named when the problem is fixed.
Our response
What you can expect from us#
- We acknowledge your report within one working day.
- We keep you informed until the problem is fixed, including when we cannot reproduce it or do not think it is a vulnerability, and why.
- We ask for coordinated disclosure: please give us reasonable time to fix the problem before you publish anything. Our default is 90 days from your report. If we need longer, or you have a reason to publish sooner, we will agree a date together.
Good faith
Research in good faith#
Good-faith security research is welcome. We will not take legal action against a good-faith report that follows these rules:
- Do not access or change other people’s data beyond what is needed to show the problem. Use an account of your own.
- Do not carry out denial-of-service attacks or anything that degrades the service for others.
- No social engineering of our staff or customers, and no physical attacks.
- Do not send spam, or use a vulnerability to send messages to people.
- If you reach personal data, stop, and tell us. Do not keep, copy or share it.
Out of scope
What we do not treat as a vulnerability#
These are examples of reports that we will usually close without a fix:
- A missing best-practice header with no demonstrated impact.
- The raw output of an automated scanner without a working proof that the problem can be exploited.
- Self-XSS, where the only person who can be attacked is the one who typed the payload.
- Clickjacking on a page that has no sensitive action to trigger.
Rewards
No bug bounty#
We do not currently pay rewards for reports. We can thank you by name, with your permission, and we will tell you when the problem is fixed.
Incidents
Security incidents that affect customers#
If a security incident affects our customers, we tell the affected customers, and we tell the authorities as the law and our Peppol obligations require. Planned maintenance and incidents are announced on the status page.