What looked correct
The support flow worked as expected. Users could submit issue reports with optional authentication, and attachments uploaded successfully. In demos and normal usage, everything behaved like a standard support feature with flexible access.
Context
This lived in a customer support pathway where users could submit issues and optionally attach screenshots. The backend used a privileged storage client to handle file uploads, a common pattern for server-side file management.
What actually happened
The endpoint allowed unauthenticated requests, but still executed file uploads through a privileged storage client. This meant anonymous users could indirectly trigger backend operations with elevated permissions. The system behaved correctly from a feature perspective, but violated the intended trust boundary between anonymous users and privileged backend actions.
Why it was missed
Each piece of the system looked valid in isolation. Anonymous support submission is a reasonable requirement. Using a privileged storage client on the server is also standard practice. The failure only appears when these two decisions interact. Typical testing confirmed that uploads worked, not whether anonymous requests were exercising elevated backend capabilities.
Why it matters
This creates a broader blast radius than expected:
- anonymous users can trigger privileged backend actions
- storage can be written to without identity or ownership guarantees
- abuse or unintended usage becomes harder to control
- the system gives a false sense of security because guarded patterns exist elsewhere
- trust boundaries are inconsistent across similar endpoints
Outcome
The system was corrected to align privilege with identity. Privileged storage operations now require explicit authentication or are routed through constrained paths for anonymous input, ensuring backend authority matches the intended trust boundary.