For security reviewers and researchers
Security and vulnerability disclosure
If you have found a way to break something here, we want to hear it, and we would rather hear it from you than read about it. This page says where to write, what is in scope, what we promise in return, and which controls are already in place, so you can check them rather than take them on trust.
Report
How to report
Email anil@riskrouter.eu with “security”
in the subject. Say what you found, how to reproduce it, and what you think the impact is.
English or French. The same contact is published at
/.well-known/security.txt.
RiskRouter is a one-person company, so you will be writing to the person who wrote the code. We aim to acknowledge a report within five working days and to tell you what we are doing about it. We will credit you when it is fixed, if you want to be credited. There is no bug bounty: we have no money to offer, and would rather say so than imply otherwise.
Scope
What is in scope
- riskrouter.eu: the site and the demo console.
- api.riskrouter.eu: pricing, recording, the ledger export and attestation, sandbox keys.
- The ledger’s guarantees: any way to change, insert, reorder or delete an entry without it being detectable, to get an attestation signed that we did not produce, or to make a failed write look like a success.
- Attribution: any way to record against a distributor without that distributor’s key, or to read another distributor’s entries.
- The public verifier at github.com/aniljangrabe-dev/riskrouter-verify: any input that makes it report a tampered ledger as intact.
Please do not
- Test for denial of service or send floods of requests. The ledger’s ceilings are deliberate and documented.
- Try social engineering, or anything involving our email provider or hosting providers’ own systems.
- Record personal data in the ledger. Entries can never be deleted, so anything you put there stays forever. A sandbox key is enough to test recording.
- Access, keep or share data that is not yours beyond what you need to show the problem.
Research that follows this page, in good faith, is welcome. We will not pursue legal action against it.
Controls
What is already in place, and how to check it
| Control | What it does | Check it |
|---|---|---|
| Content-Security-Policy | Every page may run only the scripts it shipped with, listed by hash. No third-party script, no inline code that was not there at build time, no framing. | Response headers of any page |
| No third-party requests | The site loads nothing from any other origin: no CDN, no font service, no analytics. | Your browser’s network tab |
| Transport and framing | HSTS, nosniff, framing denied, a strict referrer policy, on the site and the API. |
Response headers |
| Keys stored as digests | Only the SHA-256 of an API key is ever stored. A copy of our database would contain no usable key. | API reference |
| Append-only ledger | The database refuses edits and deletions for every role; entries are hash-chained and the head is signed. | Verify page |
| One outbound destination | The API Worker contacts nothing but its own database. An automated test fails the build if a new destination appears. | Trust page |
| Admin behind an identity check | The admin console sits behind Cloudflare Access and verifies each session’s signature. It can do five things, none of which touch a quote or the ledger. | Not publicly reachable, by design |
Honestly
What we have not done
No external penetration test and no security certification. We claim neither. The controls above are what a one-person validation build can put in place and let you check; if a regulated distributor needs an independent assessment before a pilot, that is a reasonable thing to ask for and to plan together.