Thanks a lot. Loving this already.
1 Like
That is in DW extension only (using an older version of database connector there than in Wappler) and actually it’s just we forgot to remove the limit input from there.
1 Like
Yes you can. If you have the foresight and planning, and an understanding of dynamic data and database basics. If you enter in to Wappler with these fundamentals you can create whatever you require including very powerful applications. It will be your skill as a Developer that dictates how far you can extend the capabilities of Wappler.
This is the same for any website pretty much (especially Wordpress, Joomla, and off the shielf mainstream CMS platforms)… If someone wants in they will generally find a way. Usually through the back-end by exploiting unpatched vulnerabilities on the server for example. Wappler can not protect against such a threat. That is really down to the host or developer to safeguard and audit respectfully. Saying that we have used DMX and Wappler codebases on multiple projects on various platforms, and to our knowledge the codebase has not been exploited. Where as we have seen many Wordpress deployments exploited in the same environments. Just maintain everything, update all libraries, audit your code (check time-stamps and server logs, set up correct permissions for your back-end, be sensible, be on top, and take responsibility).
My two cents 
3 Likes
if HTML + JS + PHP can build it
then wappler can. there is no fixed limit on anything by wappler
1 Like
All of the above but with one priviso that I think should be coming soon - server-side API integration
then the sky isn’t even your limit 
1 Like
@Teodor I checked the source on some showcases, and my own app and found that all the server connect components with their URL & GET parameters are exposed in the source. Isn’t that something to be concerned about?
Applying server side security as given in below tutorial does help, but is that enough?
For actions which already print the results on your page, that is not an issue. You can already see the same results on a page that is public…
Of course in your admin part you should take care of protecting your data, but that is valid for any kind of website - build with or without Wappler.
For the admin part, I do have security restrict in place and it works well. But, does having the names exposed pose a threat to abuse of API?
Before Wappler, I have used ajax for API calls, and URLs are exposed there too, but they are not as easily visible in a series of lines as here.
Also, could you please suggest any more general measures for protecting the API & data, besides security restrict action?
Not really - the server action only returns the data you are using on the page… all you can see is a json file with the data you see on your page.
That’s pretty much enough for the server action which require to be protected.
1 Like
@nshkrsh just for your info - even the web apps of big companies like DHL are using the same API calls, which are clearly accessible in the console:
This is true. But as you had written earlier, for public pages, this is not an issue. 
My main concern was for the admin pages, for which security restrict seem to work great!
2 Likes
web apps made using wappler is secure. when you use it correctly and i have tested a website with netsparker and no vulnerabilities where found
3 Likes
Thats great to hear! I am a bit less worried now. 
Do you have any particular suggestion regarding securing Wappler apps, besides the security restrict action?
As serious as a heart attack.
… unless your query includes data which you are not displaying on the page.
Something which may not be obvious to people starting with Wappler is that whatever data is included in the query is easily accessible - whether or not it’s displayed on the page. Eg if someone chooses the default asterisk/all fields, that could be a security issue (eg if your products table includes your cost prices). I’m referring to pages which are publically accessible, not backend pages which can be protected of course. (Or am I wrong, and there is a way to prevent access to this data?)
Well, we already discussed this a few times, but again - this is not Wappler related. That’s something valid for all the tools out there from hand coding PHP to any tool you can think of.
That’s basics of designing your data structures.
There is no logical reason to include data which you don’t want to show on the page, in your query…
That’s why the query builder allows you to select only the database fields you need to use on the page.
1 Like
I appreciate it’s not Wappler related and is not an issue specific to Wappler, but it may not be obvious to or expected by new Wappler users who have just used PHP to connect their databases before for example. I think people are usually surprised to realise the data is accessible in the way it is.
By default, creating a new query in query builder creates a SELECT * query - ie by default all of the data is included whether you intend to display it or not. I expect new users tend to accept defaults without realising the implications. Of course you don’t want to alarm people, but I think perhaps there should be some information about this somewhere - docs or query builder.
Tom I think you just make something really simple look complicated, which will provide some kind of false alert about the site security to the new users…
There is nothing else that needs to be explained in the docs than what is already explained: “select the columns you need and add them to the query builder”.
There are no security issues with that.
There is nothing users have to be scared of…