Your agency’s operation, in one system.
Bookings, suppliers and travel operations in one system.
Multi-tenant SaaS · E2E testing · Role-based access control
What changes.
Context
A destination management company runs itineraries, suppliers and bookings for several clients at once.
What I learned
That the interface hides, but does not protect.
How it was built.Decisions, evidence and details
Context
A destination management company runs itineraries, suppliers and bookings for several clients at once. The system is multi-tenant: every operation must be isolated from the others, and each person must see only what their role allows. The production version is v1.16.1.
The finding
- Automating an end-to-end test cycle surfaced several routes reachable by typing the URL directly, without going through the corresponding role.
- The menu did not show them to people who should not see them, which is the protection often mistaken for security: hiding a link does not close a door.
- The fix was to return 404 according to role, so the route does not even confirm it exists.
What stayed
- Multi-tenant isolation suites organised in phases, checking that one tenant cannot reach another's data.
- Protected routes answer 404 by role instead of revealing their existence with an access-denied message.
- The E2E cycle became part of the process, not a one-off exercise.
What I learned
That the interface hides, but does not protect. If a route exists and answers whoever types its address, it is open even though no button leads to it. And that a well-built automated test cycle does more than prevent regressions: it finds things nobody thought to look for.