Low-code software builders will take off your hands most boring and repetitive tasks, which includes the security of your web application. Apps, created by PHPRunner and ASPRunner.NET follow all the security standards and secure out of the box. Your projects will be protected from SQL injection, XSS, CSRF, and more. If you’d like to know more about the most common web application vulnerabilities check OWASP Top Ten Security Risks. In this article, we will discuss additional security measures that are not directly related to the generated code but nevertheless are extremely important. If you ever need to build a public web application you need to go through this checklist and make sure your application complies.
1. Location of file-based database
If you use a file-based database like MS Access ( you should not ), make sure that the database file is not accessible directly via the internet. The best option is to place it outside of the website root folder. Otherwise, an attacker can eventually guess the location and name of your database and download it.
2. Location of uploaded files folder
The same applies to uploaded files, the best option is to use a folder, that is not directly accessible via the internet. In PHPRunner and ASPRunner.NET for this purpose, we use the ‘Absolute path’ option while specifying the path to the upload folder.
3. Use HTTPS
This is an extremely common requirement these days, some web browsers won’t even let you open an HTTP website. You can even use free SSL certificates provided by Let’s Encrypt.
4. Use all the latest versions of all server software
If you run your own web server, make sure that all the software is upgraded to the latest versions. This is especially true for any public-facing software like IIS, Apache, PHP and ASP.NET.
5. Password hashing
Turn on password encryption. If your database ever gets compromised, attackers won’t be able to see users’ passwords. This may prevent unauthorized access to other websites if users do not follow the “separate password for each website” practice.
6. Use Two-Factor-Authentication
This is also now a standard for most websites that store any potentially sensitive data. PHPRunner and ASPRunner.NET support 2FA via SMS, email, and apps like Google Authenticator. Enable 2FA in the software and encourage users to enable and use it.
7. Data encryption
Encrypt sensitive data in the database like social security numbers, addresses, birth dates, etc. If hackers ever get access to the database they won’t be able to see the encrypted data, unless they also have access to the encryption key.
Data Encryption is a part of Enterprise Edition of PHPRunner and ASPRunner.NET.
8. Properly configure access permissions in the software
This is kind of obvious but it made OWASP Top Ten list. Make sure that each user and user group only has access to those pages and data that they are allowed to see. For this purpose, in PHPRunner and ASPRunner.NET use User Group Permissions and Advanced Security options like “Users can see and edit their own data only”.
9. Turn off detailed error messages
Detailed error messages can reveal important info like file names, table and field names etc. Turning detailed error messages off can be done in IIS settings for ASPRunner.NET and in PHP settings for PHPRunner. Also in the software itself choose to display a generic error message.
10. Prohibit remote access to your database
Make sure that your database is only accessible locally, from your web server. Opening the remote access invites brute force attacks and also increases the load on your database. Setup firewall rules that would prohibit remote connections.
For development purposes, use a local copy of your database.
11. Prevent SQL injection in your own code
While all the core code generated by PHPRunner and ASPRunner.NET is fully protected from the SQL injection, you need to take care of this in the code you add to events. For this purpose, you can use PrepareSQL function that will take care of this.
12. Avoid storing sensitive data in your database when possible
For instance, instead of storing credit card info in your own database use a service like Stripe to process credit cards. This way credit card info never touches your server and you do not need to worry about PCI compliance which is a major pain on its own and an overkill for most projects.
Adding Web Application Firewall as an extra level of protection
Web Application Firewall (WAF) is software that helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. Examples of popular web firewall software are Fortinet FortiWeb and Sucuri Website Firewall. Personally, we found configuring WAF time-consuming and providing little benefit. It may work well for your application though.
Preventing automated attacks
You do not want hackers to run automated scripts to brute-force your passwords. To prevent this from happening you can use built-in features like ‘Lock user account after three unsuccessful logins’, two-factor authentication and reCAPTCHA.
Testing for vulnerabilities
How to test for vulnerabilities and how to interpret the results? Most companies use a vulnerability scanner to assess their web project’s security. The most known products in this area are Acunetix and HCL AppScan (formerly IBM AppScan). These products will test all the pages of your web application against known vulnerabilities and create a report listing everything they found.
It is important that developers and the team that runs the vulnerability scanner work together to interpret the results properly. Let me give you an example. There is a vulnerability called “blind injection” (there in fact multiple versions of it like blind LDAP inject, blind SQL injection etc). The idea is to send a different set of request parameters to a certain page and your app should not indicate that parameters were and should return exactly the same output. The idea is not to provide any feedback and make parameter guessing more difficult.
One of the customers was running a vulnerability scanner against a PHPRunner app. First, the scanner executes a normal load of the list page. Then it adds a random parameter to that list page call and runs it again. The output was different and the scanner marks it as “critical vulnerability”. Turns out, they ran the vulnerability scanner against a live database that was constantly updated and the difference between the two requests was just a number of records in the database table as someone just added a new record between these two tests. This is why it is important to interpret the results properly.
1 thought on “Building secure low-code web applications”