We have an incident where a user of our client claimed that sensitive data was tempered with. The main issue is with the “Run As” feature, which does allows the Dev / Admin to impersonate a user and input data, without leaving any trace of this impersonation.
Can this Run As be audited? Is there any audit trail anywhere that can reveal data was modified not by the user but by the developer using the Run As feature?
The point is we have to prove no one tempered with the data. Any suggestions welcome. Thanks.
You should turn off the feature for developers in live. For the collaborator, check the box for ‘only dev version’. This will prevent them from accessing the live database in the future. Also, make sure they are not an ‘admin’ either. I can’t think of a way to see if a developer used the ‘run as’ feature though. Maybe ask Bubble Support to see if they have a way to see that. At least you can prevent the issue going forward. But at least one person, the admin, will always have access. That should be you only. Also, under Privacy & Security, you can turn off access so Bubble doesn’t have access to troubleshoot your app as well. For added security.
From what I know, this is not available actually, but it should be something that Bubble could easily implement. When you click on the “run as”, this will open a specific url that do a get request to app server that return an access_token and a redirect to the page you want to run as this user. So it should be really easy for Bubble to add this (and may already be available in their logs).
Go to logs, search for the data type that was changed. Use available info to narrow down like modification date, and user email. If you can find where it was changed, great! Now look for the login. As far as I know, logins are part of logs, and I don’t believe ‘run as user’ is. And you may see ‘admin’ as the user who made changes.
I had problems in client app with an intern always insisting they didn’t make the changes, yet, time and time again I found that they didn’t.
You could also consider making a robust changelog history to save all changes, knowing who changed it, from what value to what value, when they changed it and from where in the app did they change it.
Is it possible the client made an oopsie and is trying to blame it on someone? Is there anything to gain with the data that was tampered with? Why would it be tampered with by an admin? It would be just as easy to ask for proof that the client didn’t mess with it…
Sadly this feels like an un-winnable argument. It’s why I don’t tell my users about the feature, but honestly in 6 years I’ve only needed to use it maybe all of 3 times.
Although not helpful for what’s already happened, I wonder for an auditable solution for ‘run as’ the User’s IP could be attached to the User, and if this changes, create a new log.
I’m thinking similar to how other services would email you if logged into a new device or another countries IP.
Also curious if someone has implemented this before?
‘Run As’ also starts the session with a redirect, so i wonder if this could be logged also.
The “Login As” or “Run As” feature in Bubble allows app editors to view and test the app as a specific user. To use this feature, editors go to the Data tab, select “All Users,” find a user, and click “Run As.” This feature is intended for testing and debugging the app from different user perspectives.
There is no information on disabling or restricting this feature to certain app editors. The documentation does not provide guidance on blocking its use or tracking when it is used. There are internal logs for Bubble account access, but they are not typically available for tracing “Login As” usage by app editors.
@data1 open the network tab and you’ll see all the steps before arriving at the page as the User - the final one being a redirect from your app with the ?access_token=
At least you can prevent the issue going forward. But at least one person, the admin, will always have access. That should be you only. Also, under Privacy & Security, you can turn off access so Bubble doesn’t have access to troubleshoot your app as well. For added security.
