Vulnerability disclosure policy

How to report a vulnerability

Email [email protected]. It is the only dedicated address, and it is also published in machine-readable form in our security.txt file.

Please do not use sales support, the contact form or social media for a security issue: those channels are read by people who cannot act on it, and a report waits there far longer than it should.

Scope

In scope:

• the wurus.app website and its public pages;
• the application and company subdomains (*.wurus.app);
• the public API and the platform webhooks;
• our mobile applications and our service worker.

Out of scope, and not processed:

• our providers' own services (hosting, registrar, payment gateways, SMS and WhatsApp carriers) — report those to them directly; we will help you find the right contact if needed;
• social engineering and phishing aimed at our staff, our customers or our providers;
• physical access to our premises or hardware;
• denial of service, mass mailing and brute-force attacks;
• raw output from an automated scanner with no demonstrated impact;
• configuration observations with no exploitable consequence (a missing decorative header, a disclosed component version, a password policy you find too lenient).

What we commit to

• Acknowledge your report within 3 working days — a written reply from a person, not an autoresponder.
• Give you our assessment within 10 working days: what we reproduced, the severity we assign, and whether we are fixing it.
• Keep you informed until the fix ships, without you having to chase us.
• Not pursue legal action, nor ask anyone else to, for research carried out in good faith and in line with this policy. Should a third party act against you for such work, we will make it known that it was authorised.
• Credit you if you want it, once the fix is deployed. We equally respect a request to stay anonymous.

What we ask of you

• No destructive testing. Do not delete, alter or encrypt data, do not change configuration, do not interrupt the service.
• No access to anyone else's data. If a flaw gives you access to another company's or another person's data, stop right there: proving access is possible is enough, exploiting it teaches us nothing more. Never extract, keep or share such data; tell us what you saw and destroy anything you may have retrieved.
• Work on your own data. Create a trial account — it is free and gives you a whole company to break.
• No unnecessary load. Keep request volumes low; a test that degrades the service for shops that are trading is no longer research.
• Let us fix it before you publish. We ask you to wait for our fix, or 90 days from your report, before any public disclosure — and we undertake not to use that window to run out the clock.

Rewards

To be plain about where we stand: we do not run a bug bounty yet. Today, no report, whatever its severity, results in a payment, a voucher or any commercial consideration — and we would rather write that down than let anyone hope for one only to turn them down later.

This is not a matter of principle, it is a matter of cash. We are a young company, and a bounty programme opened without the means to honour it does more damage than no programme at all.

Our commitment: we will open a reward programme — material or financial — once we reach profitability or close a funding round. When that day comes, researchers who reported to us before the programme opened will not be forgotten: we keep the list, and that is exactly what it is for.

Until then, what we do offer is smaller and we stand by it: a fast reply written by someone who understands the subject, a fix, and your name in our hall of fame if you want it.

What makes a report useful

A good report saves us days. Tell us, even briefly:

• the exact URL involved and, where relevant, the test company you used;
• the steps to reproduce, in order;
• what an attacker would concretely obtain;
• the date and time of your attempts, so we can find them in our logs;
• the name you would like to be credited under, or your preference for anonymity.

A screenshot or a short video is often worth more than a long paragraph — but never of real data. Create a test company, or blur before sending. If the demonstration requires opening a real customer record, describe the path rather than its contents: we will reproduce it on our side.

This is not a formality. A report containing one of our merchants' data becomes a breach of its own, and we have no legitimate reason to hold it in a mailbox. Stopping at the proof protects us both.

French and English suit us equally well.