theme-travel-booking

name	theme-travel_booking
description	Travel / booking application palette: variants, pages, entities, and flows for building a varied reservations app. Use when theme_preset is travel_booking.

Travel booking theme

Domain

Apps that hold reservations against limited inventory and a traveler's loyalty balance. The invariants that matter — a seat/room is sold once, a fare is what was quoted, points can't go negative, you only see your own itinerary — are exactly where the interesting exploits live.

Application variants — pick ONE per lab

Honor any hint in theme_free_text / custom_prompt; otherwise pick one.

• Flight booking — search flights, seat selection, passengers, e-tickets.
• Hotel booking — room types, date-range availability, reservations, folios.
• Multi-leg trip planner — itineraries bundling flights/hotels/activities.
• Car / rental — vehicle classes, pickup/return slots, add-ons, holds.
• Loyalty-points program — earn/burn miles, tier status, reward redemption.

Roles — choose the set that fits the variant

• user (traveler) — search, book, view own itineraries, manage loyalty.
• service — inventory/availability sync, fare/points jobs where relevant.
• admin (agent / back office) — view any booking, override fares, refunds.

Most exploits run as user.

Candidate pages — select a coherent subset

Size the subset to endpoint_count. Candidates: search/results, fare or rate detail, seat/room map, passenger/guest details, checkout & payment, booking confirmation, my trips/itineraries, itinerary detail, e-ticket / boarding pass, modify or cancel booking, loyalty dashboard, rewards catalog, profile/settings, notifications, admin bookings, admin fare/inventory.

Candidate entities (seed tables) — select what the variant needs

• users — id, email, password_hash, role, loyalty_tier
• bookings — id, user_id, kind, status, total_cents, currency, created_at
• passengers / guests — id, booking_id, name, dob, document_no
• inventory — id, kind, code, capacity, remaining, starts_at, ends_at
• fares / rates — id, inventory_id, class, price_cents, refundable
• seats / rooms — id, booking_id, inventory_id, label, status (held/booked)
• payments — id, booking_id, amount_cents, method, status
• loyalty_accounts — id, user_id, points_balance, tier, lifetime_points
• loyalty_txns — id, loyalty_account_id, delta_points, reason, created_at
• rewards (loyalty) — id, name, cost_points, kind, stock
• trip_segments (planner) — id, booking_id, kind, ref_id, order, starts_at

Seed multiple travelers each with ≥2 bookings and a loyalty balance so cross-account and points exploits are possible.

Candidate user flows — select the ones matching chosen pages/features

1. Search → pick a fare/rate → enter passengers → pay → confirmation.
2. Open my trips → view an itinerary → download the e-ticket / boarding pass.
3. Modify a booking (change date/seat) → repriced → balance updates.
4. Cancel a refundable booking → refund issued → status updates.
5. Select a specific seat/room from the map → it's held, then booked.
6. (loyalty) Earn points on a booking → redeem points for a reward.
7. (planner) Build a multi-leg trip → add a hotel + activity → checkout as one.
8. (admin) Look up any booking → override a fare or force a refund.

Candidate endpoints — a feature may span several

Endpoints are a shared surface, not owned 1:1 by a feature (a single feature often spans several, and an endpoint can back multiple features). Pick a coherent subset alongside the pages above. Grouped by area:

• search / inventory — GET /api/search, GET /api/inventory/{id}, GET /api/inventory/{id}/availability
• bookings — POST /api/bookings, GET /api/bookings, GET /api/bookings/{id}, PATCH /api/bookings/{id}, POST /api/bookings/{id}/cancel
• seats / rooms — GET /api/inventory/{id}/seats, POST /api/bookings/{id}/hold, POST /api/bookings/{id}/seats
• tickets — GET /api/bookings/{id}/ticket, GET /api/bookings/{id}/boarding-pass
• payments — POST /api/bookings/{id}/pay, POST /api/bookings/{id}/refund
• loyalty — GET /api/loyalty, POST /api/loyalty/redeem, GET /api/rewards
• admin — GET /api/admin/bookings/{id}, POST /api/admin/bookings/{id}/override, POST /api/admin/bookings/{id}/refund

Where vulnerabilities fit naturally

• idor → GET /api/bookings/{id}, /api/bookings/{id}/ticket, /api/bookings/{id}/boarding-pass — read another traveler's itinerary/PII/document numbers.
• business_logic → redeem more points than held, negative/zero points delta, reprice abuse on modify, refund a non-refundable fare, apply a promo twice.
• race_condition → two users hold/book the last seat or room concurrently; redeem the same points twice before the balance settles.
• auth_bypass → reach checkout, cancel, or refund without a valid session.
• privilege_escalation → user reaching /api/admin/... fare-override or refund actions.
• idor/business_logic → set another traveler's booking_id on a cancel/refund.

Diversity guidance

Pick ONE variant and a coherent subset — a flight app and a hotel app should not share a page list. Size to endpoint_count; let theme_free_text / custom_prompt bias the variant, currencies, and naming. Vary cabins/room types, loyalty tiers, and cancellation rules so two travel labs feel like different brands.