When someone asks if an application is secure, it seems like a pretty straightforward question. Consequently, many would expect a straightforward answer: yes or no. For any developer working with any technology stack, the reality implied by that question is all too clear. It is often quite a complicated question and possibly a loaded one at that. This is especially true for web-based applications. There are multiple layers to consider, such as the database, front-end (web server) and platform or frameworks to consider. Then, there is the application in question itself. So when someone asks about Oracle APEX security, here are some of the aspects to that question that should probably be addressed and explained, as well as some tips and suggestions on how to go about uncovering any potential flaws in the system.
Securing the APEX Application
First and foremost, most inquirers are asking about the application itself and nothing backend or tech stack related. At this level, there are quite a few things developers can do to ensure their application is secure. This, in turn, can go a long way in reassuring their customers. To scan that app, use APEX Advisor. Oracle APEX includes it. It will report any errors, bad practices and security issues it comes across. Then there are third-party tools like APEXSec which is used at Oracle and we use it at Insum as well. It will also scan the target application, much like the APEX advisor. It will report any and all security flaws in a very thorough manner. Once these tools or other Oracle APEX Security alternatives have been used, the results can be used to both correct any issues and to reassure the customer of the hardened nature of the app.
Obscuring the Database
After securing the application, it will be time to tackle two other major aspects of application security. These are data and access to the application (or the database and the web-server). For the database, suffice it to say that the best practices should be implemented, such as encrypting or hashing sensitive data, using up to date algorithms and protecting any and all keys related to the process.
Another important aspect of this facet is to ensure permissions in the database are open only enough for the proper functioning of the application and no more. This is a simplistic answer, of course. This is a complex security issue. Just remember that the database itself should be hidden away in a private network with no way to access it outside that network. Proper care should also be taken to make sure that the server on which it resides is hardened as well. Other aspects in the context of Oracle APEX are not as critical, since most data breaches would only be possible or practical via the application itself with flaws such as SQL injection, which our first point should have
uncovered in the first place. But, one can never be too careful when it comes to securing their data.
Protecting the Middle-Tier
After the database, there is the front-end. In an ideal architecture, the front-end would actually include a web tier. This would act as a reverse proxy located in some sort of DMZ in a private network, and an app tier hidden behind it in the same private network as the database. You can access APEX via a few different servers. Oracle gives us several options. These are the EPG or embedded PL/SQL Gateway, OHS or Oracle HTTP server with mod_plsql and finally we have ORDS or the Oracle RESTful data Services app. Oracle recommends ORDS.
Production environments
For production environments, OHS and ORDS are ideal, for both performance and security. Since version 4.2 of APEX and version 2.0 of ORDS, RESTful services have been an integral part of what makes APEX such a powerful and attractive tool. So for that reason and because it is the recommended solution by Oracle, we will be looking at ORDS in terms of security concerns at this level of the stack. You can deploy ORDS in a container (app-server) or run it in stand-alone mode. Again, for production, don’t use standalone. So finally we are left with deploying ORDS in an app-server, of which the supported solutions are Glassfish, Tomcat and of course Weblogic.
Standard Hardening Practices for Oracle APEX security
Security wise all three share the same concerns and no major differences among the three require special attention. At this level, encrypting the connections using HTTPS (SSL) should be a top priority as well as following some standard hardening practices relating to whatever flavor of app-server was chosen. Those steps being things like removing or changing any default index pages, and closing access to any admin pages etc… ORDS itself comes quite solid out of the box. However, make sure the print debug to screen option is set to false. This is the default value. Sorry, didn’t mean to make you panic! Obviously, makes sure to set all other options to your needs as well.
Locking Down the Web Server
Finally, we come to the web-server. This machine is the door through which all traffic must pass when coming from the internet to access your application. Both the hardening of the application and this step will have the most impact on securing your application. The reverse proxy must filter the requests discarding anything not whitelisted. It should encrypt all communications with SSL (HTTPS). It should also contain as little information as possible about anything in the backend.
Following hardening guidelines here is very important. It’s particularly important to have a server with Apache correctly set up including a minimum encryption key of SHA-256 for the HTTPS certificate. This is the front line of your network. It is the gatekeeper for all communications between you and your customers or users. The good news is that hardening guides for Apache and other web servers are plentiful. You can apply a great deal of security with minimum effort.
That summarizes the four Oracle APEX security areas to cover. We haven’t gone into too much detail in this post. Still, it hopefully helps create a roadmap to more secure APEX application deployment and infrastructure.
