Responsible Disclosure.

1. Our commitment

Tripkoz Technologies runs a platform that carries children’s location data. We take reports of security problems seriously, and we would much rather hear about a flaw from you than from an incident.

If you have found something, tell us. We will investigate every good-faith report, keep you informed, credit you if you want to be credited, and fix what needs fixing.

2. How to report

Email security@tripkoz.com. Please include:

• A clear description of the issue and why you believe it is a security problem;
• The affected URL, endpoint, application version or component;
• Step-by-step instructions to reproduce it, including any request or payload needed;
• Proof-of-concept output, screenshots or a short video — enough to demonstrate it, no more;
• Your assessment of the impact, and how you would like to be credited (or that you prefer to stay anonymous).

Report in English. One issue per email, so each can be tracked and fixed separately.

If a report contains another person’s data that you encountered while testing, tell us that it does and do not attach it. We will arrange a secure way to receive whatever we need.

3. What we will do, and when

Our commitments to you:

• Acknowledgement within two (2) business days of your report reaching us;
• A triage decision — accepted, duplicate, or not a vulnerability, with reasons — within ten (10) business days;
• Progress updates at least every fourteen (14) days while the issue is open;
• Remediation targets from the date of triage: critical within 7 days, high within 30 days, medium within 90 days, low on the next suitable release;
• Confirmation when the fix ships, and an invitation for you to verify it;
• Public credit in our advisory or release notes if you would like it.

If we disagree that something is a vulnerability, we will explain why rather than closing the report silently.

4. Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised, and treat it as an exception to the technical restrictions in the Acceptable Use Policy and clause 9 of the Terms;
• Not initiate or support legal action against you in connection with it, including under the Information Technology Act, 2000;
• Work with you to understand and resolve the issue quickly;
• Where a third party brings action against you for research conducted within this policy, make it known that your activity was authorised.

This safe harbour covers only activity within this policy. It does not authorise breaking the law, and it cannot bind a third party whose systems you also touch.

If you are unsure whether something is in scope, ask us first. We will answer, and asking will never count against you.

5. Rules of engagement

While testing, you must:

• Use only your own test account, or an account you have explicit written permission to use;
• Stop as soon as you have confirmed a vulnerability — do not go further into a system than needed to demonstrate it;
• Never access, copy, modify, download or retain another person’s data. If you encounter it accidentally, stop, do not save it, and tell us in the report;
• Never degrade the Service for others: no denial-of-service, no load or stress testing, no automated scanning at volume, no resource exhaustion;
• Never use social engineering, phishing, or physical intrusion against our staff, customers or offices;
• Never plant a backdoor, persist access, or install anything on our infrastructure;
• Give us reasonable time to fix an issue before disclosing it publicly — see clause 8.

Testing that breaks these rules is outside the safe harbour in clause 4.

6. In scope

The following are in scope for testing:

• The Tripkoz marketing website at www.tripkoz.com;
• The Tripkoz web dashboard and its authenticated routes;
• The Tripkoz REST API;
• The Tripkoz Android application, including its local storage and network behaviour.

Vulnerability classes we especially want to hear about, given what the platform holds:

• Any cross-tenant access — reading, writing or inferring one organisation’s data from another organisation’s session;
• Authentication or session flaws, including token handling, OTP flows, invitation links and password reset;
• Authorisation flaws — a role or permission that grants more than it should, or an object reference that is not scoped to the caller;
• Exposure of passenger, guardian or driver personal data, location history, or uploaded documents, including through signed URLs;
• Remote code execution, injection, deserialisation and server-side request forgery;
• Payment flaws — signature verification, order tampering, or activation without a captured payment.

7. Out of scope

The following are not accepted, unless you can demonstrate a realistic, concrete impact:

• Findings from automated scanners without a working proof of concept;
• Missing security headers, cookie flags or TLS configuration preferences with no demonstrated exploit;
• Rate limiting on non-sensitive endpoints, and volumetric or denial-of-service issues;
• Self-XSS, clickjacking on pages with no state-changing action, and issues requiring a fully compromised or rooted device;
• Social engineering, phishing, and physical security;
• Vulnerabilities in third-party services we merely consume — report those to Razorpay, Google or the provider concerned;
• Outdated browsers, or software versions with no exploitable path in our Service;
• Email configuration issues (SPF, DKIM, DMARC) without a demonstrated spoofing impact;
• Reports about our staging, demo or sandbox environments, which contain synthetic data only.

8. Coordinated disclosure

Please give us 90 days from your report before disclosing publicly, or until a fix has shipped, whichever comes first. If a fix is going to take longer we will tell you why and agree a date with you.

We will not ask you to stay silent indefinitely, and we will not use the delay to avoid fixing something. Where an issue affects customer data, we will publish an advisory ourselves.

Please do not disclose the details of an unfixed issue to anyone other than us, and do not use it to pressure us.

9. Recognition

We do not currently run a paid bug bounty programme. What we offer is a fast, honest response, public credit if you want it, and a place on our security acknowledgements.

For a report of genuine severity we may offer a discretionary token of thanks. That is at our discretion, is not an entitlement, and reporting is never conditional on it.

10. security.txt

Our machine-readable security contact information is published at https://www.tripkoz.com/.well-known/security.txt in the format described by RFC 9116, and points back to this page as the policy.

If email is not suitable for what you have found, say so at security@tripkoz.com and we will arrange an encrypted channel.