auditing-presigned-url-scope-abuse

Auditing presigned URL scope abuse: when the signature grants more than the request

A presigned URL turns a server-side permission into a standalone credential: once minted, it grants whatever the signature covers to anyone holding the URL, with no further authorization check at the store. That is convenient and precisely why it leaks. If the service signs a key the caller supplied without confirming the caller owns it, the URL reads or writes another user's object. If the signed policy leaves the key prefix, the HTTP method, the content type, or the expiry looser than the request needed, the holder does more than intended: reads a sibling object, overwrites a path they were only meant to read, or replays the URL long after it should have died. The signer's own identity matters too, because the URL inherits its permissions, not the caller's. You audit these by comparing the signed scope against the caller's actual entitlement.

When to use

• A service mints presigned object-storage URLs so clients read or write a store directly.
• The object key, prefix, bucket, or upload parameters in a presign request come from the caller.
• Presigned URLs are returned to browsers or third parties where they can be inspected, edited, or replayed.

Scope check

Test presigned-URL handling only against storage and applications you own or are authorized to assess, on non-production data. A confirming request reads or writes real objects, so stay inside the authorized bucket and account and never touch another tenant's data outside an owned test fixture. If you can't name the authorization, stop.

The loop

1. Establish the caller's real entitlement first. Before inspecting any signature, determine what object or prefix this authenticated caller is actually allowed to read or write. This is the false-positive killer: a presigned URL scoped exactly to what the caller owns is correct no matter how powerful presigning looks. Name the entitlement, then compare the signed scope to it.