Security gate FAIL (Barkley, CTO-ratified): the portal pet PATCH mapped
`body.photoUrl -> updateData.photoKey` with no validation. photoKey is a
trusted S3 object key consumed server-side by getPresignedGetUrl (read) and
deleteObject (destructive); the upload path (pets.ts) already guards keys with
a pets/{petId}/ prefix to prevent hijacking. The portal PATCH bypassed that
guard, letting an authenticated customer point their pet's photoKey at any
object key (cross-tenant disclosure/destruction on a later staff action).
Fix (per CTO directive — smallest safe surface):
- Remove `photoUrl` from portalPetUpdateSchema and delete the
`updateData.photoKey = body.photoUrl` mapping. Photo changes already have a
dedicated, key-validated flow (upload + /photo/confirm). The web form's
round-trip of the GET-shaped photoUrl is a no-op (Zod strips the unknown key).
- LOW hardening: cap preferredCuts (string max 2000, array max 50),
medicalAlerts (array max 50) and medicalAlert type/description (max 2000),
mirroring the existing free-text max(2000) caps.
Tests:
- New regression: foreign photoUrl on portal PATCH returns 200 but leaves
photoKey unchanged (gate evidence).
- New: over-long medicalAlert description rejected (400, zValidator).
- Updated the existing "persists mapped columns" test: photoKey is no longer
written by the portal PATCH.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Savannah Savings