fix(documents): enforce content-type whitelist on S3 presigned URL generation (#1439)

[Awosdot]

What changed

• Added server-side validation in backend/src/services/documents.ts to restrict presigned URL requests strictly to image/* and application/pdf content types[cite: 10].
• Updated S3 POST policy conditions to enforce ['starts-with', '$Content-Type', 'image/'] and ['starts-with', '$Content-Type', 'application/pdf'] restrictions[cite: 10].
• Configured error handling to reject invalid content types with HTTP 400 and INVALID_CONTENT_TYPE[cite: 10].
• Added integration tests requesting presigned URLs for unauthorized types (e.g., text/html) to confirm HTTP 400 rejection[cite: 10].

Why

Generating presigned upload URLs without content-type restrictions allowed users to upload arbitrary HTML or executable shell scripts, enabling stored XSS attacks when documents were fetched via GET /vaults/:id/documents/:docId[cite: 10].

How tested

• Ran integration test suite verifying that text/html upload requests return HTTP 400 with INVALID_CONTENT_TYPE[cite: 10].
• Confirmed existing PDF and image document upload flows pass cleanly[cite: 10].

Closes

Closes #1439

[drips-wave]

@Awosdot Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits