Question about set state security

I have a couple of questions regarding my setup and if I need to change anything.

What happens - When the page loads it pulls some data from the URL and sets some states on the page such as who is the “Owner” of the page. I have a button that says edit page that shows up only when current user = owner. When that button is hit a different state called “Edit Mode” is switched to yes. Some elements that were hidden are now visible with edit mode set to yes. The elements are for editing some info on the page, for example, an input that lets you change the text heading on the page.

My main question is, is that safe to do? I know here
https://manual.bubble.io/core-resources/elements/shared-properties#this-element-is-visible-on-page-load
it says it is possible to see hidden info, but is it possible to interact with it?

And if it is a problem, would a solution be to set: Only run if current user = owner for all my workflows regarding the hidden elements?

TLDR - Can a hidden element that requires a set state to be seen, be interacted with in any way if the state is not set?

2 Likes

Hello! Sam here, with Bubble support.

Can a hidden element that requires a set state to be seen, be interacted with in any way if the state is not set?

Yes, by a malicious actor who is savvy enough to know what to look for and where to find it.

What’s important to understand is that anything that is hidden / protected via front end workflows (including custom states) is accessible by a “bad actor” via the browser’s javascript console. By accessible, I mean that any data associated with the element (ie: list of information for records in a hidden repeating group) could potentially be viewed by someone savvy enough. If they find it, they can interact with the javascript console to set states and make things appear on their screen when they shouldn’t normally be appearing.

The reality is, your average user won’t be able to find anything, and this type of visibility condition that looks at a custom state is generally perfectly acceptable for things that you just want to hide because they aren’t relevant to the current user (ie: hiding a link for “sellers” when your current user’s type is “buyer”)

If your app deals with truly sensitive data however, it’s important to protect all data with privacy rules, and execute any workflows that involve sensitive data on the backend, where they can not be inspected via browser console.

For example - given your specific use case, it wouldn’t be a big deal if someone who wasn’t the owner was able to use the javascript console to make the “edit mode” button appear, as long as the data that was being edited was all protected by privacy rules. The “bad actor” user would be able to see the button, and maybe even click it. But the privacy rules would prevent the relevant data from actually being seen or manipulated.

Let me know if you have any specific questions about this!

2 Likes

Hey, thanks for the detailed response! I have a question about how to setup my data in a way so it is safe.

I have a data type called “Pages” that is used to supply data to what is basically a profile page. And then their user account has a “List of Pages” data type. I want the data in the “Pages” to be publicly visible, but only editable by the user who has it in their “List of Pages”.

I assume the solution in my first post wouldn’t work, because a savvy user would be able to set the state of “Owner” to match their own account and then have access to anything the true Owner would? And even if I added Owner = Current user to every workflow, it wouldn’t matter since they set the state to match their account, which would be current user?

To make it secure I would have to do something like “get page from url” is in “current users list of pages” for each workflow I want to be secure? Or is this all meant to be done by setting the “type of content” of the main page element rather than use states?

Or am I thinking about all this in the wrong way?

Thanks for any help you can give.

2 Likes

Hello -

For this type of set up, I would have a field on the user data type called “user role” which would be set to “owner” for authorized users.

Then, in your workflows, you can refer to “current user’s user role” rather than having to a set a custom state to determine who the owner is.

A field on a data type in the database is much more secure and can be protected by privacy rules so that only the current user and user’s with a role of admin can view details. This way, there would be no way for a bad actor to access and update this information through the javascript console.

I hope this makes sense! Please let me know if you have any other questions!

I don’t think that would work for my needs because I want each user to be able to edit their own pages but not other users. Doing it the way you suggested would allow them to edit any page and not just their own, right?

So what I need to do is confirm a user owns a page through the database and not using states.

Since in my user datatype they have a list of pages they created, can I just reference that? Like is current page in current users list of pages?

If so, what would be a safe way to get the page? Previously I was setting a state when the page was loaded based on the path from the URL. I now know I cannot reference that state, but could I still get the page from the URL or is that not secure either?

Basically, would this work https://i.imgur.com/kYPIXjz.png as a secure workflow?

Thanks again for all your help!

I definitely wouldn’t use the page URL as a means of authorizing a user for a certain page - that isn’t a secure way of doing things, because anyone who knew the URL or could guess it would be able to access the page.

In my first response, I hadn’t grasped that your users could create their own pages and that is what you were attempting to protect. In that case - yes, using the “list of pages” field would be the best option.

You should be able to set a condition on any element that you only want the owner to view (ie: the edit button) that says “Only when current user's list of owned pages contains current page

The expression above might look slightly different depending on how your DB is set up and how you are storing page names on the user, but that should get you going in the right direction!

Thanks for all the help. I think I overcomplicated things by using a bunch of custom states rather than build around the main page element. Have to restructure a few things but I think it will be better in the long run, and then I can just verify against the page element. Thanks again for your time.

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