Securing Your APEX Apps: Client Side Logic

Oracle APEX is a powerful low-code development platform that enables rapid application delivery. But with speed and ease comes a common pitfall: trusting client-side code for critical operations. This is one of the most prevalent and dangerous mistakes developers make, especially early on.

In this post, we’ll explore why the first step to securing your APEX apps is understanding the difference between client-side and server-side code, and why you should never trust the client with business logic, data operations, or security checks.

What Is Client-Side vs. Server-Side Code in APEX?

Let’s start with the basics.

• Client-side code runs in the user's browser. In APEX, this includes JavaScript, Dynamic Actions (that run “in browser”), and anything rendered in HTML or controlled by CSS. It’s fast and great for user experience, but also completely exposed.

• Server-side code, like PL/SQL processes, validations, and conditions evaluated on the server, runs securely on the APEX engine (and ultimately the Oracle DB). The user can’t see or alter this code.

Developers often fall into the trap of thinking that hiding or disabling elements on the page is enough. But everything rendered in the browser can be manipulated by the user.

Common Mistakes:

• Hiding buttons with JavaScript: Users can simply unhide them using browser dev tools.

• Disabling fields via Dynamic Actions: A user can re-enable them in seconds with the console.

• Relying solely on client-side validation: A user can bypass validations by either intercepting and modifying HTTP requests or simply modifying the client side code.

• Insecure SQL Concatenation: A user can send SQL queries inside an item that get executed by the database, granting them full access.

Bottom line: if your security measures depends on what’s happening in the browser, it’s not secure.

What we found

When working with customers, we often discover their apps to be insecure and to have been developed while trusting the client-side implicitly. Very often javascript is used solely to check that text is safe to be stored in the database. These can be bypassed very easily by simply changing the function code, this could lead to potentially XSS or data issues that could expose your users personal information as well as causing data issues in the application that could lead to your users facing errors.

In the worst cases we saw user input concatenated into SQL queries, this could lead to 'SQL Injection' attacks which would allow the user to expose the content of the entire database. This could include sensitive user data. Fixing SQL Injection issues is often very simple (just avoid using user input in queries unless correctly sanitised) but lots of developers neglect considering it.

These examples are all a result of application developers not thinking about security while developing the applications. The next section will guide you on how to think like an attacker to hopefully mitigate the issues in your apps.

How do attackers see your apps?

As developers, it's easy to focus on the "happy path", the expected user behaviour, without considering how a malicious actor might approach the application. However, attackers view your app very differently. They will actively probe it, manipulate it, and attempt to bypass every control in place. A disabled button, for example, is quickly re-enabled in the browser just to see what it triggers. They’ll inspect your application's HTML and JavaScript in detail, looking for exposed or vulnerable components such as unsecured AJAX callbacks, which they can exploit to access or manipulate data improperly.

To build secure applications, you must adopt this mindset yourself. Think like an attacker: question every client-side control, assume nothing is safe just because it's hidden, and always consider, “What could be manipulated here by someone using developer tools or modifying the client-side code?” This shift in perspective is essential for writing secure, resilient code.

What We Do at RADAPEX

At RADAPEX, security isn’t an afterthought, it’s baked into every step of our development process. We understand that building secure Oracle APEX applications means going beyond best practices and into a culture of continuous testing and validation. Every feature we develop undergoes automated security testing along with a multitude of other automated checks that ensure we are developing applications following industry standard best practices.

We pen-test our own apps early, often, and aggressively. Before any code hits production, we conduct targeted penetration testing on the features it introduces, this occurs during the pull request stage. This includes probing for insecure AJAX endpoints, broken access controls, and client-side assumptions that could be exploited.

Security reviews, code audits, and threat modelling are all part of our development lifecycle and definition of done. Whether it's validating that a button can't trigger unauthorised actions or simulating attacker behaviour against a new report page, we’re constantly thinking like an attacker so our clients don’t have to.

We also partner with trusted external security specialists to independently assess our applications, uncover any hidden vulnerabilities, and deliver comprehensive third-party validation, giving our clients added peace of mind and confidence that their systems are not just secure, but expertly tested and industry-approved.