get_reservations_for_month in src/backend/reservation.rs has no perm_check!. The auth middleware protects only /admin* pages, not /api/*, so anybody can call the function with a month and a year and get all bookings of that month as ResSumWithItems: date, items, price, state, note, and the customer's full name, e-mail address and phone number.
The response also contains the uuid of every booking. Since #18 the uuid is the secret of the customer's booking page, so whoever reads it here can open that page and cancel the booking.
The function is not called from anywhere in the application (the bookings overview uses reservations_in_month); it only has to be known by its name under /api.
Proposed change
Remove get_reservations_for_month, or give it perm_check!(is_logged_in) if it is to be kept. It returns ApiResponse, so the macro fits.
Go through the other server functions without a permission check and confirm each one is public on purpose. Found by a scan of src/backend/:
To check: get_message returns any mail template to anybody (no personal data, but nothing public needs it); years and months reveal in which months there are bookings. These return plain Result<T, ServerFnError>, so they need an explicit check instead of the macro, or a change of the return type.
To check: that nothing reachable without login returns a booking uuid (get_public_form_data and its Reservation rows).
Consider a test that fails when a new server function is neither permission-checked nor on an explicit list of public ones, so this cannot come back unnoticed.
Acceptance
Calling the endpoint without a session returns no bookings (403 or the function is gone).
The bookings overview and the dashboard in the admin portal work as before.
Every server function without a permission check is on a documented list of public ones.
Note for existing installations
Customer data of installations reachable from the internet may have been read this way. Access logs of the reverse proxy show requests to /api/get_reservations_for_month….
## Problem
`get_reservations_for_month` in `src/backend/reservation.rs` has no `perm_check!`. The auth middleware protects only `/admin*` pages, not `/api/*`, so anybody can call the function with a month and a year and get all bookings of that month as `ResSumWithItems`: date, items, price, state, note, and the customer's full name, e-mail address and phone number.
The response also contains the `uuid` of every booking. Since #18 the uuid is the secret of the customer's booking page, so whoever reads it here can open that page and cancel the booking.
The function is not called from anywhere in the application (the bookings overview uses `reservations_in_month`); it only has to be known by its name under `/api`.
## Proposed change
- Remove `get_reservations_for_month`, or give it `perm_check!(is_logged_in)` if it is to be kept. It returns `ApiResponse`, so the macro fits.
- Go through the other server functions without a permission check and confirm each one is public on purpose. Found by a scan of `src/backend/`:
- Public by design: `get_appearance`, `get_remembered`, `get_hours`, `get_hours_for_day`, `get_closing_time`, `get_closing_times`, `get_properties`, `get_active_properties`, `get_public_form_data`, `create_reservation`, `get_booking`, `cancel_booking`, `login`, `logout`, `auth_check`, `admin_check`, `get_user`, `get_pow`.
- To check: `get_message` returns any mail template to anybody (no personal data, but nothing public needs it); `years` and `months` reveal in which months there are bookings. These return plain `Result<T, ServerFnError>`, so they need an explicit check instead of the macro, or a change of the return type.
- To check: that nothing reachable without login returns a booking `uuid` (`get_public_form_data` and its `Reservation` rows).
- Consider a test that fails when a new server function is neither permission-checked nor on an explicit list of public ones, so this cannot come back unnoticed.
## Acceptance
- Calling the endpoint without a session returns no bookings (403 or the function is gone).
- The bookings overview and the dashboard in the admin portal work as before.
- Every server function without a permission check is on a documented list of public ones.
## Note for existing installations
Customer data of installations reachable from the internet may have been read this way. Access logs of the reverse proxy show requests to `/api/get_reservations_for_month…`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
get_reservations_for_monthinsrc/backend/reservation.rshas noperm_check!. The auth middleware protects only/admin*pages, not/api/*, so anybody can call the function with a month and a year and get all bookings of that month asResSumWithItems: date, items, price, state, note, and the customer's full name, e-mail address and phone number.The response also contains the
uuidof every booking. Since #18 the uuid is the secret of the customer's booking page, so whoever reads it here can open that page and cancel the booking.The function is not called from anywhere in the application (the bookings overview uses
reservations_in_month); it only has to be known by its name under/api.Proposed change
get_reservations_for_month, or give itperm_check!(is_logged_in)if it is to be kept. It returnsApiResponse, so the macro fits.src/backend/:get_appearance,get_remembered,get_hours,get_hours_for_day,get_closing_time,get_closing_times,get_properties,get_active_properties,get_public_form_data,create_reservation,get_booking,cancel_booking,login,logout,auth_check,admin_check,get_user,get_pow.get_messagereturns any mail template to anybody (no personal data, but nothing public needs it);yearsandmonthsreveal in which months there are bookings. These return plainResult<T, ServerFnError>, so they need an explicit check instead of the macro, or a change of the return type.uuid(get_public_form_dataand itsReservationrows).Acceptance
Note for existing installations
Customer data of installations reachable from the internet may have been read this way. Access logs of the reverse proxy show requests to
/api/get_reservations_for_month….