TourPro stores some of the most sensitive data a touring operation handles: passport numbers, flight details, contacts, and the day-to-day movements of your whole team. This page describes the specific mechanisms we use to protect it, what we rely on, and how to report a vulnerability. We prefer listing real controls over making generic claims.
Field-level encryption for sensitive PII. Passport numbers, medical notes, and emergency contact details are encrypted with AES-256-GCM at the application layer before they reach the database, so these fields are ciphertext even inside our datastore, not just on the underlying disk.
Encrypted offline database on desktop. The desktop app's local offline database is encrypted at rest. The encryption key is generated randomly on each device and stored only through the operating system's credential store (Keychain on macOS, DPAPI on Windows, libsecret on Linux).
Encryption in transit. All client-to-server traffic uses TLS. Our desktop and mobile apps only connect to our configured HTTPS endpoints.
Encrypted storage at rest. Our hosted database and file storage are encrypted at rest by our infrastructure providers.
Mobile apps store session tokens in the operating system's secure enclave storage (iOS Keychain, Android Keystore), never in plain app storage.
The desktop app keeps its offline sync token in memory only. It is never written to disk.
Signing out or switching accounts on desktop wipes local cached tour data, so shared machines do not leak the previous account's information.
Data is scoped per tour. Access is enforced server-side through per-tour permission keys (for example, who may edit schedules, manage billing, or invite members), not just hidden in the UI.
Authentication is delegated to Auth0 with short-lived JWTs verified on every API request.
Team administrators can remove members at any time, and access is revoked at the permission layer.
All database queries are parameterized; user input never reaches SQL strings.
Tiered rate limiting on authentication, token, upload, AI, and public endpoints.
The desktop app denies all device permission requests by default. Only notifications and clipboard writes are permitted; camera, microphone, geolocation, and hardware access are refused and logged.
Desktop navigation and external links are restricted to an allowlist of TourPro and Auth0 origins, and IPC calls are schema-validated and payload-capped.
Product analytics are off by default. You opt in explicitly in Privacy Settings.
When session replay is enabled, all text inputs and images are masked by default in recordings.
Synthetic probes continuously exercise production login, API health, and flight search, alerting our team when real user journeys break.
Current service status is published at statuspage.incident.io/tour-pro, where incidents are opened and resolved automatically by our monitoring.
If you believe you have found a security vulnerability, email security@tourpro.app (or info@tourpro.app). Please include steps to reproduce and avoid accessing or modifying other users' data. We aim to acknowledge reports within 3 business days and will credit researchers who follow coordinated disclosure.
Our disclosure coordinates are also published at /.well-known/security.txt.
Device-level protection: on mobile and desktop, the device itself is the security boundary for a running session. We strongly recommend keeping full-disk encryption (FileVault, BitLocker, or device encryption) enabled.
We are honest about scope: traffic between your device and our servers is not end-to-end encrypted, so the service can process your data to provide features like search, imports, and shared schedules.
Subprocessors: our infrastructure providers (hosting, database, authentication, analytics) process data under their own security programs. A current list is maintained in our security documentation.