Data deleted... or not ? security concern

Bugs
1

Over the last weeks, together with @Sarah_Esteve, we’ve been through a DB refacto exercise for one of our customers in order to optimize data loading, improve app performance & enhance end-user experience.

As part of this process, we moved a significant number of fields from one table to another, deleted those fields afterwards and optimized the app.

But guess what ? the deleted and optimized FIELDS STILL APPEAR in the brower…

I’ve checked bubble documentation and @petter (awesome !) books to try to understand what went wrong and if we were missing something but could not find anything.

So I’ve contacted bubble support and after many email exchanges, i received this answer :

" I do see that the documentation mentions something different, however there have been cases where data that is referenced earlier may not be fully deleted, since it is still being used in another part of the app. We understand this is a bit of a known behavior, but in general to fix this you would need to restore the app and relevant data type to before you deleted the data type. If it falls within your app’s retention period (20 days on a Team plan), you should be able to do this on your end, as we don’t have longer retention than this on our side."

Whaaaaaat :interrobang:

This is NOT a known behavior, I’ve just found one mention in a post by @rico.trevisan.
I believe bubble community should be made aware of this, and documentation updated accordginly as it could cause serious security issue (you lose control over privacy rules for those fields).
…Not to mention the impacts on WU consumption impacts and associated over invoicing…

CURRENT SOLUTION FOR NOT YET DELETED DATA : The only way to avoid this is to REALLY delete data (bulk) BEFORE deleting the fields, (yes… it costs WU)

SOLUTION FOR DELETED & OPTIMIZED DATA : NO KNOWN SOLUTION

Finally, Bubble support manually removed the list of fields we provided, but this is clearly not a sustainable approach. And we have still other fields deleted in other tables, but also other apps, other clients…

We also asked Bubble to provide a more comprehensive solution and, at the very least, update the documentation and inform the community, but we have not received any response.

Through this post, I hope that giving visibility to this issue will help to solve it !

Happy bubbling !

Sylvie :sunny:

PS : In order to see data still loaded in the browser, you have to use the dev tool and look at your data

image
image975×702 49.8 KB

11 Likes
2

If it’s got anything to do with information security, it’s not Bubble’s expertise or focus area, or interest for that matter. To the point they know there are some holes, and they won’t inform Bubble users. New folks have to learn the hard way. Something for the auditor when Bubble has their SOC2 audit - Processing integrity, confidentiality, and privacy are areas that need to be looked at. Not too sure who the auditors will be, I’m assuming it will be Sensiba. We’ll probably have more luck trying to get the auditor’s attention than Bubble’s attention.

1 Like
3

I can’t really offer any solution here, but can confirm this behaviour…

I recently deleted entire datatypes, and some huge list fields from an app in an attempt to optimise the amount of data being loaded.

Yet, even after deleting fields AND running the ‘Optimise App’ function (on the understanding that that would remove all traces of them), they are still loading to the page (as seen in the network tab).

For future reference, I would recommend, prior to deleting fields or datatypes, to set up privacy rules such that the data cannot be accessed by anyone. Then delete them and optimise the app (assuming that privacy rules still apply to deleted datatypes and fields - I’ve never actually tested that - if not then I guess the only way to do this would be to actually delete the data from the database, before removing the fields and datatypes).

4 Likes
4

Interesting.

I had commented before about trying to figure out why things weren’t truly deleted.

As I mentioned after some research, it was because everything had to still be there in the event you wanted to restore back to a previous time.

Supposedly, the optimize app feature is meant to delete these, but I’m not sure.

Also, the delete change history is supposed to permanently delete these from what I could understand.

Thanks for your suggestions.

5

Interesting.

I was aware of a separate (but perhaps related) issue whereby deleting an item from the DB without also removing it from any list fields that contain it would result in “phantom” items remaining in the list, which weren’t reflected in the list “:count” but could impact backend and/or API workflows.

I was unaware of this specific behavior with regard to deleted fields, so thanks for the heads-up. My main take-away is to always delete all data and field references before deleting the relevant fields.

I’m curious, does the “zombie” data that appears client-side still consume WU?

(Wow, phantoms and zombies… How fun! And just in time for Halloween! :ghost: :man_zombie: :jack_o_lantern: )

:smirk:

6

Absolutely insane, but also on par for what’s normal in Bubble. It’s going to take a massive twitter post like the one below to finally wake them up. That’s how they operate. Things need to go bad, then they react.

(1) xyzeva on X: “gaining access to anyones browser without them even visiting a website (CVE-2024-45489) https://t.co/Junay0CCNv” / X

There are massive “known issues” that haven’t been fixed in multiple years (like the public fileupload endpoint). There are no HSTS headers, meaning every Bubble app is susceptible to a man in the middle attack. It’s literally just one line:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

@josh and @emmanuel used to be really passionate about Bubble, would visit the forums often, build out entire features in a day–but they’ve checked out ever since the WU pricing announcement. I think they’re burned out and don’t care anymore.

1 Like
7

@sylvie.daisytech I would take all of this and submit a ticket to support. They can escalate it to the right engineering team to take a look. I’ll share on my end.

1 Like
8

Can anyone confirm if the following fixes this, assuming you haven’t “Optimized” your app?

  1. Delete ALL entries from that data type so that there’s zero of that Thing in the database.
  2. Delete the type of Thing. (Optional: Delete all fields of that type before deleting the Thing type).
  3. Optimize app.

If you do everything in this order, is the data still accessible? Would be curious to know if this works @sylvie.daisytech

9

Hi @fede.bubble ,

Thanks for your reply, the reason of my post is precisely because the support is not taking this issue seriously enough (in my view).
Here is the exact copy of the answer I got :
" As for the general nature of the problem, as mentioned this is technically expected behavior, but our Engineering Team made an exception in this case to manually clear the data. We can submit this as internal feedback so that we can try to have discussions in the future about whether we want to change this functionality, but as explained the data may remain if not fully deleted before the data type entirely is deleted. So in the future when you’re deleting data types, you’ll want to delete the data under the data type first ."

… Which I find extremely disappointing and concerning

5 Likes
10

Hi @randomanon ,

This is what i mention in my “CURRENT SOLUTION FOR NOT YET DELETED DATA” , it works.

The thing is that if you don’t know you HAVE to go this way, you would probably not do it ths way, as it takes more time and it costs WU.
I would make the comparison of being obliged to delete all files of one folder before deleting the folder itself…

2 Likes
11

Meaning even the fields are actually gone gone? Like it doesn’t even show up as empty, but that the field isn’t even there when inspecting the dev console?

Also, what happens if you just delete a field without the deleting the entire type? Would you have to delete ALL field data from that type before deleting/optimizing? Thanks @sylvie.daisytech

12

Yeah it’s super concerning. Imagine someone has sensitive personal or financial details stored in a field. They decide it’s not worth the risk so they delete the field or data type. There’s no popup or warning that say, “Are you sure you want to do this? The data will remain and can still be accessed by 3rd parties depending on the current privacy rules at this time.” Also, I’m not even sure that privacy rules apply to these data types, I’m assuming they do because when I restored a deleted data type, the specific privacy rules I had applied also were restored, but I don’t know for sure.

1 Like
13

Thanks for reporting this @sylvie.daisytech,
so what is going on if you doesn’t delete your database records and delete the table ?

That mean that there won’t be any way to delete your database item ?!

14

@antoine3
Exactly, you do not have anymore control on these records (especially once the retention period is over), the only way is to have bubble support team handling that manually : i don’t think either them or us are happy with that “solution”

3 Likes
15

It is a bit of a mess. We had a data type with 3 million+ records in on the legacy plan. Of course we don’t want to deal with that with WUs and it would break bubble anyway so we removed the data type entirely.

No idea if it is actually deleted or not as in Bubble it can be restored but I will be furious if one day Bubble puts the responsibility or WUs on me for deleting that data. It shouldn’t be such an Einsteinian endeavor to delete your data.

17

Does anyone know if this problem occurs when you don’t delete the entire Thing, but only the Field? Is it safe to delete a Field then Optimize App, or do you need to schedule a workflow on a list to clear that field entirely?

@sylvie.daisytech would really appreciate your comments on this since you have the most experience with this issue.

1 Like
18

@randomanon I think that if you properly delete an entire Data Type (using the app search tool to ensure you remove all instances where the data type is used) , there is no reason to load the related data in the browser.
So I would assume it’s ok.
That being said, using the dev tool and analysing what is truly loaded is certainly the best way to confirm this assumption.

19

Question raised during the “security” session yesterday… :melting_face:

image
image955×748 83.7 KB

Question still being analysed… do you believe it ? :joy:

Maybe @flusk can help ?

2 Likes
20

Up, because that a very big thread

1 Like
21

This is grave security concern. Recently found out that same things are happening with deleted pages as well. In many cases, deleted pages are also consuming workload units.

When a consumer is paying for deleting data in bubble currency of workload units, that data is not deleted. :no_entry_sign: Not fair.

1 Like