Security and responsible disclosure
Last updated: 18 October 2026
[ 01 ]
How we protect the platform
At a high level, and only what is in place:
- TLS on every connection; a strict Content-Security-Policy on our websites.
- Passenger names, dates of birth, travel documents and contact details encrypted field by field with AES-256-GCM, under keys held outside the database.
- Payment cards sent to pay an airline are passed to that airline and never stored; the card a business pays us with goes straight to Stripe.
- Row-level security in the database separating one customer's data from another's.
- API keys and passwords stored only as hashes; two-factor authentication available on every account; sessions you can list and end yourself.
- Production data hosted in the European Union, with the providers listed on our Sub-processors page.
The Privacy Policy (clause 8) and the Data Processing Agreement (Annex A) describe these measures in the same terms.
[ 02 ]
Reporting a vulnerability
If you believe you have found a security vulnerability in norba.io, app.norba.io, api.norba.io, booking.norba.io or the Norba Travel apps, write to hello@norba.io with "Security" in the subject. Please include:
- what the vulnerability is and where — the URL, endpoint or screen;
- the steps to reproduce it, and a proof of concept if you have one;
- what an attacker could do with it, as you understand it;
- how to reach you, and whether you would like to be credited.
Do not include real passengers' data, card numbers or other people's credentials in the report. If you came across any while testing, say so and describe it without copying it.
Our contact details for security reports are also published, in the format of RFC 9116, at norba.io/.well-known/security.txt.
[ 03 ]
Rules for testing
Good-faith research is welcome. To stay within it:
- Test only against your own account, and in the sandbox environment wherever you can.
- Never test against airline systems. Bookings made through Norba reach airlines' live reservation systems, and a test there is a real booking with real consequences.
- Do not access, change or delete data that is not yours. If you reach someone else's data, stop, do not keep a copy, and report it.
- No denial-of-service testing, no high-volume automated scanning, and nothing that degrades the service for others.
- No social engineering of our team or our customers, no phishing, and no physical attempts.
- Give us reasonable time to fix the issue before you disclose it, and agree the date with us.
[ 04 ]
Our commitment to researchers
If you follow these rules, we treat your research as authorised: we will not bring legal action against you or report you to the authorities for it, and we will not treat it as a breach of the Terms of Service or the Acceptable Use Policy. If a third party brings action against you over research that complied with this page, we will make it known that it was authorised by us.
That commitment covers our own systems. It cannot authorise testing of systems that belong to others — airlines, payment providers, or the services listed on our Sub-processors page — whose own policies apply.
[ 05 ]
What happens after you report
- We acknowledge your report and tell you who is handling it.
- We investigate, keep you informed of progress, and tell you when the issue is fixed.
- We agree the disclosure date with you, and credit you publicly if you wish.
- If the issue has exposed personal data, we handle it as a personal data breach, as the Privacy Policy and the Data Processing Agreement describe.
[ 06 ]
Usually out of scope
These rarely carry real risk on their own; report them only with a concrete way to exploit them:
- reports produced by automated scanners with no demonstrated impact;
- missing best-practice headers or cookie flags with no exploit;
- clickjacking on pages with no state-changing action;
- self-XSS, or attacks that need a compromised device or browser;
- vulnerabilities in third-party services we use, which belong with their own programmes.
[ 07 ]
Keeping your own account safe
- Turn on two-factor authentication.
- Keep API keys on your servers only — never in a browser, a mobile app or a repository — and rotate any key you suspect has leaked. Revocation is immediate.
- Review your active sessions and your security events in the dashboard under Settings, or on the booking site under Account → Security.
- We never ask for your password, a two-factor code or card details by email, chat, a support ticket or the telephone. A message that does is not from us; forward it to hello@norba.io.