Private routes stay private
App pages, user trips, settings and API routes are gated before a signed-out visitor can reach them.
Trust & security
Your trip details should stay yours.
Tripz Travel handles bookings, invites, plans and AI suggestions. That means trust has to be part of the product, not a page we bolt on later.
Tripz TravelSecurity
Trip access checked6 travellers, 1 shared trip
Signed in
Trip member
Private details hidden
Private by default
Security signals on
Data access has rules
Product code is expected to go through DAL and repository functions that check who can see or change a trip.
Browsers get stricter defaults
Tripz Travel sends CSP, HSTS, frame, content-type, referrer and permissions headers from the shared proxy.
Sensitive details get less room to leak
The codebase includes encrypted trip fields, redacted logging and startup checks for critical production wiring.
How it works
Security is mostly boring on purpose.
The useful work happens in the quiet places: strict route gates, browser headers, policy-aware data access, encrypted sensitive fields and logs that avoid spilling private trip details.
Auth first
Dashboard, trip and settings routes are not public browsing surfaces. If you are signed out, you are sent to login.
AI with boundaries
Tripz Travel documents how Copilot and AI features use trip context, with privacy policy links visible from the public site.
Reports and telemetry
The app accepts CSP reports and checks production telemetry wiring during startup so security signals do not quietly disappear.
Before wider launch
No pretend badges.
These are the production trust checks still tracked in the project docs. They need live-environment evidence before Tripz Travel talks about them as done.
External uptime probing for the public site and health endpoint
A named paging route for production incidents
Confirmed Postgres backup retention and restore settings
Written RPO and RTO targets
Plain-English docs