Should a marketplace let providers upload documents that customers can download directly?

Introduction

Marketplaces connecting providers and customers often face the question: should providers upload documents that customers can download directly? This article addresses this question with a focus on secure access, document visibility, and operational clarity. By defining a marketplace-document visibility model, founders and product owners can make informed decisions on document handling that balance usability and security.

1. Distinguish Public Proof from Private Verification Documents

Providers may upload various document types: public proof approved for release (e.g., a redacted credential summary or brochure) and private verification files (e.g., contracts, sensitive reports). Public proof documents can be accessible to all customers or even the general public, while private documents require strict access controls.

Decision: Categorise documents into public and private buckets. Public documents can be stored in public storage with accessible URLs. Private documents must reside in protected storage with access governed by authentication and authorisation.

2. Define User Roles and Access Permissions

A marketplace typically involves at least three roles: providers, customers, and administrators. Each role requires different document access levels.

• Providers: Upload and manage their own documents.
• Customers: Download documents linked to their transactions or relationships.
• Authorised verification/support staff: Access only documents required for their assigned duty, with separate finance and verification privileges.

Decision: Implement role-based access control (RBAC) ensuring customers only access documents linked to their accounts or transactions. Providers manage their own files but cannot access others'.

3. Use Signed URLs with Expiry for Secure Downloads

Direct public URLs expose documents to unauthorized access. Signed URLs provide bearer access subject to the storage and cache behaviour; they are not a guarantee that copied or cached content disappears at expiry.

Technical note: Signed URLs are bearer tokens granting temporary access to private files. Their expiry limits risk if URLs leak. Supabase storage, for example, supports creating signed URLs with expiry times.

Decision: Generate signed URLs for customer downloads with an adopted sensitivity-based expiry (the example durations here are hypothetical), balancing user convenience and security.

4. Implement Server-Side Authorization Checks

Relying solely on signed URLs is insufficient because URLs remain valid until expiry, even if user access changes.

Best practice: Enforce server-side checks on every document access request to verify the user's current authorization before generating or serving a signed URL.

This aligns with OWASP authorization principles to avoid broken access controls.

5. Test Document Links Under Each User Role

Before launch, test all document access scenarios:

• Providers uploading and accessing their documents.
• Customers downloading authorized documents.
• Attempts to access unauthorized documents by any role.

Testing should cover expired links, revoked access, and edge cases such as role changes.

6. Handle Document Expiry and Revocation

Choose access duration separately from retention. A 30-day access period is an invented policy example; contracts may need different retention and access rules.

Proposed policy: Store document metadata including upload date, access expiry, and associated user IDs. Implement automated expiry handling that stops new access grants at expiry; delete only under a separately reviewed retention and recovery policy.

Revocation of signed URLs is complex; caching and bearer token nature mean immediate revocation is not guaranteed. Plan accordingly.

7. Protect Against Privilege Escalation and Data Leakage

Ensure that authorization logic strictly enforces least privilege:

• Customers cannot access other customers’ documents.
• Providers cannot access documents of other providers.
• Admins have oversight but should have audit trails.

Use database row-level security (RLS) policies and storage access controls to enforce these rules.

8. Align Document Handling with Marketplace Platform Architecture

Marketplace platforms often integrate payment, booking, and fulfilment systems. Document access should be tied to transaction states (e.g., payment confirmed).

Integration tip: Link customer-facing transaction documents to an authorised relationship and an appropriate state. Verification files can remain staff-only even after payment, and a customer may need a draft contract before completion.

Refer to Symaxx’s Marketplace Platform Development guide for architecture best practices.

Practical Output: Marketplace-Document Visibility Model

How to use:

1. Classify documents upon upload.
2. Assign storage bucket accordingly.
3. Enforce user role checks before generating signed URLs.
4. Set expiry based on document sensitivity.
5. Regularly audit access logs.

Worked example:

Provider uploads a contract document linked to customer order #123.

• Stored in private bucket.
• Customer #456 authenticated requests download.
• Server verifies customer #456 is linked to order #123.
• Server generates signed URL valid for 12 hours.
• Customer downloads document.
• After 12 hours, the token's expiry rule applies to new origin access. A previously warmed same-token CDN response can persist until its cache lifetime ends; issuing a new link requires a fresh authorization check.

9. Implement Row-Level Security (RLS) for Document Access Control

Row-Level Security (RLS) in your database is essential to enforce fine-grained access control for documents in a marketplace. It allows you to define policies that restrict which rows (documents) a user can access based on their identity and relationship to the document.

Action steps:

• Enable RLS on your documents table.
• Create policies that allow:
  • Providers to access only documents they uploaded.
  • Customers to access only documents linked to their transactions.
  • Staff to access only documents permitted by their specific verification/support duty.

Decision evidence: Supabase supports RLS tightly integrated with its authentication system, allowing you to write policies using the authenticated user's ID.

Recorded fields: Ensure your document metadata includes owner_id (provider user ID), customer_id (linked customer), and transaction_id for precise policy enforcement.

Expected results: Unauthorized users cannot query or download documents not linked to their account. This reduces risk of data leakage and privilege escalation.

Recovery steps: Regularly audit RLS policies and test with different user roles to detect and fix any access leaks. Use logging to monitor unauthorized access attempts.

10. Automate Document Expiry and Access Revocation

Managing document lifecycle is critical, especially for private verification documents.

Proposed operating rules:

• Store upload_date and access_expiry timestamps in document metadata.
• Run scheduled jobs (e.g., daily cron) to:
  • Stop new application download grants after the adopted access deadline. Updating metadata or hiding links does not revoke an already issued bearer URL or cached copy.
  • Delete documents only under the adopted retention, recovery and review procedure; access expiry alone is not a deletion instruction.

Decision evidence: Link expiry and application revocation have provider-specific limits; inspect cache behaviour as well as token validity.

Recorded fields: Maintain audit logs of expiry actions, including document ID, user IDs affected, and timestamps.

Expected results: New access grants are denied after the adopted deadline. Already issued, cached or downloaded copies require separate consideration; this is not proof of compliance.

Recovery steps: If a document is mistakenly expired or deleted, restore from backups and notify affected users.

Worked Hypothetical Case: Document Access Workflow in a South African Marketplace

Scenario: A marketplace connects local service providers with customers. Providers upload contracts and certification documents. Customers should download contracts related only to their orders.

Step 1: Document Upload

• Provider P123 uploads a contract file for order O789 linked to customer C456.
• Metadata stored: owner_id = P123, customer_id = C456, transaction_id = O789, upload_date = 2024-05-01, access_expiry = 2024-05-31.
• Document stored in a private bucket.

Step 2: Customer Access Request

• Customer C456 logs in and requests to download the contract for order O789.
• Server verifies C456 is linked to O789 and that access_expiry is not passed.
• Server generates a signed URL valid for 12 hours.

Step 3: Download and Expiry

• Customer downloads the document via the signed URL.
• At the 12-hour token expiry, new origin access follows the provider's expiry rule; a warmed same-token CDN response may persist for its independent cache lifetime. A fresh link requires authorization.
• After the hypothetical 31 May 2024 application deadline, the server denies new download grants. Previously issued bearer links and cached copies follow their separate token/cache limits.

Acceptance tests:

• Customer C456 can download the document before expiry.
• Customer C999 (not linked to O789) cannot access the document.
• Provider P123 can view and manage their uploaded documents.
• Authorised staff can view the specific documents their duty permits.
• New origin requests are evaluated under token expiry; also test a previously warmed same-token cache.
• New links denied after access_expiry; existing cached responses tested separately.

Failure tests:

• An uncached origin request with an expired token must fail under the provider contract; record actual status instead of assuming 403.
• Attempt by unauthorized user returns 403 Forbidden.
• A new application grant after access_expiry is denied; a direct previously issued URL has its own expiry/cache behaviour.

Expected recovery:

• If a user reports inability to access a valid document, verify server logs and metadata.
• If document expired prematurely, restore access by updating access_expiry.
• If deleted, restore only from a separately verified object-storage backup; a database backup may contain metadata but not file bytes.

Worksheet for Document Access Policy Implementation

Use this worksheet to track and enforce document access policies systematically.

---

For more on marketplace platform architecture and secure document workflows, consult Symaxx’s Marketplace Platform Development resources.

Separate application expiry, token expiry and cached copies

Supabase's authenticated-download guidance distinguishes private access with an authorised download request from signed URL delivery. Authorise the tenant, actor, document and permitted action before issuing a link. Once issued, a bearer link can be used by someone who obtains it without repeating that application check.

Supabase's Smart CDN documentation explicitly states that token expiry and cache duration are independent. A warm cached response can continue to be served for the same signed URL after token expiry. Deleting the object invalidates cached entries, but propagation can take up to a minute; browser or previously downloaded copies may remain. Do not promise an immediate cutoff based on metadata or a short signed URL alone.

For sensitive files requiring a current permission check on every request, review a controlled authenticated delivery/proxy design and its cache policy. This still cannot revoke a file already downloaded. Decide which documents should never be made public or delivered through reusable bearer links.

Supabase storage access controls use policies on storage objects for permitted operations. A document metadata row policy does not automatically secure every file-serving path. Public buckets expose retrieval publicly, and privileged service keys bypass policies. Test the object path, new link issuance and direct old link independently.

OWASP authorization guidance supports permission checks on each request. Add upload quarantine, size/type checks, malware scanning where applicable and publication approval before a provider's file becomes public. Treat scanned status and credential validity separately: a harmless file is not proof of a genuine credential.

Extra visibility-model fields

Record tenant ID, document purpose, sensitive classification, quarantine/review state, authorised relationship, storage path, version, application access deadline, retention rule and signed-link/cache policy. Test cross-tenant download, provider replacement of a reviewed file, staff downgrade and a link warmed before revocation. Durations such as 12 hours or 30 days in this hypothetical example are proposed choices, not recommended universal limits.

Frequently asked questions

Should documents be accessible without login?

Public proof documents can be accessible without login if non-sensitive. Private or sensitive documents must require authentication and authorization.

How can I revoke access to a document immediately?

Immediate revocation of signed URLs is difficult due to caching and bearer token nature. Consider short expiry times and server-side checks before issuing URLs.

What if a provider uploads malicious files?

Implement file type validation, virus scanning, and content moderation to mitigate risks.

Can customers upload documents?

If your marketplace model requires customer uploads, apply similar access control and storage policies to customer files.

Conclusion and Recommendation

Allowing providers to upload documents for direct customer download is feasible and beneficial if managed with clear document categorisation, strict access controls, and expiry policies. Separate public from private documents, enforce role-based access, use signed URLs with expiry, and test thoroughly. This proposed model needs role, upload and cache tests; it does not prove security or compliance.

For detailed platform development guidance, see Symaxx’s SaaS Development and Marketplace Platform resources.

If your business needs help designing secure document workflows in a marketplace, get in touch with Symaxx to explore tailored solutions.

---

Also see Symaxx guides on CMS vs Custom Development, Discovery Phase Checklist, and User Journey for broader product design insights.

Sources

• Supabase storage access control
• Supabase authenticated downloads
• Supabase Smart CDN
• OWASP authorization guidance