Subject: KitchenAsty: authenticated customers can read other customers' reservations (authorization gap in packages/server)

Hello,

I run independent verification of AI-built systems (Trenyx; the published engagements are at https://trenyx.io/audits.html). During a static read of mighty840/kitchenasty at commit e0359f73 I found one authorization gap that SECURITY.md lists in scope, so I'm sending it privately per your policy. No exploit code follows; the description is enough to reproduce.

The gap: `GET /api/reservations/:id` is wired with `authenticate` only (`packages/server/src/routes/reservation.routes.ts:30`), while the sibling list/patch/delete routes add `requireStaff`. The handler, `getReservation` (`reservation.controller.ts:105-123`), loads the reservation, checks it exists, and returns it, including the customer's name, email, and phone (selected at line 111), with no ownership comparison. By contrast `getOrder` (`order.controller.ts:427`) does this correctly: `if (user.type !== 'staff' && order.customerId !== user.id) → 403`.

Impact: Any authenticated customer account can read any reservation record, including another customer's contact details, given its id. Ids are Prisma cuids, so mass enumeration isn't practical; access via a leaked, shared, or guessed id is.

Fix: Mirror the order check in `getReservation` (`user.type !== 'staff' && reservation.customerId !== user.id → 403`), or add `requireStaff` to the route like its siblings, depending on whether customers should see their own reservations there.

Three non-security correctness gaps I noticed in passing, offered separately if useful (happy to send details): reservations are created and updated without any table/time conflict check despite the docs describing one; the stock availability check and the decrement run as separate calls with no transaction, so concurrent orders can oversell; and cancelling an order never restores stock. The test suite mocks Prisma entirely, which is why none of these show up green-to-red.

I'll follow your coordinated-disclosure timeline; my default is no public mention before a fix or 60 days, whichever comes first, and I'm glad to re-check whatever you ship. Any write-up publishes only after that, and says you fixed it.

SK
Trenyx