This page describes the security posture of SimilarTours in plain language. We are a comparison site, not a transaction processor - the most security-sensitive actions (payment, booking) happen on partner sites, not ours. The information below covers what happens when you use SimilarTours itself.
In transit
- HTTPS only - every request to similartours.com is served over TLS.
- HSTS preload is enabled with a 2-year max-age + includeSubDomains. After the site is added to browser preload lists, browsers refuse plain HTTP entirely.
- HTTP/2 + HTTP/3 (QUIC) supported via the Vercel edge.
In the browser
- Content Security Policy with an explicit allowlist of script + style + image origins. Currently in Report-Only mode while we tune for upstream vendors; flipping to enforced after a one-week soak.
- Strict response headers:
X-Content-Type-Options: nosniff,X-Frame-Options: SAMEORIGIN,Referrer-Policy: strict-origin-when-cross-origin,Cross-Origin-Opener-Policy: same-origin, and a restrictive Permissions-Policy (camera/microphone disabled, geolocation reserved for self). - Authentication tokens are stored in browser
localStoragevia Supabase Auth and tied to a Google OAuth flow - we never see or store your Google password.
In the database
- Postgres on Supabase, with Row-Level Security enabled on every table. The anon key shipped to browsers can only read/write what RLS policies explicitly allow.
- Service-role keys (which bypass RLS) never touch the client bundle and only run inside Supabase Edge Functions or the Next.js server runtime.
- Daily backups + point-in-time recovery via Supabase. We test restores periodically; the procedure is documented in our runbook.
Secrets + API keys
- Tour-partner API keys are server-side only - stored as Supabase Edge Function secrets and never bundled into client JavaScript.
- Environment variables are validated at startup via a zod schema; misconfiguration fails the deploy rather than silently leaking defaults.
- Source code is not committed alongside
.envfiles;.envis gitignored. CI does not log secret values.
Affiliate tracking + click-out
Every booking link points at /api/click/[provider]/[id]?to=.... The handler validates the target URL against a per-provider hostname allowlist - only the booking partner's official domain is accepted for that partner's clicks - before redirecting. This blocks open-redirect abuse and prevents arbitrary URLs being injected into our click-out flow.
Vendor list
See the Data Processing Agreement for the full sub-processor list. Briefly: Supabase (database + auth), Vercel (hosting), Google Analytics + Microsoft Clarity (analytics, behind consent), and our booking partners.
Reporting a vulnerability
If you believe you've found a security issue with SimilarTours, please email hello@similartours.com with the subject line [SECURITY]. Include reproduction steps and what you tried. We aim to acknowledge within 48 hours and remediate critical issues within 7 days.
We don't run a paid bug-bounty today but we credit researchers who report responsibly. We ask that you don't access user data beyond what's needed to demonstrate the issue, and that you don't publish details until we've had a reasonable window to fix.
What we are not
We are not SOC 2 / ISO 27001 certified - we're small and these certifications aren't proportionate to what we do today. If your use case requires one, please reach out so we can talk about timelines.