I have a client I want to pitch tomorrow. I know they will ask to compare to other CMS like Craft CMS.
How secure is the CMS and data against cross scripting, sql injection and other attack’s? I have been looking but found nothing on it.
Thanks in advance.
The login / secured areas code and protection is secure and you shouldn't be worried about:
You are in full control of your files and uploads. No scripts are included on the fly, so there is no chance of XSS
Server Connect and Database Connector/Updater use strict parameters for all their input values, so No SQL Injection is possible. You can also add additional validation rules to all the input parameters to make sure they are what you expect - next to be even more secure it allows you to detect errors more easily.
We have integrated Security Provider so you can limit the access and data availability of your site on various levels. You can create and secure admin areas, you can limit data availability to certain users and groups.
You can also create accounts with encrypted hash values as passwords so that those are stored fully secure as well.
Generally every modern security feature that you need in a CMS is already available in Wappler.
We have been working on those security components for years. Server Connect appeared first in 2013 as server components for Dreamweaver with our DMXzone extensions.
So everything is well tested and strengthened through the years.
Prefect. Thanks so much
Thank you for sharing this info, I had the same questions. 
Is this going to be an issue? https://snyk.io/vuln/SNYK-JS-JQUERY-174006
Chrome Audit is telling me to avoid jQuery 3.3.1 which is included automatically in my Wappler project due to a Medium-level security vulnerability.
Recommended action is to update to jQuery 3.4.0/1
Most hosts these days secure against the most common form of injection via rulesets. Although not perfect they do offer reasonable protection. Server Connect offers good integrity checking and security which further bolsters the standard rulesets. Still good practice on account of the developer is important. Try to allow only certain database users access to all features. If a user (database user) does not require write or update, delete, don't assign it to them. Just the basics really. Brush up on the techniques to undertake injection and then you will have a good idea of how to defend against them.
For example we have database users that just have the read permission. It may take five minutes longer to add connections for multiple database users based on permissions but it is worth it (server Connect allows you to do this in minutes, and, further to that, then apply permissions based upon restrictions set in the Security Provider to other user group data contained in your database tables, such as a user registration table with a group field). Then we have users with replace, update, and delete, and variations of these permissions. For some this may appear as overkill... But to us is good practice to separate your eggs!