“Run As” is not the only vulnerability.
It may be a lot more than borderline… especially since it appears that “Run as” clicks aren’t logged anywhere (at least not visible in our server logs.
From my POV there are 2 main reasons:
- [main reason] Current state of the Ideaboard is something like “post it here and that’s it”. No feedback from the team at all. You don’t know if your idea was ignored or included in the roadmap or backlog…
- Few big players (= enterprises) use Bubble. And those that use - don’t know about
run as...feature OR have bad security audit OR are aware of this security backdoor, but Bubble doesn’t care about these 15 upvotes on the Ideaboard…
I’m sure I just don’t get it, but I have never viewed the “run as” feature as a security issue/hole. Heck, I work for a multi-billion dollar company, and our support department makes use of a “login as” feature all the time to troubleshoot issues for customers. I actually thought it was kind of a standard(ish) practice, and again, I think the feature is somewhat invaluable.
Yep, from support’s side that feature is great, cause it’s easier and faster way to solve issues. I wish I could have similar feature in my IRL job (IT department in a big bank).
But any bad player from support team can make any actions on behalf of the user without any logs being saved.
Well I guess I’m predictable and at least consistent, but you can’t be a serious enterprise development platform and have an Ideaboard drive the priority of security issues.
I’m talking to you Bubble, pick a lane: either make a platform for hobbyists and excite them with slick features OR a stable and secure platform with the right devops and integrity that also adds slick features from an Ideaboard ONLY when the critical infrastructure meets the proper standards.
Pick one and and tell us which one and commit to it! That way serious apps and developers can know whether or not Bubble is a viable solution for them or not. And it’s fine if you pick option 1; I won’t complain anymore or make any noise and we can still be friends but damn it pick one and go all in on your choice!
@code-escapee, I am genuinely curious, though… would you want the feature gone altogether or do you see use cases for it if it can only be accessed by the “right” folks and if its use is logged appropriately?
Hell, maybe this discussion hasn’t been done to death!
Is PII stored on the user’s profile?
Don’t get me wrong. It is an invaluable feature and every platform I’ve built had a admin/token feature that functionally did the same thing. BUT access to this feature was role based and logged and in at least one instance, gave limited access to what user information you could see.
I’d like it under those circumstances (it is a great feature). But if the choice is status quo or remove it altogether then security always comes over features (esp since we gotta prove we can be trusted and scalable)
Not a question I was asked, but I’d like to share some thoughts from my experience.
This feature should not be available for anybody (even for god-mode-folks aka admins/developers) in production. If you need to debug an issue - you should have a test user with appropriate roles/authorisations similar to the real user that reported a bug. This is the way to perform root cause analysis and solve issues.
Cool, thanks for the insight. I really do dig the feature, but it would definitely be good if they logged who used it and when.
Sorry, Artem… grateful to hear your thoughts, too, of course!
I hear what you’re saying, but issues are often related to customer/user-specific data, and you can’t really replicate that, right?
For sure, this is the dilemma. Make it easier to help customer with his issue as soon as it is possible or follow security best practises as a priority (and torture end user with additional requests for screenshots and step-by-step descriptions).
So, I think that:
run as...should be an optional feature deselected by default. And turning it ON/OFF should be logged and available in admin panel.- each
run as...action execution should be logged in admin panel. Something likeuser XXX (email) used "run as..." feature on behalf of user YYY. So admins/developers/support staff can use this feature (if it is globally activated), but this information will be saved into logs. Not a good option from security side. But at least If something bad happens - it will be possible to investigate.
It’s all bout risk appetite. If you build an internal tool that doesn’t require top security approach - it’s ok to lower security demands. But if you are developing some B2B SaaS - that’s totally a different case with higher security priorities.
I’m not sure I agree that it’s a security issue.
Only admins can use run as & restricting that doesn’t really do anything because all it does is make testing harder.
An admin can just build a page that does the flows in a few seconds anyway or change the content type to current page user instead of current user. The admin can also view/change all the database.
I’m not sure I see any additional security issues with run as since it’s an admin who access it anyway 
Good point Chris. I forgot / didn’t realize that that can be restricted for collabs although the “Only dev version” leave a lot to be desire since its carte blanche. Ideally, App, Data and Logs should have separate permissions for Dev and Live.
I now recall that for I once gave a developer access using 2 emails/accounts. One with admin level access (including View and Run as) for dev and the other with more limited access but access to Live.
I’m sure it was a pain for him to switch between accounts but that was the only solution we came up with that satisfied compliance ppl.
Let’s imagine that we’ve build an internal Payroll Management Software tool. So currently app admin can change salary for any employee (directly via database or using run as... feature). How will you find out who and when made it?
Going further - let’s imagine that our Payroll Management Software app is not an internal tool but a SaaS. So now the scale of the problem is much bigger 
Wouldn’t be able to see who did it if they changed in database or copied the page and made it all “current page user” then just ran the flow like that either. It would appear it was the page user just like if they did run as.
Giving anyone admin permissions there are multiple ways of doing the same thing as “run as” that’s why you need to trust who’s on the team. Just like traditional code someone with admin rights can fully change/edit anything.
If you copy a page/change conditions (or data source) - you need to deploy it to production. While investigation you’ll at least have something to work with.
It doesn’t really matter if it’s trad code or low code or no code. Security best practice is to log everything about operating with crucial data no matter who made the change (admin or end-user).
Very good point
Well now we get to talk about how logs as a whole suck in Bubble 
I don’t think there was anything mentioned about this at BubbleCon though, so one can only hope!
No, we don’t… not in this thread, at least. 