Support for PostgreSQL Row Level Security (RLS)

Feature Request
1

I would like to see this supported in the near future.

2

I decided to ask Copilot to give me a helping hand in promoting this request. This is the result:

:bulb: Why RLS Support in Wappler Matters

Row Level Security (RLS) in PostgreSQL allows you to define policies that restrict access to rows in a table based on the user's identity or session context. For Wappler users building multi-tenant apps, this means:

  • Cleaner logic: No need to manually filter queries by tenant ID in every API call.
  • Centralized security: Policies live in the database, reducing the risk of accidental data leaks.
  • Scalable onboarding: You can onboard new tenants without rewriting query logic.
  • Better separation of concerns: App logic stays focused on UX, while data access rules are enforced at the DB level.

:hammer_and_wrench: What Wappler Could Do

If Wappler added native support for RLS, it could:

  • Allow setting session variables (like current_user_id or tenant_id) on DB connection.
  • Surface RLS policy management in the UI or via Server Connect actions.
  • Provide guidance or templates for common multi-tenant RLS setups.

:mega: Community Momentum

Adding your voice here could help nudge it forward. :+1:

3

With Server Connect in Wappler, row-level security at the database level isn’t really needed - you can handle this securely by filtering queries based on the logged-in user, using Security Provider and the security identity ...

4

Thanks for the clarification! I completely understand that Server Connect’s identity filtering handles most use cases well, especially when queries are consistently routed through Wappler’s logic.

That said, I’m working on a multi-tenant project with sensitive tables, where PostgreSQL’s row-level security (RLS) provides an added layer of protection. It’s not about mistrusting the app layer—more about defense in depth: if someone bypasses Server Connect or a query slips through without proper filtering, RLS ensures the database itself enforces access boundaries.

For most Wappler workflows, your approach is clean and efficient. But in shared schemas, RLS offers peace of mind—particularly when compliance is a concern.

Appreciate the insight as always! Just exploring ways to balance convenience with robustness.

5

Hi Ben, totally get where you're coming from but please tell the AI writing this that if someone bypasses Server Connect that's a developer oversight :smile: The same kind of mistake can just as easily happen when misconfiguring RLS. No security layer is foolproof if it's not set up correctly.

1 Like
6

Thanks as always, Teodor. RLS was the catalyst that pushed me to convert from MySQL to PostgreSQL.

Now I find myself in a bit of a quandary: do I stick with Postgres, or retreat to the far more familiar territory of MySQL?

7

Postgres is a good choice of database even if you don’t use RLS

Another disadvantage of using RLS is that you have to maintain the users as real database users and not just list of users in a table. So you have to create them and assign security with database native functions.

Then you will have to pass the specific database user into your database connection that will not be able to be cached and reused because it is specific for that user.

8

Yup, I've been using supabase's RLS for a project that was mobile application only and it has become messy REAL quick. I also fell for the appeal of RLS, assigning read only permissions to generic user accounts, or the insert to be only allowed to those with the permissions,etc. But it quickly became a headache when performing joins, or other operations that generic/public pool of users were restricted to! Whenever I created new queries that required joins I had to modify rules to allow user query certain columns from restricted tables, otherwise? null or missing record in inner join case :man_facepalming: I have quickly switched the strategy to resort to wappler's backend with jwt authetication and with combination of library events for checking more nested permissions, I am able to perform much more complex workflows while also having the ability to join data from different sources with only disadvantage being that its processed via server therefore it needs to request and process data from the database instead of retrieving it directly , but with servers being in the same datacenter for end user its unnoticeable!

3 Likes
9

Great point that I missed when I researched RLS, thank you for mentioning this.

JWT's can be intercepted and the contents read, exposing any confidential information. I have been looking at asymmetric signing with keys managed via PKI to improve the security.

10

JWT’s aren’t designed for the information to be hidden, hence why they’re in base64. No confidential information should be stored in JWT, after all, basic information is enough for the client, and if JWT is tampered with, it won’t validate. And isn’t assymetrical pki signing just a different type of signing with the contents still being decodable? At the end of the day, JWT shouldn’t be used to store any sensitive information but the common information that could be used on the server side email, role, permission level, expiration of the token. ! Yet still maintaining the integrity when validating the token!

Edit: if you want to make it more confidential, references to the database records can be stored! That’s how I store multi level/nested permissions!

1 Like
11

And with your solution you need add that "filtering queries based on the logged-in user" in to each and every SQL Query.
Real life projects might have hundreds of them.

12

Sorry to disagree but i see user level filtering as going hand in hand with adding security restricts, it takes seconds and should be an integral part of your workflow.

13

I don't think that's true.
One of our clients has implemented RLS in a Wappler SaaS project.
I would have done this for another client's SaaS project, if I knew about it earlier.

Relying on Wappler's security restrict is not enough in any scenario when it comes to a SaaS project, contrary to what Teodor suggests.
Its extremely easy to mess things up when app grows - and this comes from 4 years of first hand experience of building a SaaS platform in Wappler.
Security provider is a great first level of defence, but for SaaS apps, not enough.

With the RLS that we have in another app, we don't have a DB user for every logged in user. We use transaction and a library action in every SA to configure the logged in user's access - so its sort-of easy to configure - and none of the queries need any additional conditions.
Its not the best, but without native support, this works well.

2 Likes