Export Data Leaks in SaaS: How CSV and PDF Jobs Expose Tenant Records

How SaaS export jobs, signed URLs, retries, storage keys, and report generation can leak wrong tenant records when files are not tenant-bound.

Export Data Leaks in SaaS: How CSV and PDF Jobs Expose Tenant Records

Exports are dangerous because they run outside the normal request path, survive longer than the session, and are easy to reuse accidentally.

The UI might show the right tenant boundary. The background job that creates the file might not. A valid CSV or PDF can still contain the wrong tenant’s records.

That is how CSV, PDF, and signed download flows end up returning wrong tenant records even when the interactive API still looks safe.

If you want the commercial test for this path, use the Export Data Leak Audit and keep it aligned with the multi tenant security audit hub.

Need this tested in your SaaS?

We test request-level evidence, tenant boundary testing, and a clear audit report so you can see whether the export path is actually scoped.

What changes when data leaves the live request

The live UI request usually carries the full context:

  • user identity
  • tenant identity
  • role
  • filters
  • session

The export worker often gets less:

  • a report ID or export ID
  • a user ID
  • a file path
  • a queued payload

That is where the boundary gets weaker. The file can still look valid while the tenant data inside it is wrong.

  • the storage path may not include tenant ID
  • the download endpoint may trust file ID too much
  • signed URLs can outlive the session that created them
  • retries may regenerate data under the wrong context

Why export flows fail

Export leakage usually comes from a separate execution path:

  • queued jobs without tenant ID rely on user context that no longer exists when the worker runs
  • report templates use broader queries than the UI list, so the export sees more rows than the page
  • signed URLs are not tied to tenant and actor, which makes direct file access easier to reuse
  • shared bucket paths let files collide or be reused across tenants
  • retry and retry-all flows regenerate output without rechecking the original tenant scope
  • stale files are reused after tenant switch because the old artifact was never invalidated
  • exports use different query logic from the UI, so the visible list and the downloaded file disagree

The file looks legitimate because the output format is valid. The tenant boundary is what is wrong.

SaaS failure examples

Concrete failures usually look like this:

  • Tenant A CSV includes Tenant B rows, so the file is valid but the contents are cross tenant
  • PDF summary includes global totals, which reveals business data that the UI never showed
  • signed download link works after session switch because the URL is still accepted even though the active session changed
  • export retry delivers a file created for another tenant because the retry path reused the wrong job scope
  • file ID is guessable or accepted without file ownership check, so the download route exposes the artifact to the wrong requester
  • scheduled export email sends mixed tenant data because the report job combined separate customer scopes
  • admin export path reuses customer export logic incorrectly and leaks data through a shared template or queue

Where tenant scope gets lost

The leak usually happens in one of these places:

  • background job payload stores user ID but not tenant ID
  • export query rebuilds filters without a mandatory tenant constraint
  • storage key uses report ID but not tenant ID
  • download route checks authentication but not file ownership
  • signed URL grants direct object access without an app-level recheck
  • cache or reuse layer returns an old generated file
  • worker runs with service permissions and forgets customer scope

What safe export handling should enforce

Safe export handling is mostly about keeping the file bound to the tenant from start to finish:

  • tenant ID in the job payload
  • tenant ID in the export query
  • tenant ID in the storage key or metadata
  • actor ID and role in the audit log
  • file ownership check before download
  • short lived signed URLs
  • one tenant per generated file
  • server side scoped query generation
  • separate authorization for the export action
  • retest after remediation

Request-level tests for export leaks

Test the export path like a boundary problem:

  1. generate the baseline export under Tenant A
  2. replay the same export request under Tenant B
  3. mutate the report ID, file ID, tenant ID, date range, and role
  4. inspect the CSV or PDF contents, not only the response status
  5. verify the download link cannot be reused across tenants
  6. verify an expired signed URL is rejected
  7. verify the retry path keeps the same tenant scope
  8. verify a scheduled export uses the correct tenant context
  9. verify audit logs record actor, tenant, report type, file ID, timestamp, and download action

Fix direction after a failed export test

  • tenant-aware export jobs
  • tenant ID carried in job payloads
  • tenant-bound storage keys and metadata
  • scoped download authorization
  • file ownership checks before download
  • short lived signed URLs
  • export queries generated server side from scoped tenant context
  • separate authorization for export actions
  • audit logs for export generation and download
  • retest the same failed export path after remediation

When this deserves an audit

Export flows should be reviewed before launch, after reporting or export changes, before enterprise buyer review, or when files are generated outside the normal request path.

The risk is highest when CSVs, PDFs, signed URLs, scheduled exports, retries, shared storage paths, or background workers are involved.

A good audit should prove whether the generated file, storage path, download route, and audit trail all stay bound to the intended tenant.

What evidence belongs in the audit report

A useful report should show:

  • baseline tenant, actor, export type, and filters
  • mutated tenant, role, report ID, file ID, or date range
  • expected tenant boundary
  • actual CSV or PDF contents or download behavior
  • affected file path, storage key, job payload, or download route
  • signed URL lifetime and ownership behavior if relevant
  • whether the leak came from worker scope, query scope, storage path, retry flow, or download authorization
  • audit log behavior for export generation and download
  • severity and business impact
  • remediation note
  • retest result after the fix

Need a SaaS security review?

Check where authorization, tenant boundaries, and audit trails can fail before they turn into an incident.

Test your SaaS for authorization issues See how SaaS systems fail at scale

SaaS Security Cluster

This article is part of our SaaS security architecture and audit series.

SaaS Security Architecture: A Practical Engineering Guide