Reporting a security issue
If you've found a vulnerability in Tebura, we want to hear about it. This page tells you where to send it and what happens next.
Version 1.1, 11 August 2026.
Where to send it
Email is the only reporting channel. Everything below is about making your report easy for one person to act on. None of it is a precondition for writing to us.
What to expect
You'll get an automatic confirmation the moment your email arrives, so you know it landed and reached the security mailbox rather than general support.
A human replies as soon as one can. We're a small team and we won't publish a response time we can't hold. We'd rather tell you that than set a date and miss it. If you haven't heard from a person and want to know where things stand, reply to the thread.
We won't ask you to stay quiet indefinitely. If we've gone silent, publishing after a reasonable period is your call. We'd appreciate a heads-up first so we're not finding out at the same time as everyone else.
We'll credit you by name if you'd like us to, once a fix is out.
Rewards
We don't run a bounty programme and there is no standing rewards budget, so please don't send us a report expecting payment. If what you find turns out to be serious, we will consider a reward case by case. That is a decision we make after the fact rather than a negotiation, and it never changes how we handle your report.
What to include
A report we can reproduce gets fixed. A report we can't turns into a round trip, and at our size a round trip costs days. Copy this into your email:
Target URL: Steps to reproduce: What you observed: What you expected instead: Impact (what could someone actually do with this): Test account used (if any): Source IP and UTC time window you tested in: Did you access any data that wasn't yours? If so, what:
If you can, put "tebura-vdp" plus a name or handle in your User-Agent while testing. Without it your traffic is indistinguishable from an attack in our logs, and the first hour of looking at your report goes on proving to ourselves that it was you.
Scope
In scope (things we run and can fix):
- tebura.eu and www.tebura.eu, including the booking flow, customer, hotel and driver surfaces.
- Our email and DNS configuration, where the problem is ours to fix rather than a provider's default.
- A demonstrated subdomain takeover. A CNAME pointing at a live provider is not one.
Out of scope (not ours to fix):
- Third-party services we use but don't operate: our payment processor, hosting platform, email provider, error tracking and DNS registrar. Report those to the vendor, who will act on them faster than we can.
- Our hotel partners' own systems and networks. If something looks like it belongs to a hotel rather than to us, send it to us anyway and we'll pass it on.
- Physical attacks on the van, the luggage, or the locks, and anything involving our staff, drivers or hotel reception teams.
We don't run a public test environment. That means production is the only target, so please keep testing read-only: do not create bookings, hotel records or payment intents on tebura.eu. Each one costs real money, sends real email, or takes a slot on a real day's van.
Rules of engagement
Stay inside these and you have our full cooperation:
- Use your own accounts and your own data. Don't touch anyone else's booking.
- No testing that affects availability: no load testing, no denial of service, no hammering an endpoint to see where the limit is.
- No social engineering of our team, our drivers, or hotel staff, and no phishing.
- Don't modify or delete data, and don't hold on to anything you came across.
- Give us a reasonable chance to fix it before you tell anyone else.
Proving impact without taking data
Stop at the first record that proves the point. One screenshot, redacted. Don't page through results, don't dump a table, don't download a file. Tell us how many records you could have reached rather than reaching them. That's just as convincing and it doesn't put anyone's data on your laptop.
If you realise afterwards that you pulled more than you needed, tell us. We would much rather know, and it won't change how we treat your report or how we treat you. We have a legal duty to work out exactly what was accessed, and we can only get that right if you're straight with us.
What we won't treat as a vulnerability
These come up constantly, almost always from an automated scan. Below is what we skip and why. If you think one of them is genuinely exploitable in our setup, show us the impact and we'll look properly.
Email and DNS
| Finding | Why we won't act on it |
|---|---|
| Missing or permissive DMARC, SPF or DKIM | Our mail setup is deliberate. Scanner output on its own isn't a finding. Show us a message a recipient would actually act on. |
| "DKIM is missing" | Our signing selector isn't one of the common names scanners sweep for. Not finding it doesn't mean it isn't there. |
| Email spoofing demonstrated by mailing yourself | Shows the header can be set, not that anyone is harmed. Show us delivery to a third party that a recipient would act on. |
| No DNSSEC, no CAA record, zone transfer attempts | Known and accepted for a site of this size. |
Headers and scanner output
| Finding | Why we won't act on it |
|---|---|
| Missing security headers, HSTS without preload, Referrer-Policy or Permissions-Policy values | We'll take these as suggestions, not vulnerabilities, unless you can show an actual attack they enable. |
| Content Security Policy weaknesses with no working proof of concept | Our CSP has to accommodate several third-party scripts. A scanner disliking it isn't an injection. |
| TLS configuration or server banner findings | That's our hosting provider's edge, which we don't control. |
| Clickjacking on a page with nothing to click | Framing a marketing page achieves nothing. |
| Our version number is visible at /up/version | Published on purpose. It's how we check what's deployed. |
| robots.txt, sitemap.xml or this security.txt reported as information disclosure | All three are meant to be public. |
Keys that are public by design
| Finding | Why we won't act on it |
|---|---|
| Payment provider publishable key in the page source | Publishable keys are published. That's what the word means. |
| Error-tracking JavaScript key in the page source | It's a browser ingest key with no read access. It has to ship to the browser to work. |
Working as intended
| Finding | Why we won't act on it |
|---|---|
| Account or email enumeration on sign-in or password reset | Accepted. Hiding it degrades the experience for every real customer more than it slows an attacker. |
| Booking references look sequential or guessable | Access is authorised server-side. Show us an unauthorised read and we'll treat it seriously. |
| Lock codes are short and could be enumerated | The printed code is public by design, since a phone camera is the intended entry point. A way to bypass our rate limiting, or a response that tells a real code apart from a made-up one, we do want to hear about. |
| Self-XSS, or XSS in a field only you can see | No path to another user. |
| Missing autocomplete attributes, weak password policy, no MFA, back button after logout | Known product decisions, not defects. |
| Anything needing a rooted device, a machine-in-the-middle position, or physical access to a signed-in browser | If someone already has that, this isn't where they'd start. |
| Scanner or AI-generated reports with no demonstrated impact | We'll reply once. We won't debate a template. |
If we've got one of these wrong for our particular setup, tell us why and show the impact. We'd rather be corrected than consistent.
Sending something sensitive
We don't publish a PGP key. An unmonitored key we can't decrypt in the field would be worse than none. If a report is too sensitive to send in plain email, write to security@tebura.eu saying so without the detail, and we'll arrange another channel.
Legal
Belgium has had a nationwide legal safe harbour for ethical hackers since February 2023. If you follow the national procedure, you're protected under Belgian criminal and civil law, and that protection comes from the law, not from us.
One of its conditions is that you notify the Centre for Cybersecurity Belgium as well as us, at cert@ccb.belgium.be. That's expected, and it's also where to take it if you think we've handled your report badly.
Nothing on this page shrinks that protection. When we say something is out of scope, we mean it's not something we'll act on, not that you've lost any legal standing by looking at it.
We don't negotiate payment for reports. If a report arrives as a demand, we'll assess and fix the issue exactly as we would otherwise, and take the rest to the CCB.
