Quick update (@mike_verbruggen):
I talked to Bubble about the possibility of using Javascript to “fake” a server-side Bubble action and exploit the fact that a lookup will produce a result regardless of privacy rules. As suspected, it’s not quite that easy.
The way I understand it based on these conversations is that Bubble doesn’t accept any server-side actions that it doesn’t recognise as part of the app itself. In other words, if an action exists on the page that makes changes to a database record (that could potentially be found via a lookup even when protected with Privacy Rules), there’s potentially a chance that a hacker would be able to trigger that workflow and make those changes. But - only if you as a developer left the action unprotected to begin with by not including conditions. As I touch upon in the book, constraints on server-side actions are also performed server-side (when possible), meaning that the action will be stopped on the server as long as the condition is there. The way I see it then, any vulnerability introduced as part of this logic is the fault of the developer, and not Bubble.
All that being said, this emphasises the importance of protecting both database (privacy rules) and workflows (server-side conditions) - not setting just one of them.