Vulnerability Disclosure & Security Policy

If you believe you have found a security vulnerability in a Yatra service, please tell us. We treat responsible disclosure as a collaboration, not an adversarial process. This page sets out our scope, rules, timelines, and the legal safe harbour that applies when you follow them.

This Policy is drafted against the Electronic Transactions Act, 2063 (2006), the Banking Offences and Punishment Act, 2064 (2008), the draft Nepal Cybersecurity Policy, 2080 (2023), and the international benchmark ISO/IEC 29147:2018 (vulnerability disclosure) and ISO/IEC 30111:2019 (vulnerability handling).

Send your report to [email protected]. A matching PGP key is published at https://yatraforfun.com/.well-known/pgp-key.txt and fingerprinted under Key fingerprint below. The inbox is monitored 24 × 7.

A good report includes:

• A title with the component or URL affected.
• Steps to reproduce — the minimum set needed to demonstrate the issue. A curl command, Burp request, or short screencast is ideal.
• Impact — what an attacker can read, change, or do that they should not be able to.
• Supporting evidence — request and response snippets, screenshots, a Proof-of-Concept payload.
• Your contact handle — e-mail, a public researcher profile (HackerOne, Bugcrowd, GitHub), and a preferred name for credit.

If the vulnerability is actively being exploited, or exposes sensitive data, use the subject prefix [URGENT]. For sensitive payloads, encrypt to our PGP key.

In scope

• yatraforfun.com and every subdomain under it — in particular www, api, dashboard, media, admin, staging, and docs.
• Public Yatra REST and GraphQL APIs.
• The Yatra Android and iOS applications when available through the official store listings.
• Yatra npm, PyPI, and crates.io packages published from a Yatra-owned account.
• Yatra infrastructure components you can see from the public internet — nginx, Cloudflare edge, exposed docker ports — if they leak data or enable lateral movement.

Out of scope

• Third-party services we merely link to (airline sites, PayPal, eSewa, Khalti, Agoda, Amadeus GDS) — report to those vendors.
• Social-engineering attacks against Yatra employees, contractors, or suppliers.
• Physical attacks against Yatra offices or staff.
• Denial-of-service attacks or load-testing.
• Brute-forcing live customer credentials. Use a test account you own; if you need one, ask us to provision a test tenant.
• Reports produced by automated scanners without manual validation (Nessus, Burp Active Scan, Acunetix) and no proof of exploitability.
• Missing security headers (CSP, HSTS, X-Frame-Options, Permissions-Policy) without a concrete impact.
• Self-XSS, tabnabbing without meaningful impact, clickjacking on unauthenticated marketing pages, or any finding that relies on a user installing malware or running attacker-controlled code on their own device.
• SPF, DKIM, DMARC, or DNS-caa misconfigurations — please send us a courtesy heads-up at [email protected]; we'll fix them, but they are not rewarded.
• Rate-limit bypasses unless they enable a concrete impact (for example, bulk account takeover or financial loss).

1. Test only against accounts you own. If you need multiple accounts or a tenant, e-mail us first and we provision isolated test identities.
2. Do not access, modify, or delete data belonging to another user. The moment you can see somebody else's PII, stop, document the proof-of-exposure with a minimal sample (we recommend a masked sample of the schema, not the raw record), and report.
3. Do not run denial-of-service or resource-exhaustion attacks. If you suspect a DoS condition, describe it in writing with a math proof rather than demonstrating it live.
4. Do not attempt to escalate a bug into a criminal action. No data exfiltration, extortion, or publication before we agree.
5. Do not socially engineer Yatra staff, partners, or customers to progress a test.
6. Keep payloads benign. Avoid destructive commands (DROP, rm -rf, overwrite) even as a proof of concept.
7. Do not publish the finding without our written coordination. See the 90-day disclosure timeline below.
8. Give us a sensible time window to fix. See "Our commitments" below.

When your research is conducted in good faith and stays within the Scope and Rules of Engagement above, Yatra will:

• Not pursue legal action against you under the Electronic Transactions Act, 2063 (2006), the Banking Offences and Punishment Act, 2064 (2008), or under any civil cause of action, including contract, trespass, or intellectual property.
• Not report you to law enforcement for any activity undertaken in compliance with this Policy.
• Waive any anti-scraping claim to the minimum extent required for your testing, provided the rate of requests is reasonable.
• Cooperate with you if a third party — for example, a host-country authority — takes action that we did not initiate; we will provide a written statement that your research was authorised under this Policy.

Safe harbour does not cover intentional harm, theft, extortion, publication of exfiltrated data, or attacks against targets and services outside scope. Nothing in this Policy authorises you to violate the law of a country other than Nepal.

Where your research conflicts with the acceptable-use rules in our AUP, this safe-harbour provision prevails within its limits.

We keep the reporter informed at every stage. If we miss an SLA, we tell you why and agree a new target.

Yatra runs a discretionary bug-bounty programme. We pay in NPR or in USD via PayPal, at the reporter's choice.

Final reward amount is determined by impact, exploit complexity, quality of the report, and whether the fix we ship required your input. Duplicate findings are awarded only to the first valid submission. Rewards are paid after we confirm the fix and — where legally required — after KYC and withholding-tax deduction under the Income Tax Act, 2058 (2002).

Residents of countries listed on a Nepal Rastra Bank or UN sanctions list are not eligible for cash rewards.

With your permission, we credit valid reporters on the Security hall of fame page, including a link back to your chosen profile. You can opt out of public credit — we will keep the recognition private.

• Primary e-mail: [email protected]
• PGP key: https://yatraforfun.com/.well-known/pgp-key.txt
• Fingerprint: 5E7F A3B1 9C2D 4E6F 8210 B4C6 D8E0 1234 ABCD EF56 (example — replace with the real fingerprint on launch).
• security.txt: https://yatraforfun.com/.well-known/security.txt — machine-readable version of this Policy (RFC 9116).
• Postal: Yatra For Fun Pvt. Ltd., Koteshwor-32, Kathmandu, Nepal — Attn: Security Team.
• Emergency (24/7): +977 980-2363869.

You may want to see what we already do before suggesting an improvement. Summary controls (non-exhaustive):

• HTTPS with modern cipher suites; HSTS with a 12-month max-age; Certificate-Transparency monitoring.
• Short-lived JWT access tokens (15 minutes) and rotating refresh tokens (7 days).
• Passwords hashed with bcrypt; argon2id is planned for 2026.
• Role-based access control across super_admin, admin, hotel_admin, travel_agent, and agent roles; least-privilege by default.
• Idempotency keys on every booking and payment endpoint.
• Signature verification on all gateway callbacks.
• Payments via regulated gateways only (eSewa, Khalti, ConnectIPS, FonePay, PayPal); Yatra stores only tokenised references.
• Network-segmented data plane: database and Redis are not exposed to the public internet.
• Encrypted daily backups; tested restore procedure.
• Centralised structured logging; anomaly review.
• 72-hour data-breach notification commitment to affected users and the competent authority, under the Individual Privacy Act, 2075 (2018).
• Secrets handled in environment variables, scoped per service, rotated on a schedule; no secrets in source control.

We update this Policy as our scope, stack, or reward tiers change. The Last updated date at the top of the page reflects the current version. Material changes are announced via the security.txt file and via [email protected].