If your Node.js SaaS generates AI reports and serves them via signed URLs, you are likely treating object keys as authorization tokens. That is a mistake. A new governance checklist published on DEV.to by Liam Foster argues that private object storage must be paired with strict application-level tenant verification before any link is minted. The core premise is simple but frequently ignored: the database owns the relationship between a tenant and a report, not the storage path.

The Authorization Boundary

The checklist emphasizes that a prefix like tenants/t-184/reports/r-9021/summary.png is helpful for operators but useless for security. If your code signs a URL before confirming the caller owns the report ID, you risk disclosing another customer's data to anyone who can guess a report ID. The guide provides a Go-based contract exampleβ€”applicable to any languageβ€”that explicitly checks report.TenantID != tenantID and returns ErrForbidden before calling store.SignGet. This ensures the browser receives temporary read authority, not the service credential itself.

Lifetimes and Revocation Reality

While the example code suggests a five-minute lifetime for signed URLs, the author warns this is a policy example, not a universal standard. Shorter lifetimes increase API traffic and risk expiration during slow downloads; longer lifetimes extend exposure after session changes. Crucially, the checklist notes that signed URLs do not provide instant revocation. If a user's access is revoked, an already-issued link remains valid until it expires. Teams must tie lifetime policies to report sensitivity and expected transfer times, rather than defaulting to arbitrary numbers.

Testing Residency and Compatibility

The guide moves beyond code to operational evidence. It demands that teams document object locations, processing regions, and support access rights as part of a written control, not a vague dashboard memory. Compatibility should be defined as the tested subset of operations: private upload, metadata lookup, signed download, and deletion. For browser uploads, the checklist highlights that CORS policies must be verified end-to-end, as a presigned upload fails if the storage endpoint doesn't honor the allowed origins and headers. Familiar SDK ergonomics cannot compensate for missing residency or recovery evidence.

Key Takeaways

  • Never let storage decide application ownership; verify tenant ID in the database before signing.
  • Signed URL lifetimes are a trade-off between API load and exposure window, not a fixed rule.
  • CORS configuration is a mandatory part of the test plan for any browser-based presigned upload.
  • Private delivery is unsuitable for public image catalogs or static sites requiring anonymous CDN access.
  • Rollback happens at the application boundary by stopping link issuance, not by making buckets public.

The Bottom Line

Stop treating object keys as security mechanisms. Tenant isolation belongs in the database, and rollback means stopping link issuance, not flipping buckets to public.