Responsible Disclosure

Scope

This policy covers om-travels.in and its subdomains: the website you are reading now, and any page or path under it. That includes the pages you can see, the forms on them, and anything a browser or an ordinary security tool can reach without needing a login we have not given you.

Out of scope: our physical premises, our vehicles, and social engineering directed at our staff or drivers. This policy exists to make it safe to test a website. It is not a licence to test a person, and it does not authorise turning up at our office, approaching a driver on the road, or calling our team and pretending to be someone you are not, however good the intention behind it.

We draw that line for a plain reason: a website vulnerability and a person are different things to put at risk, and the protection this policy offers a genuine researcher is specific to the first. Physical intrusion, and any attempt to manipulate a staff member into handing over access or information, sits outside authorised security research under the Information Technology Act, 2000 in a way a technical finding on this site does not, and it puts a real person under real pressure for no benefit to anyone. If you believe a member of our team has been careless with information rather than that a system has a flaw, tell us that directly through the contact below rather than testing it on them.

How to report

Write to us or call. Reports go to Sachin Jaglan, Security Contact: email sachin@om-travels.in, phone +91 99966 69190. Please do not raise a security report through our general enquiry form or our public reviews; write or call the contact above instead.

A phone call is the fastest way to reach us if the issue is actively being exploited or is otherwise urgent. For everything else, email is the better channel: it gives you room to set the report out properly, it gives us something to file and track, and it creates a record both sides can refer back to as the case moves along.

We ask that you keep a report to one issue at a time rather than a running list. A single, well-described finding is easier for us to triage correctly and to act on quickly than several issues folded into one message, and it means the acknowledgement and the timeline below apply to something specific rather than to a bundle we then have to separate out ourselves.

What to include

A report is actionable when we can reproduce the issue from what you have written, without having to write back and ask what you meant. The more of the following you can give us, the faster we can confirm the issue and start fixing it.

• A description of the issue, in plain terms: what is wrong, and why it matters
• The exact URL or endpoint where you found it
• The steps to reproduce it, in order, as precisely as you can set them out, so that following them gets us to the same result you saw
• The browser, app or tool you used, including its version where that is relevant to the issue
• A screenshot, a short screen recording, or the request and response data, wherever that helps show the issue rather than just describe it
• What you believe the impact is, and to whom: a user, our systems, or both

None of this needs to read like a formal report. A clear, chronological account of what you did and what happened is worth more to us than polished language, and we would rather have a plain account today than a tidier one next week.

Our commitment

We read every report ourselves. Here is the timeline we work to once one reaches us.

A timeline matters because a report you cannot get an answer on is a report you have no way of judging. It tells you we have actually seen what you sent, rather than left it sitting unread, and it gives you a point at which it is fair to follow up if you have heard nothing. Acknowledgement confirms your report has reached a person, not a spam filter. Triage is where we work out what you have found, how serious it is, and what has to change to fix it.

Between acknowledgement and resolution, we may write back to ask a question, to confirm we have reproduced what you reported, or to let you know the issue has been passed on to whoever is fixing it. We do not promise a running commentary on every step of the fix, since some of that work is internal and some of it takes longer than any timeline can predict in advance, but we do promise to tell you once the issue is resolved, and to let you know if our assessment of its severity changes along the way.

Safe harbour

Reporting a security issue to a business, rather than exploiting it or walking away, is a good faith act, and it should not carry personal risk for the person doing it. That is what a safe harbour is for: it tells a genuine researcher, before they write to us, exactly where they stand, so the decision to report is not also a decision to gamble with their own position.

If you keep to this policy, here is where you stand with us.

We will not pursue legal action against, or ask law enforcement to investigate, any researcher who reports a vulnerability to us in good faith and in accordance with this policy. We consider such research authorised under Section 43 and Section 66 of the Information Technology Act, 2000.

This protection runs alongside the rest of this policy rather than instead of it. It covers testing and reporting carried out within the scope set out above and in keeping with what we ask of you further down this page. It does not extend to activity outside that scope, and it does not retroactively cover an issue you already disclosed publicly or exploited before writing to us.

What we ask of you

These are not arbitrary conditions. Each one exists to keep the research itself safe, both for you and for anyone else using the site while you are testing.

• Do not go beyond a proof of concept: stop once you have shown the issue exists, and do not extract data past that point. Once you have demonstrated that a flaw is real, pulling further data adds nothing to the report and turns a legitimate test into exactly the kind of access this policy exists to keep out
• Do not degrade the service for other people using the site while you test. A live site is being used by real people booking a real trip while you are testing it, and a denial-of-service test or a heavy automated scan can take the site down for them even if that was never your intention
• Do not access, change or delete another person’s data. Confirming that a flaw exposes data belonging to someone else does not require reading, copying or altering it, and doing so moves a finding from research into an intrusion on a third party who never agreed to be part of your test
• Do not disclose the issue publicly until we have agreed a date with you. A vulnerability made public before it is fixed is a vulnerability every visitor to this site is exposed to in the meantime, and an agreed disclosure date protects both your credit for finding it and our customers while the fix is being made

Working within these limits is also what keeps your own testing inside the safe harbour above. A report built on a proof of concept, left the rest of the site alone, and stayed private until we agreed otherwise is exactly the kind of good faith research that clause protects.

Recognition

We do not currently offer a monetary reward for a report. We are a working transport business rather than a technology company with a bounty budget.

What we can offer is credit. If you would like to be named, we are glad to credit you by name once the issue is fixed, and to say so if you ever need it confirmed, for instance for your own portfolio of disclosed findings. If you would rather stay anonymous, that is equally fine with us: tell us which you would prefer when you report, and we will follow it.

security.txt

A machine-readable copy of the contact details on this page is published at /.well-known/security.txt, for a scanner or a researcher’s tooling to find without reading this page first.