Help: rich text input's pictures are publicly visible on the Internet

Need help
1

We’ve been using Bubble’s Rich Text Input for comments in our ticket system, where users post, among other things, screenshots of their issues.

For a while the Rich Text Input of Bubble used to sore images in base64 encoding, which was great in terms of privacy, because the image data was secure on the database. Then we filed a bug because the input sometimes stored images as base 64 and othe times as an image on the database.

Recently, we looked up our database and found out Rich Text Input stores ALL images pasted inside the text PUBLICLY on the Internet. And I got a confirmation from Bubble team that there is no way to make these images private.

Our team is frantic! We have now a file storage full of publicly available images that contain private data! It puts us in a very precarious situation vis-a-vis GDPR and we are sin serious trouble if somehow one finds out how to access these images.

  1. How can we clean up this mess now?
  2. How can we get inputs with pasted images that are private?
  3. Are we the only ones freaking out about this? How can Bubble just leave such a gap in privacy wide open?
1 Like
2

By not fully realizing a feature/element, if the Rich Text Input you are using is built by Bubble. What should be on there is a simply checkbox for ‘make all images private’, but I’m not sure if it exists, as personally, I do not let users upload images via a rich text input, not for purposes of privacy, but other reasons.

Need to find a way to take the upload images and ‘re-upload’ them into another data field of type image and make that private. I did this years ago when taking images from another website which had the website address attached to their file location, I used the text of that link to upload the image into my database and so my images had my app name attached to link. I don’t recall how I did that.

Then redo your UX/UI so that users can not upload via the RTE and instead have to do it via a picture uploader element.

2 Likes
3

Is this a joke?
If that’s the case bubble should clearly document this and make users aware.
This a is big hole, so I’m sure there is more to this?

1 Like
5

Any updates on this?
I would like to think rich text fields are secure.

6

Hi,

Equaly anxious here but no updates. I’ve also asked for a work around, i.e. a way to capture images and re-upload them privately, but nothing so far.

Meanwhile I added a feature request on ideaboard. Feel free to upvote.

7

Its great you have asked for the feature, but I would like to think Bubble would make users aware of this privacy loophole.

It’s not even documented so developers can be aware of this.

Too much focus on ai and new clients they missed a basic security requirement?

1 Like
8

How does one get hold of bubble? There are no support email addresses? You can only submit a bug report?

9

There is a support@ email

10

thanks

11

I also checked again with Bubble, and you are right, Images in rich text fields don’t have any privacy protection.

I requested that they make an announcement on this and update Bubble’s documentation to reflect this issue. I don’t think they have any interest in this.

For me this sums up Bubble’s attitude towards information security. I can almost guarantee you neither I nor @data1 would have been the first ones to complain about this.

It really surprises me that Bubble thinks that Enterprises would want to use them. There is a lack of understanding of what enterprises actually value and priorities and the knock-on effects via customer and supply chains etc.

Knowing this issue exists and deliberately not informing their customers is a breach of general trust, not to mention making a joke of any SOC2 controls. SOC2 compliance needs a re-audit.

12

Just to add to that.

I really think people should take more interest in securing organisation’s or individual’s data. In my opinion there is a “duty of care” that falls upon a developer even if the client they are developing the product for, doesn’t specifically ask for it.

Because in most cases whoever is using the product is storing data that impacts many other organisations and individuals, not just the person or organisation that bought the product (Bubble app).

Even if you don’t use rich text fields or don’t store images in rich text fields, you should have a level of concern, as this rich text field issue should have been part of the documentation from day one.

In the case of this post the damage is irreversible, and I think Bubble underestimates the reputational and/or operational impacts that can come from this.

13

Yeah, bit strange there’s no ‘Make this file private’ checkbox with the ‘Thing to attach to’ field that other plugins (not even built by Bubble) use.

By the way, I haven’t found a way to scrape Bubble’s file manager to identify public files other than by using brute force.

Bubble stores each file with a unique ID, and the file name. You need to know both of these to access it, and there’s no obvious endpoint that allows you to search for all public files on an app you aren’t a collaborator on.

There is an endpoint that allows you to programatically retrieve any files in your file manager, and programatically read/delete them, but you require access to the app’s editor to do so.

Still, being unlikely to find something doesn’t make it secure.

2 Likes
14

What is the endpoint that allows you to do that?

15

It’s a Bubble editor endpoint, not an app endpoint

16

Is there a list of bubble editor endpoints?

17

No, there aren’t

18

So what is the endpoint that allows you to programmatically delete the files from file manager?

19

To list/filter files:

https://bubble.io/appeditor/list_uploaded_files

{
    "cursor": 0,
    "limit": 100,
    "filename": "",
    "only_private_file": false,
    "file_type": "all",
    "sort_type": "date",
    "descending": true,
    "appname": "{appID}",
    "app_version": "{version}"
}

To delete file(s):

https://bubble.io/appeditor/delete_uploaded_files

{
    "appname": "{appID}",
    "app_version": "{version}",
    "urls_to_delete": ["{fileS3Key}"]
}

{fileS3Key} is returned from the list files endpoint.

Both of these require you to be authenticated with the login cookie of a collaborator on the app that has permission to access the file data on that version.

It just means that in theory, if you have a list of file URLs from your database, you can actually manage to delete orphaned files by deleting any files that aren’t stored in the DB. Of course, Bubble won’t allow you to do that yourself in the editor (and wouldn’t endorse this method either). However, all this is, is a way to automate what you can already do in the editor (and, for example, get 1000s of files at a time rather than 50…) if you have sufficient coding experience or can be bothered enough.

2 Likes
20

This topic was automatically closed after 70 days. New replies are no longer allowed.