Make all APIs restricted by default

[kfawcett]

This request is to switch APIs from being unrestricted by default to restricted by default. If an API needs to be open then a “Security Unrestrict” could be added to the API.

This is a better approach to ensure data is not leaked unintentionally by Wappler developers that miss the step or do not know better.

This comes up every so often in posts and I would wager many Wapplers are exposing their data like this unsuspectingly.

TIP: Server Actions are not restricted by default

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 defau…

Privacy Settings Equivalent and Database Security in Wappler

Not only GETs. Any method. What you are trying to convey I think is that browsers will send GET requests by default when you visit a URL. But you can also send a POST and retrieve data. Actually with any type of request(GET, POST, PUT, PATCH, DELETE). It all depends on the server implementation. So secure everything that can be secured.

[NodeJS] About the "uploads" directory

It didn’t create an uploads directory in my project. With NodeJS it will be possible to upload files outside of the public folder, so that they are not accessible from the internet. I think the uploads directory will be the default directory for that. The advantage is that you can secure your files, create a server connect action with a security provider on it that restricts it to logged in users only which can then download the file.

Identity false

All you need to do is add a Security Provider and Security Restrict steps above your Server Connect queries. Can specify login and forbidden redirection within the Security Restrict dialogue. That will protect your API calls and only allow logged in Users to execute them.

Wondering what is the general rule for security in each server action (e.g. just security provider, or both SP + SR)?

Ok Personally, I would be putting a security restrict on pretty much every server connect file. I mean I guess you just ask yourself, would you want someone to be able to access the output of the server connect file (whatever it is) without being logged in?

[brad]

I think this is a great idea. Definitely voted.

[mgaussie]

Voted, great idea.

[Apple]

I think a better approach is to specify which group of routes should be protected. Refer to a past topic of mine, though I don’t think a feature request is open:

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 …

[TMR]

Voted. ‘Restricted by default’ needs to be the default. @Apple idea of having groups of them is a good one, it’d certainly save a bit of set up time and make it easier to secure a lot of APIs with one click

[Hyperbytes]

But restricted how, any logged in user? Specific user?
As user role can differ it is difficult to be generic?
I mainly use security restrict in an admin environment and adding a default general restriction would just be a nuisance.
Also how will the redirect work? To a fixed url set by wappler?
Perhaps this could be managed in site settings?

[kfawcett]

These are all good questions.

1. I think it would be an across the board restriction based on security identity. Role/permissions would not be related to this restriction.
2. I understand that adding a default restriction would be a “nuisance” for some, but not having data restricted is even worse. Inadvertently exposing data has much larger affects than the effort needed to explicitly unrestrict specific APIs.

Just look at AWS 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

3. I foresee this being something that is additive. For example, there is a global security restrict and anything added to the individual APIs could override it (i.e. a more specific Security Restrict or a Security Unrestrict on one API while all others fall under the global security restrict).

This would have the benefit of educating newer Wapplers that do not know any better and protect long-term Wapplers from making a mistake during development.

[Hyperbytes]

Perhaps three new options in the security provider.

A. Default restriction.

1. None
2. Any Role.
3. Specific role (activates select of all current defined roles for user to select)

Then two pickers for redirects if unauthorised etc.for page/route.
Any manually added restricts should override this.

Still not convinced it’s a positive option though, in my view far more api calls are typically public than are in need of security so will be more work in my opinion.

[Alexander_Paladines]

I don’t think so, personally I think that more of Wappler users develop Backends, and most of the Wappler functions today help in develop Dashboards, admin panels, etc (Login, backend stuff, etc). With that in mind, most of the API calls should be restricted and not public.

The opposite of what teodor say:

TIP: Server Actions are not restricted by default

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.

[Cheese]

How about a specific secured api directory which is restricted? Any Action within the directory is secured by default.

[Apple]

@Cheese that would require users to build apps with certain assumptions, too risky to assume users will follow such convention

[Cheese]

Last thing I want to do is spawn assumptions! After all they are the mother of all…

Maybe scrap that idea then.

[sid]

Not sure how this will work out with the role option in the security restrict functionality - without adding to confusion of the existing security setup.

I do not like/want this because we use our own mechanism for security - while using Wappler’s.
If this is going to be done on Globals level as a default, I would need an option to disable it.

[famousmag]

Hi everybody,

I would like to suggest an idea…
(I think I have read about it somewhere in here but can’t recall now…)

I suppose we all know the importance of holding our server APIs under folders.

So, I think it would be great if we could apply Security Restrictions on each folder:

• Every folder comes with a default Permission of “None” (means no restriction and no action/redirection at all)
  

  
  
  This way no extra actions and programming is needed from the Team for existing projects

• Every folder’s Restriction Permissions setup is reserving its subfolders Permissions.
  This means if we want a subfolder that only a few may have perimission on it, we have to set its parent folder to “None” so the subfolder is accesseable on first level and then applied its own permissions.

Of course, I don’t know how difficult is this to be applied by the Team…
I wish it was something that can be applied!

[franse]

Maybe this can help more than we think:

@Roney_Dsilva

Missed security restricts for API