>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3625422. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !356 >>> <p>A read of the whole module found places where the tenant boundary, the permission model or the booker's browser is trusted further than the rest of the code trusts them. Each one is a door the module already guards everywhere else.</p> <h3>Tenant and permission boundaries</h3> <ul> <li><strong>Managers' booking queries are never narrowed.</strong> <code>ManagerHooks</code> implements <code>query_yoyaku_access_alter</code>, but booking entity queries carry the tag <code>yoyaku_booking_access</code>, so the hook never fires: an access-checked booking query run by a resource manager (autocomplete, Views, an order spanning resources) returns bookings of resources they do not manage.</li> <li><strong>The orders view shows every tenant's orders.</strong> <code>views.view.yoyaku_orders</code> is opened to resource managers and per-tenant order managers on the promise that "the entity query still scopes what each one sees", but nothing implements <code>query_yoyaku_transaction_access_alter</code>, so a tenant-A order manager reads tenant B's orders with the booker's name and email. The native overview hides the rows one by one in <code>buildRow()</code>, which also leaves its pager counting rows it never shows.</li> <li><strong>Canceling is checked as editing.</strong> <code>OrderActionBase::access()</code> asks <code>update</code> for every action and the route <code>entity.yoyaku_transaction.cancel</code> requires <code>yoyaku_transaction.update</code>, while <code>OrderAccessControlHandler</code> makes cancel its own operation needing "cancel booking". An order manager without that permission cancels through the "Cancel order" action or the order's Cancel link.</li> <li><strong>A public route books another tenant's slot.</strong> The calendar and placement routes check the permission and the booking channel, never the tenant. On tenant B's domain, <code>/booking/availability/{resource of A}</code> serves A's availability and <code>/booking/slot/{slot of A}/claim</code> holds A's places, and <code>HoldEngine</code> then stamps the new order with A's tenant. Check-in has the same gap: a door operator of one tenant completes another tenant's ticket.</li> <li><strong>Access results do not vary by tenant.</strong> <code>YoyakuAccessControlHandler</code>'s answer depends on the tenant the domain resolves but carries only the <code>user</code> cache context (its comment says a tenant context does not exist; the booking channel has one), so a cached list or operations link built for an operator on one tenant's domain is served on another's.</li> <li><strong>Admin selects list every tenant's rows.</strong> <code>ResourceOptionsTrait::getResourceOptions()</code>, the calendar block form and <code>PlaceBookingForm</code> load every resource or slot of the site with no tenant condition and no access check.</li> <li><strong>The pinning map trusts a hidden field.</strong> <code>PinnedPlaceMapForm</code> saves the place and allotment ids the browser writes into <code>assignments</code> with <code>save()</code> and no <code>validate()</code>, so an edited field pins a seat of another venue or holds places for another tenant's allotment.</li> </ul> <h3>Requests the booker's browser can be made to send</h3> <ul> <li><strong>Check-in completes a booking on a GET.</strong> <code>/yykc/{token}</code> completes the bookings its token names while building the form. Any image, iframe or link preview a logged-in door operator's browser loads marks that ticket used, and its holder is refused at the door.</li> <li><strong>The SVG scanner lets script through.</strong> <code>MapBackgroundSvg::getScriptedConstructs()</code> is the only check on a venue illustration that <code>venue-map.js</code> inserts into every booking map. An event handler written straight after a slash in an <code>svg</code> tag, one written straight after a closing quote on an <code>image</code>, and a <code>javascript</code> URL scheme spelled with a numeric character reference or with a named entity for its colon all come back clean: the handler pattern needs whitespace before <code>on</code>, and the URL checks read the text before the parser decodes its entities. Ticket logos also accept SVG into <code>public://</code>.</li> <li><strong>A venue package skips validation.</strong> <code>VenueImporter</code> saves every entity with <code>save()</code> and never <code>validate()</code>, so a grade color that closes the style attribute and opens an <code>img</code> element with an error handler reaches the legend <code>venue-map.js</code> builds with <code>innerHTML</code> (and the downloaded layout's <code>style</code> element); two packages keeping the default <code>map_background.svg</code> share one file, so arranging either hall repaints the other; and a grade, section or configuration key is unique within its venue only on the form.</li> <li><strong>Filter URLs carry the operator's CSRF token.</strong> <code>FilterFormBase</code> is a GET form that keeps Form API's <code>form_token</code>, <code>form_build_id</code> and <code>op</code>, so the "shareable" filtered URL carries the session's token into history, logs and Referer headers.</li> </ul> <h3>Proposed resolution</h3> <p>Implement <code>query_yoyaku_booking_access_alter</code> and <code>query_yoyaku_transaction_access_alter</code>; ask the <code>cancel</code> operation on the action and the route; refuse a resource or slot of another tenant in the booking-channel access check and in check-in; add a <code>yoyaku_tenant</code> cache context and put it on every tenant-scoped result; scope the admin option lists by tenant and access; accept only ids of the pinning's venue and tenant and validate before saving. Complete a check-in on GET only for a navigation the operator made (<code>Sec-Fetch-Site</code> none or same-origin), and ask for a confirmation otherwise. Decode entities before scanning an SVG, match handlers after any non-name character, and refuse SVG for ticket logos. Validate every imported entity, write each background under its venue's own name, and add a key-uniqueness constraint per venue. Take the token, build id and op out of the filter forms.</p> <h3>Verification</h3> <p>Each item has a test that fails against 1.x and passes with the change: a manager's access-checked booking query and the orders view return only what the account may see; the cancel action and route are refused without "cancel booking"; a slot of another tenant is refused on the served tenant's route and at the door; the access result carries the tenant context; the pinning map refuses a place of another venue; a cross-site GET of a check-in link completes nothing; the four SVG payloads are reported; an imported grade color that is not hex is refused, and two imported venues get two files; the filter form has no token.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)</p>