The technical and organizational measures protecting the Platform, and how to report a vulnerability.
Last updated: 8 August 2026
Effective Date: 8 August 2026
Last Updated: 23 August 2026
This Policy describes the security principles and practices Onyatrips applies to protect the Platform, and explains how to report a suspected vulnerability. We aim to describe our current practices accurately, and we do not claim a security certification, formal audit, or capability we do not have.
This Policy describes the security principles, technical controls, and processes Onyatrips applies to protect the Platform and the data described in our Privacy Policy. It also sets out how to report a suspected security vulnerability. It applies to the Onyatrips website, backend API, and associated infrastructure.
We aim to apply defense-in-depth (multiple independent layers of control rather than relying on any single measure), least privilege (access limited to what a given user, role, or system component needs), and secure defaults. This section states our aims; the sections below describe what is actually implemented today versus what is planned.
jwt_blocklist) invalidates specific access tokens on logout, and a per-user token version counter can immediately invalidate every outstanding access token for a user (used, for example, after a suspected compromise).Not currently implemented: SMS-based OTP, two-factor/multi-factor authentication (TOTP or authenticator-app based), and biometric authentication.
user, admin, super_admin roles stored on the user's profile), enforced by dedicated middleware for admin-only routes.express-rate-limit) on authentication (20 requests/15 min), OTP (5 requests/15 min, keyed by IP and email), payment, booking, support, upload, and webhook endpoints, and a general-purpose limiter elsewhere..jpg extension), file-size limits per category, path-traversal protection on filenames, and an explicit block on SVG uploads (a common vector for stored cross-site scripting and XML-based attacks).We maintain application logs and rely on our hosting providers' (Render, Vercel, Neon) built-in logging and monitoring. We do not currently claim to operate 24/7 dedicated security monitoring, a security operations center (SOC), or automated real-time alerting on anomalous security events. Analytics tooling (PostHog, Google Analytics) is used for product usage insight, not security monitoring, and should not be conflated with it in this Policy.
We do not currently have a documented, formally adopted incident-response plan or breach-notification procedure. Until one is defined and adopted, this Policy commits only to the following: if we become aware of a security incident affecting your Personal Data, we will investigate, take reasonable steps to contain and remediate it, and notify affected Users and, where required by applicable law (including the DPDP Act and, where applicable, GDPR/UK GDPR), the relevant regulatory authority, within the timeframe required by that law. We do not commit to a specific notification timeframe beyond what law requires until a formal incident-response process exists.
We rely on routine dependency updates and standard package-manager tooling to track known vulnerabilities in third-party libraries. We do not currently confirm that automated dependency-vulnerability scanning is active across our systems, and we do not currently claim to run scheduled, independent penetration testing or a third-party security audit.
Credentials and provider API keys (database connection strings, JWT signing secrets, Razorpay keys, email-provider keys, etc.) are managed through environment variables rather than being committed to source control, following standard practice reflected in our .env.example files (which document required variable names without real values).
We have not confirmed a specific, tested backup and disaster-recovery procedure beyond whatever automated backup capability our database provider (Neon) offers by default. This Policy does not claim a specific recovery-point objective (RPO) or recovery-time objective (RTO) until these are defined and tested.
We use a defined set of third-party service providers, listed in the Privacy Policy (PostHog, Google Analytics, Google Sign-In, Razorpay, Customer.io, Ably, Cloudflare R2, Render, Vercel, Neon). Each processes only the data necessary for its function.
Paid booking is live on Onyatrips today (group-trip seats and Place slots) — see the Refund and Cancellation Policy. Card, UPI, and netbanking details are entered directly into Razorpay's hosted checkout interface and are never received, processed, or stored by Onyatrips — this reduces our PCI-DSS scope, since we do not directly handle cardholder data. We store only Razorpay's own order/payment identifiers, amount, currency, and status. The Razorpay webhook-signature verification described in Section 7 is live in production as part of this integration, using a timing-safe comparison to prevent forgery; both the client-side verification callback and the webhook independently and atomically transition a payment/booking's state exactly once, so a retried or duplicated request cannot double-process a payment. The amount charged is always computed by our backend from the trip's/slot's own stored price, never accepted as a value supplied by the client.
Access to production systems and administrative tooling is intended to be limited to authorized personnel on a least-privilege basis. We do not currently have documented, formal internal-access-review procedures, employee offboarding checklists, or admin-action audit logging beyond the business-listing approval audit trail (business_status_logs).
No independent penetration test or formal third-party security audit has been confirmed as completed as of the Effective Date above. This Policy does not claim otherwise. We intend to conduct periodic internal security review as the Platform matures; a formal, scheduled program has not yet been adopted.
We do not currently operate a formal bug-bounty program or a published security.txt file. Until a dedicated security contact and process exist, please report a suspected security vulnerability to legal@onyatrips.com with the subject line "Security Vulnerability Report," and we will route it internally.
While investigating or reporting a vulnerability, please do not: access, modify, or exfiltrate data beyond what is strictly necessary to demonstrate the issue; perform denial-of-service testing against our production systems; use social engineering against our staff, contractors, or Users; access another User's account or data without their explicit permission; or publicly disclose a vulnerability before we have had a reasonable opportunity to investigate and remediate it.
We will not pursue legal action against a security researcher who: makes a good-faith effort to comply with this section; reports a vulnerability responsibly and confidentially; and does not exploit the vulnerability beyond what is necessary to demonstrate it.
We do not currently commit to a specific response-time SLA per severity tier, since no formal triage process has been adopted. We intend to prioritize reports broadly by potential impact (for example, unauthorized data access or account takeover would be treated with higher urgency than a low-impact configuration issue), but do not publish a formal severity-classification matrix or guaranteed response window at this time.
We do not currently operate a paid bug-bounty program or a public researcher acknowledgments page. We may consider introducing one in the future.
For an active, ongoing security incident (e.g., evidence of an active account-takeover campaign or a live data exposure), email legal@onyatrips.com with "URGENT SECURITY" in the subject line.
We may update this Policy as our security controls and processes evolve. Material changes will be reflected in an updated "Last Updated" date above.
We use analytics cookies to understand how you use Onyatrips, so we can improve it. These are optional — the site works fully without them. Learn more.