Vulnerability disclosure

1. Why this page exists

RezRoute is built to sit between sales channels and the systems that hold operators' calendars and travellers' bookings. A weakness in that position would not stay in that position, so we would rather hear about one from a researcher than from an operator whose seats have been sold twice.

This page tells you what you may test, how to tell us what you found, and what we will and will not do in response. What the service receives, forwards and keeps, and the controls around it, are described on the security page.

It is written plainly, including about what we do not promise, because a disclosure policy that hedges is a disclosure policy nobody follows.

2. What is in scope

The following are in scope for testing under this policy.

• rezroute.com, this website, and any subdomain of it that RezRoute operates.
• api.rezroute.com, the connectivity endpoint that receives calls from sales channels, and the endpoints it exposes.
• Authentication between a channel and the service, in both directions. That authentication is HTTP Basic, because HTTP Basic is what the channels require.
• Routing itself: anything that would let a call about one marketplace's product be answered by, or written into, the other.
• The request logs described on the security page, and anything that would expose operator or channel credentials.

We are most interested in anything that would let one party read, change, hold or cancel another party's availability or bookings, and anything that lets a caller bypass authentication. Those are the findings that cost an operator a real seat.

3. Systems that belong to somebody else

These are outside this policy. Testing them is not covered by the safe harbour below, because we cannot give you permission we do not have.

• The marketplace platforms The Greek Local and Cyprus Bucket List, including their operator portals and their public sites. They are separate systems with their own arrangements, and this policy does not cover them.
• GetYourGuide, Viator, and any other sales channel. Report to them directly, under their own policies.
• Providers listed on the sub-processors page. Report to the provider under its own policy. Tell us as well if the issue exposes RezRoute data. Our hosting provider's own acceptable use terms apply to your testing of anything we run on it, and we cannot waive them on your behalf.
• Systems belonging to an operator, including any website or booking system of their own.

4. How to report

Send the report by email, with the word security in the subject line, to the support address published on the contact page, which is currently connectivity@rezroute.com.

A useful report contains:

• the host or endpoint affected, and the date and time you tested;
• what the issue is, in one or two sentences, before the detail;
• the steps to reproduce it, including any request and response needed to see it;
• what an attacker could actually do with it, which matters more to us than a severity score;
• how you would like to be credited, or that you would prefer not to be.

Please send one issue per report, in English or Greek, and please do not send a scanner export in place of a description.

5. What to expect

We do not publish a guaranteed acknowledgement time, because we do not yet have the rota that would honour one, and a guarantee made by a website rather than by a team is worth nothing to the person relying on it. What we commit to is the sequence, not a clock.

1. We read every report a person sends, and we reply to it.
2. We tell you whether we could reproduce the issue, and whether we consider it a vulnerability. If we do not consider it one, we say why.
3. We tell you what we intend to do about it, and we tell you when it is fixed.
4. Where an issue affects operators, a marketplace or a sales channel, we inform the parties who need to know.

The GetYourGuide Supplier API specification requires a connectivity partner to keep a named technical contact reachable within 24 hours or the next business day. That is an obligation we owe the channel, not a response time offered to a researcher.

Please give us reasonable time to fix an issue before describing it publicly, and tell us when you intend to publish so that we are not surprised by it.

6. Safe harbour

If you research in good faith and stay inside this policy, we treat your testing as authorised. That statement is worth little on its own, so here is what it actually commits us to.

• We treat access you gain in the course of research that follows this policy as authorised access, so far as it is ours to authorise, for the purposes of any law that turns on whether access was permitted by the system owner.
• We will not bring a civil claim against you, and we will not make a criminal complaint or a report to law enforcement, in connection with that research.
• If somebody else brings a claim or a complaint against you for research that followed this policy, we will state in writing that your testing was authorised by us, to them and to a court if it comes to that.
• If we receive a legal demand for your identity or for your correspondence with us, we will tell you before we respond, unless we are prohibited from telling you, so that you have the chance to take advice.
• If you cross one of the lines below by accident, stop when you notice and tell us promptly, we will still treat the report as made in good faith. Those lines exist to limit harm, not to give us a reason to withdraw this afterwards.
• We will not use a report as a reason to end or worsen a commercial relationship, if you happen to be an operator or to work for one.

Good faith, for this purpose, means all of the following.

• You stay within the scope set out above.
• You stop as soon as you have a proof of concept. You do not go further to see how much more you can reach.
• You do not access, copy, alter or delete data that is not yours, and you do not use anyone's credentials but your own.
• You do not degrade the service. No denial of service testing, no load testing, and no automated scanning heavy enough to affect a real booking call.
• You do not create real reservations or bookings against a live operator's calendar. A seat you hold is a seat a real traveller cannot buy.
• You do not use social engineering against our staff, our operators or our providers.
• You give us reasonable time before publishing.

What this safe harbour cannot do

It is given by DEMCYN LTD and it binds nobody else. It does not authorise testing of a sales channel, a marketplace, a provider or an operator, because none of those are ours to authorise. It does not waive our hosting provider's acceptable use terms, which apply to you as they apply to us. And it is not a licence to break a law that does not turn on the system owner's permission.

7. If you encounter personal data

This website holds no personal data for you to find. The router is a different matter: booking payloads that pass through it carry travellers' names and contact details, and sometimes free text about health or mobility. If your testing exposes personal data at any point, on any system covered here:

• stop immediately;
• do not save, copy or share it, and do not include it in your report. Describe what you were able to reach instead, and redact any example;
• tell us straight away, and tell us what you saw;
• delete anything you captured incidentally, and tell us that you have.

Nothing in the safe harbour above protects testing that keeps going once personal data is in view. What happens to that data in normal operation is set out in the privacy notice and the data processing terms.

8. Reports we will not act on

These are out of scope unless you can show a working exploit and a real consequence. If you can show one, send it.

• Missing security headers with no demonstrated impact.
• TLS configuration findings with no working attack.
• Email configuration findings, including SPF, DKIM and DMARC, with no demonstrated exploit.
• Output from an automated scanner without a proof of concept and an explanation.
• Library or framework versions reported as outdated, without a vulnerability that is reachable here.
• Findings that assume this site has an account system, a login, a form or a session. It has none of those.
• Self-inflicted issues, including self-XSS.
• Clickjacking on pages that carry no state-changing action, and missing anti-clickjacking headers on such pages.
• Denial of service, volumetric testing and rate limit exhaustion.
• Social engineering, phishing and physical access attempts against people or premises.
• Findings that only affect an unsupported or heavily modified browser.
• Reports about a third party service, which belong with that service.

9. No bug bounty, and no promised response time

We do not pay for vulnerability reports. There is no bounty, no reward schedule, no points and no swag. We would rather say that at the top of a page than let a researcher spend a weekend expecting one.

There is no promised response time either. Not a business day figure, not a best effort figure. The sequence set out above is the whole of what we commit to, and nothing on this site should be read as a service level for security reports. The absence of an operator-facing service level agreement is explained on the reliability page, and it applies here for the same reason.

What we offer instead is a straight answer, a fix, and credit if you want it.

10. Contact

• Security reports: connectivity@rezroute.com with the word security in the subject line.
• Entity giving the safe harbour: DEMCYN LTD, Vavyla 3, Block A, Flat/Office 204, Pera Chorio Nisou, 2572 Nicosia, Cyprus
• Everything else: connectivity@rezroute.com

This version of the policy is dated 24 October 2026. When the scope changes, the date changes with it.