TIP: Server Actions are not restricted by default

[kfawcett]

I didn’t realize this before. If you do not add the Security Restrct action to your Server Connects, then they are wide open for anyone to query. Add a Security Restrict at the top to keep them locked down.

[Apple]

I wrote about this if you want to join the discussion

Do we really need to Server Restrict every single Server Action we want to protect?

Do we really need to apply server restrict to each server action we want to protect? e.g.: /admin/user/delete Wouldn’t it be better to just apply the server restrict to a group of routes? e.g. /admin Am I missing something? It feels like Wappler didn’t nail this right yet. In other frameworks we have middlewares, so we can apply common logic to a group of routes instead of manually going to every possible page/server action we want to protect Manually protecting every single Server Action is …

[kfawcett]

Maybe George or Teodor could merge these two, but I think the topics are slightly different as mine is just a tip to add the Security Restrict, and yours appears to be more about designing it differently. I prefer their granular design now, but I can also see the desire for the option to group them.

As for this topic, I didn’t realize I needed to add a Security Restrict action at all. Part of the confusion, I think, was because a lot of my actions needed the Security Identity to function and I got in the habit of setting “credentials” on all of my Server Connects. But recently I created some Server Connects that do not need the identity, and it was only when I started building them into my App Flows that I noticed they were not restricted.

This led me to add a Security Restrict to most of my Server Connects and that has shown another issue that needs fixing.

Server Connects in App Flow do not have "Credentials" flag

Wappler Version : 5.8.2 Operating System : Windows 11 Server Model: node.js / Capacitor Database Type: N/A Hosting Type: docker Expected behavior App Flows with Server Connects should be able to work with security-restricted Server Actions by sending the logged-in user’s credentials. Actual behavior 401 Unauthorized responses are returned. How to reproduce Create a Server Connect action that has the Security Restrict action [image] In a mobile project, create an App Flow and add the Se…

[Teodor]

The server actions are not restricted by default. There are many cases where the data need to be displayed on the front end and doesn’t need any protection.
It’s up to you to restrict the server actions, which are supposed to be used in your admin panel / cms etc. and the ones that are not supposed to serve publicly available data.

[kfawcett]

I fully understand the logic between allowing something to be publicly available or not, but just wanted to let others know if they mistakenly thought they were locked down like I did. This one mistake could mean other app developers are accidentally exposing their data publicly.

It would be better to have everything restricted by default and require explicit roles/permissions to allow access (i.e. admin only, subscriber, public, etc.)

Just look at S3 as an example for why restricting by default should be the norm. There’s too many data leakages and mistakes that developers can make to not require explicit access.

Why Amazon S3 is a ransomware target and how to protect it | TechTarget