Storage security and limits
Storage runs inside one tenant site and one app at a time. Access is decided in two steps: platform login and roles first, then a per-bucket policy for each file operation.
Who can do what#
Bucket administration (create, change settings, delete a bucket) requires an organization owner or admin, or another cloud user with access to the site.
Object work (upload, copy, move, delete) requires a signed-in user. Anyone can download a public file or list the public files in a public bucket. Search and browse always require sign-in.
Policy checks run for every sensitive object action. Each bucket has its own policy. Changing who can upload or delete means updating that bucket’s policy, not changing application code.
Default policies by bucket type#
When you create a bucket, you choose a category. That choice sets the starting policy:
| Category | Typical default |
|---|---|
| Assets | Signed-in users can read. Upload, update, and delete need extra policy rules. |
| Attachments | Signed-in users can read, upload, and update. Delete needs an extra policy rule. |
Public files can be read without login. Editing a SharePoint-backed Office file always requires login and a passing policy check, even when the file is public.
Batch upload and batch delete check each file separately. Allowed items succeed; denied items appear in the response failed list instead of failing the whole request.
Listing and browse#
Listing a private bucket requires a caller whose policy allows read. Anyone can list a public bucket, including callers who aren't signed in; if the caller can't read the whole bucket, the list includes only the files that are effectively public, with their path, name, size, type, and metadata. Keep private details out of file paths and metadata in public buckets.
The folder-style browse endpoint always requires login, including for public buckets.
Tenancy#
Buckets and objects never cross tenants. Everything stays in the site that owns the app. Anonymous callers can download public files and list the public files in a public bucket. They can't search or browse.
Destructive actions#
Deleting a bucket removes every object in it and its access policy. Cloud access is required. There is no undo in the API.
Deleting one file or a batch removes the record and the copy in S3 or SharePoint. Batch delete accepts up to 100 paths per call.
Data handling#
- File bytes live in S3 or SharePoint, not in the database.
- Object metadata is small (up to about 2 KB) and stored as plain text—do not put secrets in metadata.
- Download links in API responses still require permission unless the object is public.
- SharePoint view and edit links are per user; do not share them between people.
Numeric limits#
Upload size, batch sizes, metadata caps, and optional bucket quotas are listed on Configured limits. Quota usage is recalculated periodically, so crossing a quota flags the bucket but doesn't block the next upload.
Report a problem#
If a private file is readable without signing in, a user sees another app's bucket, or a delete succeeds when policy should deny it, contact TaruviBase support. Don't post reproduction steps in public channels.