addComment writes comments to non-existent / soft-deleted photo items with no length cap

Area: Files/photos (re-run) (audit p5r) · Surface: POST /photos/item/{id}/comment · Dimension: security · Severity: minor

Any authenticated user can POST a comment row keyed to an arbitrary or already-deleted item_id (the value is taken straight from the URL and cast to int). This lets a user attach comment rows to items that were soft-deleted (which then resurface if the item is ever restored) or to ids that don't exist, and store arbitrarily large bodies (DoS / storage abuse) since there is no length bound before the INSERT. This is a separate defect from the already-filed missing viewableBy check — it is the absence of any existence/deleted/length validation on the write itself.

Evidence

platform/src/Controllers/PhotoGalleryController.php:712-731 addComment(): after requireAuth + validateCsrf it does `$body = trim((string)($_POST['body'] ?? ''));` then immediately `INSERT INTO photo_comments (item_id, user_id, body) VALUES (:i,:u,:b)` with `'i' => (int)$id`. There is no PhotoAlbumItem::findById() existence check, no `is_deleted = 0` check on the target item, and no maximum-length validation on $body (contrast reportItem at line 1071-1074 which caps details at 1000 chars and validates the item exists).

Suggested fix. Load the item with PhotoAlbumItem::findById((int)$id), 404 if missing or is_deleted=1, and cap $body length (e.g. mb_substr to 2000 chars or reject longer) before the INSERT — mirror the validation already present in reportItem().

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.