But if someone can get that amount of access (the ‘super administrator’), I would have thought it’s probably likely they could destroy your database anyway.
Super administrator is an invented word in this context. He is just referring to give access to a specific user or group of users. But he could screw up the logic of setting te security provider. He could make a change to a role in the database or a bug with Security Provider could appear.
1 Like
Good reading between the lines there Jon, yes I meant a figurative super admin, just not sure how far the built in server connect security provider, or gate in your terms, in front of the gold actually protects whats behind it.
Of course, but my point is that there will be users who can delete records, change prices and customer details etc. If someone can get past the security features and have this control, they could wreck your database whether or not the type of features discussed in this thread have been implemented.
1 Like
It’s better than nothing 
But not enough. Not even close.
1 Like
If they get past Security Provider they can do whatever your API allows them to do.
If you don’t sanitize sql queries they can DROP a database.
1 Like
Are you suggesting it’s not possible to create secure systems with Wappler? If not, then whether or not features like this are implemented is not relevant. (I appreciate that it’s probably not possible for any system to be 100% secure.)
Lol, thats scary, as Tom says, we all have many server actions that allow users to delete records and update records, that we have stuck behind that gate, without really considering that the gate could be made of chicken wire.
There are many scripts I would hate a hacker getting to, that I put behind the trusty built in server side security.
Not exactly.
This.
1 Like
Yes, ok fair enough, this is a bigger one indeed
1 Like
Assuming backups are available, I can think of many situations where someone could do more damage changing values in a database table than deleting it entirely. It’s very easy to spot the problem in the second case.
So let’s keep the sites unprotected as we have daily db backups 
guys c’mon!
1 Like
I think you missed my point.
I think I will stick to my original idea of using this to do what’s needed and then removing the script off the local and server just to be extra sure.
This will be something that would possibly only be needed this one and only time anyways, no point leaving it there in my circumstances.
Here’s an example of a feature which could be implemented using dynamic custom queries (using the method suggested above). This is an advanced search form for searching accounting data (this is an image I’ve just Googled)
Obviously access to such a system would not be public-facing and would be require a log on system. The UI would mean only a very limited set of parameters can be sent to the query. The query itself could include further restrictions - limit tables, parameters, certain words (eg ‘DROP’, ‘TRUNCATE’ etc.).
Would this be a valid use of such dynamic queries? It’s a common UI feature.
If user input is inserted without modification into an SQL query, then the application becomes vulnerable to SQL injection. So the best practices to prevent this are:
- Parameterized Query
- Input sanitization
You can find a lot of information about this in Google, but remember nothing is safe forever so do your homework, make backups and keep reading about security stuff because while you build things every day someone discovers a new way to brake things. 
Another preventative measure I often use is when the query is only for reading data and not updating or deleting data, I will often use a second database user that only has read access.
Interesting, how do you set that up in the connection properties in Wappler?
That is quite a common scenario. Database read replicas.
They are used for increased performance in read applications and scalability though. Not so much for security purposes.
Most hosting accounts like cPanel you can set them up when you are granting your database user permissions.
Hetzner and Xneelo hosting accounts as well as many MS SQL Server accounts seem to have them as a default.
Docker in the standard Wappler setup screens sets up a root user account with a root user password as well as a normal Database User account with a different user password, which i assume is for the same thing, however I have not tested the grants differences between root and db_user so not 100% certain on that one.
The setup in Wappler is just another database connection, and whenever I do read type stuff only I use that connection instead of the main one.