Bubble file-upload security checklist for client portals
The question this checklist answers
Can a person from one client organization upload, view, replace, or retain another organization’s file? A client portal should answer that question for every file operation, not only for the page that displays a file. The useful unit of review is one complete workflow: the user selects a file, the app decides where it may go, the bytes are stored, the app records ownership, another user requests it, and eventually it is deleted.
This checklist is a design and review tool, not a certification. It covers both Bubble-hosted private files and a possible external storage design using Google Cloud Storage. Bubble’s own file documentation explains that a private file must be attached to a database thing and that the uploader’s private-file setting works with the relevant privacy rules. Its privacy-rule guide makes clear that hiding a file URL field alone does not protect the file if someone obtains the URL elsewhere. For external storage, Cloud Storage access controls govern access to the bucket and objects; Bubble privacy rules do not automatically apply there.
Start with a concrete threat model
Imagine an agency portal used by two client organizations, Cedar and Harbor. Each has staff who can submit invoices and retrieve their own documents. The most useful test account is a legitimate Harbor user who tries to reach a Cedar file. That person already has access to the application and knows how normal uploads work. Test the same paths for a signed-out visitor, a former employee, and an administrator whose rights are narrower than a storage administrator’s.
Write down the data classes before reviewing controls. Are these public marketing assets, ordinary business files, financial records, or regulated documents? Who may upload, view, replace, download, and delete each class? Who decides retention? If the answers depend on a customer’s contract or regulated-data obligations, assign a qualified reviewer rather than assuming a generic checklist resolves them.
Conceptual trust boundary
The arrows identify places to inspect, not a verified Bubble2X workflow. Bubble2X’s customer-facing file workflow is currently planned, so this article makes no claim that Bubble2X provides these controls today.
Copyable review checklist
For every row, record an owner, the date verified, and an evidence link or test result. “Configured” is weaker than “tested.” A screenshot of a checkbox can establish configuration; an access test establishes observed behavior.
Check | Why it matters and action | How to verify | Owner | Verified on / evidence |
|---|---|---|---|---|
File inventory | List file types, sensitivity, allowed actors, retention, and deletion owner. Unknown classes invite inconsistent rules. | Trace one sample file of each class from upload to deletion. | App owner | ___ |
User and organization binding | Derive the acting user from a trusted session and resolve organization membership on the server. Do not trust an organization ID merely because the browser submitted it. | Change the submitted organization ID from Cedar to Harbor; expect denial. | Bubble app or integration service | ___ |
Operation-specific authorization | Check upload, view, download, replace, and delete separately. Read access does not imply write access. | Exercise each action using member, nonmember, and signed-out accounts. | App and integration service | ___ |
Bubble private-file settings | For Bubble-hosted private files, attach each file to the correct thing, enable the uploader’s private-file setting, and configure the associated privacy rule. | Try the file URL as an unauthorized user and confirm access fails, not merely that the URL field is hidden. | Bubble app | ___ |
Credential placement | Keep provider credentials in server-managed configuration. Bubble’s API Connector security guide warns against placing keys in page workflows, option sets, URL parameters, or default values. | Inspect a test browser session, page source, network requests, and connector configuration using a nonproduction credential. | App and integration service | ___ |
Storage access | If using Cloud Storage, grant the service only the bucket and operations it needs. Consider uniform bucket-level access to simplify IAM-based access. | Review effective IAM and try an unauthorized read or write with a separate identity. | GCP owner | ___ |
Upload constraints | Set an allowed file policy: intended types, size limit, name handling, and optional content inspection. A browser extension or declared MIME type is not proof of content. | Submit an oversized file, a mismatched extension, and an unexpected content type; record the actual response. | App and integration service | ___ |
Object identity | Assign an opaque object identifier and store an ownership record. A path prefix can help organize files but is not an authorization check. | Request an object with another organization’s path while authenticated to the wrong organization. | Integration service | ___ |
Completion proof | Treat “the browser sent a request” differently from “the intended object exists and passed validation.” | Interrupt an upload after authorization, then inspect status and object metadata. | Integration service | ___ |
Download access | Reauthorize every download request. If a temporary URL is issued, keep its lifetime short and avoid placing it in logs or analytics. | Reuse a previously issued link after membership revocation and after expiry; document residual access during its lifetime. | Integration service | ___ |
Audit events | Record actor, organization, action, object ID, time, result, and correlation ID without file contents, secrets, or full temporary URLs. | Compare a denied request, a completed request, and a timed-out request in the audit view. | App and integration service | ___ |
Retention and deletion | Decide when a file should be removed from the app record and storage. Check backup, versioning, soft delete, and legal holds where relevant. | Delete a synthetic file and verify each expected state over time. | App and GCP owner | ___ |
Abuse and cost controls | Bound issuance of upload permissions, request volume, total storage, and repeated failures. | Simulate repeated requests within a disposable environment and observe alerts or rejection. | App and GCP owner | ___ |
Where each control belongs
Bubble already offers file hosting and privacy controls. For a modest portal, using them may be the clearest choice. The Bubble files guide describes private files attached to a database thing, and the privacy-rule guide explains why access to the attached file needs its own permission. Review the exact uploader and rule configuration in the app you operate. Third-party uploader plugins can have different behavior and need their own inspection.
When an agency chooses external storage, the application needs a second authorization boundary. Cloud Storage can answer whether a Google Cloud identity may operate on an object. It does not know that a particular Bubble user belongs to Cedar unless your own service checks that relationship and maps it to a narrow storage operation. A signed URL gives temporary resource access to whoever possesses the URL. It is therefore a delivery mechanism for a previously authorized action, not a substitute for the authorization decision.
Avoid describing bucket naming as tenant isolation. A path such as “cedar/invoices/…” helps operators find objects and apply lifecycle rules, but a service account with broad bucket access can still reach Harbor’s objects. Separation requires a server-side check against an ownership record, narrow identities or resource controls, and tests that try to cross the boundary. If different customers require materially different retention or access policy, compare separate buckets or projects with the operational burden they create.
Test denial, not just success
Begin with one synthetic Cedar file and one Harbor file. Record their object IDs and owners. Then run the same matrix against upload authorization, view, download, replacement, and deletion. A Cedar user should succeed only for actions permitted by Cedar policy. A Harbor user should be denied when requesting new access to the Cedar file even when they know its ID. A signed-out visitor should be denied by private app endpoints. An already-issued Cloud Storage signed URL is a separate bearer grant that may remain usable until it expires; test and document that window.
Retest after a user is removed from an organization. Cached pages and already-issued temporary links complicate this case: revoking app membership does not necessarily revoke a URL already handed to the browser. Choose an acceptable link lifetime and document that residual window. Test duplicate requests as well. A second upload attempt should not silently overwrite the first file, especially if a user can influence its object name. Cloud Storage request preconditions can help prevent unintended overwrites when the integration uses them correctly.
Also test partial failure. If an upload was authorized but never completed, does the interface show a pending item forever? If the object exists but the app never receives a callback, can the server reconcile it? If a scan or validation step fails, can an ordinary user still download the unapproved object? These are workflow questions that privacy settings alone cannot answer.
Decide what evidence is enough
The minimum evidence packet for a project should include its data classification, a trust-boundary diagram, the owner for each checklist row, test accounts and synthetic files, a dated negative-test record, and a record of unresolved exceptions. Do not paste live keys, customer filenames, temporary URLs, or file contents into that packet. Review the packet whenever the uploader, privacy rules, identity mapping, bucket policy, or download path changes.
Cloud Storage object lifecycle rules can automate some cleanup, but their actions are asynchronous. That is useful for housekeeping, not a promise that an object disappears at an exact second. Document the product’s deletion state separately from the storage lifecycle and verify what “deleted” means to the customer.
This review will not make a portal secure by itself. It makes the responsibilities and the tests explicit so an agency can identify gaps before they become invisible assumptions.
Request early access to discuss your client-portal file workflow. The first planned Bubble2X workflow focuses on customer-file storage using Google Cloud Storage.
Related reading: GCS upload architecture and cross-tenant file access tests.
