Privacy rule based on Current User's email address not possible

georgecollier · 2024-10-23T12:30:52.777Z

michael.bond:

Been working to securing my apps data server side,

Good on you

michael.bond:

there’s now a fair amount of logic and workflows to change annoyingly - but that’s on me.

What’s your use case? As @adamhholmes points out, it’s likely that you should be relating data by the User type, not an email (text).

michael.bond · 2024-10-23T13:26:04.371Z

My use case is that I have a bunch of data types with publicly visible privacy rules on them where I’ve aimed to speed up development by building first, then returning the restrict them - probably not the right approach!

In a few of my tables design I’ve included a text data type containing the email address of the person who should only be able to see said record.

In my clientside elements such as repeating groups, I’ve always ensured “do a search for” contains constraints that limit the data the user can see - my lookups almost always contain a constraint for user = current user’s email.

For some extra protection I want to retrospectively go over my data types so that server side it will never return another customers data.

For example, if I made a mistake in one of my “do a search for” for forgot to add the correct constraint, I want to always ensure customer X can only see customer X’s records - so it’s blocked server side if said mistake was made.

Bit of peace of mind really, hopefully that’s the correct approach - I’m still fairly new to bubble.

boston85719 · 2024-10-23T13:50:07.829Z

michael.bond:

where I’ve aimed to speed up development by building first, then returning the restrict them - probably not the right approach!

It is absolutely the right approach in my mind and should be a best practice followed by every developer as it does speed up development time as it removes slow downs caused by silly privacy rule errors, such as not logging in while testing. Also reduces the chances that other mistakes do not go uncovered prior to deploying to live.

michael.bond:

For example, if I made a mistake in one of my “do a search for” for forgot to add the correct constraint, I want to always ensure customer X can only see customer X’s records - so it’s blocked server side if said mistake was made.

If you set these up properly before implementing privacy rules, or at least do proper testing and debugging prior to implementing privacy rules, this will not happen anyway…best way is to use ‘current user’ and not some text field representing email address. In Bubble, all roads lead by to user…this is because every single data type has a built in field of ‘creator’ which is related to User data type. The created by field should not always be utilized though since there are use cases of a need to have another field, like ‘user-owner’ that you create (for example, employee created data, when employee leaves, the data can be transferred) but also because of Bubbles’ not fully realized feature of ‘cookies’ (when a user is not logged in and is not a registered user, any data they create, Bubble properly maps the ‘creator’ field to them when they return to register within 72 hours, - however, absurdly, Bubble did not make this same functional possible for a registered user, who is logged out and comes back within 72 hours and logs into their existing account).

michael.bond:

In a few of my tables design I’ve included a text data type containing the email address of the person who should only be able to see said record.

This should be a field that is related to User and not a text field

Your privacy rules could be either ‘this things creator is current user’ or ‘this things user-owner is current user’.

michael.bond · 2024-10-23T14:16:27.020Z

boston85719:

If you set these up properly before implementing privacy rules, or at least do proper testing and debugging prior to implementing privacy rules, this will not happen anyway…

Thanks for the explainer.

And yep, this had crossed my mind - did wonder whether privacy rules are absolutely required, when you visit most of the videos online of people teaching privacy rules the message is generally “you must have privacy rules setup before going into production, no ifs or buts”.

I did check devtools on a fair few parts of the app and at no point can my test user see information that they shouldn’t be allowed to see.

And presumably someone can’t manually send a HTTP post to
https://%appname%/version-test/elasticsearch/msearch to request information they shouldn’t ordinarily be able to see, these requests need to come from the elements I assume.

boston85719 · 2024-10-23T15:24:15.459Z

michael.bond:

“you must have privacy rules setup before going into production, no ifs or buts”.

This is good advice. Before you deploy to live (ie: before going into production), you should implement your privacy rules and test against them.

GH5T · 2024-10-24T09:31:07.151Z

boston85719:

It is absolutely the right approach in my mind and should be a best practice followed by every developer as it does speed up development time as it removes slow downs caused by silly privacy rule errors, such as not logging in while testing.

IDK bout you guys, but this is opinionated I believe. Mainly because I always build with privacy first, then open as needed. Sure it takes a little longer, but it takes longer to go back and then secure your app.

georgecollier · 2024-10-24T09:52:55.639Z

GH5T:

IDK bout you guys, but this is opinionated I believe.

Yeah, I can’t imagine building an app without building privacy rules first. The number of bugs that must slip through when adding them later! It’s generally pretty easy to tell when an issue is caused by privacy rules (so you can make the change in 2 minutes when you find it and be on your way) but if you add them later you’ve got to go over every possible user interaction to check it still works.

randomanon · 2024-10-24T10:19:13.083Z

michael.bond:

And presumably someone can’t manually send a HTTP post to
https://%appname%/version-test/elasticsearch/msearch to request information they shouldn’t ordinarily be able to see, these requests need to come from the elements I assume.

A hacker could do this, that’s why you have privacy rules.

georgecollier · 2024-10-24T10:22:03.418Z

michael.bond:

And presumably someone can’t manually send a HTTP post to
https://%appname%/version-test/elasticsearch/msearch to request information they shouldn’t ordinarily be able to see, these requests need to come from the elements I assume.

Yes you can, it’s like ten lines of code (though you don’t execute it from the URL you provided). Essentially you can search the DB without the data API enabled with constraints like the data API. You can access any data that the privacy rules permit you to have access to.

adamhholmes · 2024-10-24T10:32:23.509Z

Yeah… building an app without Privacy rules first, then going back and adding them afterwards seems crazy to me!!! (certainly it goes against virtually ALL my development best practices), and on the rare occasion where I have done it this way (either intentionally or not), it requires the entire app to be tested again to make sure the new privacy rules haven’t broken anything.

michael.bond · 2024-10-24T10:55:39.769Z

Yes you can, it’s like ten lines of code (though you don’t execute it from the URL you provided). Essentially you can search the DB without the data API enabled with constraints like the data API. You can access any data that the privacy rules permit you to have access to.

Wow, I guess Bubble’s privacy term “publicly visible” is pretty accurate then.

Couple that with the ability to see the db schema using this tool, I bet you could scrape a hell of alot of data out there that you shouldn’t really be able to access. https://forum.bubble.io/t/give-me-a-url-and-ill-visualize-your-entire-database

I’m glad for asking, and thanks for all the replies - given me a better understanding how to build going forward.

georgecollier · 2024-10-24T10:59:40.487Z

I’m building an audit tool that reviews more of your app than Flusk and doesn’t need collaborator access,
it just works with publicly available info. DM me with your app URL if you want me to run it on your app so you can see what’s public and/or exploitable.

boston85719 · 2024-10-24T11:00:24.082Z

GH5T:

IDK bout you guys, but this is opinionated I believe

The phrase ‘in my mind’ indicates an opinion.

georgecollier:

The number of bugs that must slip through when adding them later!

None, when tested properly. That would be the point of testing before deploying to live.

georgecollier:

It’s generally pretty easy to tell when an issue is caused by privacy rules (so you can make the change in 2 minutes when you find it and be on your way)

Except that the logs do not show when a privacy rule causes and issue and the debugger doesn’t show when privacy rules are the issue if the privacy rule does not allow the data entry to be found in searches.

georgecollier:

but if you add them later you’ve got to go over every possible user interaction to check it still works.

Solid testing to ensure no crazy mistakes are made in a live app like deleting other user data.

adamhholmes:

it requires the entire app to be tested again to make sure the new privacy rules haven’t broken anything.

Exactly, to ensure the privacy rules are working properly and that all other features/functions worked properly prior, meaning there is no need to use privacy rules as a crutch to avoid making mistakes in search constraints or something else that can cause the app to malfunction.

It is okay for people to have differing opinions, everybody has different approaches to life, development and we all learn differently as well. I guess I am just wired a bit differently than some other developers and the way in which I want to approach my development, makes it such that I don’t want to be bothered by privacy rules during development and I want to just test features to ensure they work, and then go back and test privacy rules to ensure they work, even if that means I have to test every user type, as in the end, it makes it so that my live app is more secure and less buggy compared to if I were to put in privacy rules first since I’m prone to not logging in while testing.

Glad everybody has their own ways that work for them.

adamhholmes · 2024-10-24T11:49:28.611Z

boston85719:

meaning there is no need to use privacy rules as a crutch to avoid making mistakes in search constraints or something else that can cause the app to malfunction.

That’s a good point…

I never like to rely solely on privacy rules to restrict what data is loaded… (that’s what search constraints are for).

I’ve seen apps that don’t use any search constraints… and just use privacy rules to restrict data to, say, only data created by the current User.

That’s fine (I guess) but if the privacy rules change at some point (or they are incorrectly set up, as is often the case), then it can cause problems.

So a combination of correct search constraints, plus robust privacy rules is best (in my opinion).

georgecollier · 2024-10-24T12:01:14.109Z

adamhholmes:

I’ve seen apps that don’t use any search constraints… and just use privacy rules to restrict data to, say, only data created by the current User.

Yeah this is wack and a pain for maintainability.

I use search constraints everywhere, build privacy rules first, and then when I do make a mistake, I get to be glad my privacy rules are set up correctly and it causes a bug rather than a data leak.

randomanon · 2024-10-24T12:29:06.249Z

What are you looking for exactly? Would be curious to know how yours is more comprehensive. I know that there are a couple of very esoteric things that not even Flusk checks for, like having an API call set as Data instead of Action.

georgecollier · 2024-10-24T12:36:05.629Z

CleanShot 2024-10-24 at 13.33.35@2x722×1316 33.8 KB

Big value-adds are:

privacy rules (handles data that is supposed to be public effectively too so won’t flag public listings in a marketplace for example)
page redirects (assesses if a page should be private, takes into account that content may be hidden on page load even if no server side redirect)
public backend workflows (identifies exploitable backend workflows e.g ‘sendemail’ that takes an email address and content parameter
known insecure plugins
leaking data in API calls, including API keys or user data
sensitive data stored in option sets

It’s just a one time audit vs Flusk which focuses on ongoing monitoring.

All of this without collaborator access.

randomanon · 2024-10-24T12:38:01.726Z

georgecollier:

content may be hidden on page load even if no server side redirect

Hidden how? You mean not loaded yet from a search?

georgecollier:

sensitive data stored in option sets

Interesting, I’m guessing you’re running some sort of Claude or GPT analysis on this? It can be pretty subjective.

georgecollier · 2024-10-24T12:38:39.921Z

randomanon:

Hidden how? You mean not loaded yet from a search?

You can securely have a client side redirect so long as the page’s content is invisible by default, and made visible by a server-side condition.

randomanon:

I’m guessing you’re running some sort of Claude or GPT analysis on this?

Yes, among other things

randomanon · 2024-10-24T12:42:36.605Z

georgecollier:

You can securely have a client side redirect so long as the page’s content is invisible by default, and made visible by a server-side condition.

When you say “visible” do you mean literally the “is visible” condition? My understanding was that conditionals have no effect on what’s loaded since it’s purely clientside. Meaning if the group is invisible on load and the condition says “Visible if Current Users’s Role is Admin,” someone can still see the group using dev tools.