Tackling The OWASP Top 10 in Oracle APEX: Part 1

Introduction

The Open Worldwide Application Security Project (OWASP) Foundation is a non-profit organisation dedicated to increasing the security of global software through community-led open-source software projects. The OWASP Top 10 is a regularly updated awareness document on the 10 most critical application security vulnerabilities.

OWASP uses many criteria to assess the top 10, including but not limited to: exploitability, detectability, prevalence, and technical impact. It is important to recognise that the OWASP Top 10 is not a checklist or a complete compliance standard. Instead, it should be used to raise awareness about the most common vulnerabilities in applications and prompt organisations to prioritize security.

Oracle APEX houses many built-in security features, such as cross-site scripting (XSS) defense, session state protection, authorization schemes, and SQL injection prevention. However, the responsibility of security lies with the developer building the application to use these features correctly and leverage their full capabilities.

In this blog series, we’ll address each of the OWASP Top 10 (2025) vulnerabilities and how to mitigate them in Oracle APEX applications, starting with the top 3 in this blog. No more yammering, let’s get straight into our first vulnerability.

A01: Broken Access Control

OWASP describes Broken Access Control as the failure to enforce restrictions on what authenticated users are permitted to do. Typical examples include:

• Viewing another user's data by modifying a URL or request parameter.

• Accessing administrative pages without administrator privileges.

• Performing actions through hidden or disabled UI elements.

• Changing data belonging to another user.

• Circumventing client-side restrictions.

• Accessing APIs or AJAX endpoints that lack server-side authorization checks.

Oracle APEX, like any software tool, cannot infer your application’s business logic or processes. Most access control issues therefore come down to incorrect or missing authorization checks, or the assumption that hiding functionality is the same as locking it down.

An example of this is pages and page items with no authorization scheme attached. In Oracle APEX, all pages and page items can be assigned specific authorization schemes that will block any unauthorized users from rendering the page. In many applications, however, this feature is forgotten and pages are left completely open. A naive developer may think, ‘there are no links to this page, so the users cannot access it.’ But this is a flawed mentality, as a malicious actor can simply use probing or simple guessing to find URLs that link to hidden pages. 

This also applies to row-level data security. SQL queries are often left completely open to all users, with no authorization or verification that the requesting user can access specific rows. RADAPEX has a brilliant blog on securing report row actions. Access to data should always be constrained by checks in the WHERE clause, using database views, or using Virtual Private Databases (VPDs).

The best practices for mitigating Broken Access Control are:

• Apply authorization schemes to ALL application pages that are not public (an example of a public page is the Login page)

• Never assume that hiding a button or menu item secures its functionality

• Always validate requests on the server-side.

• Always filter data to only display what a user is permitted to see

• Protect all AJAX callbacks and REST endpoints with appropriate authorization

• Always apply the Principle of Least Privilege (see below)

The Principle of Least Privilege states that: ‘A user, process, or application should be granted only the minimum permissions necessary to perform its intended function and no more.’ This is the key rule for ensuring that actors cannot exploit your application’s access control configurations.

Although the OWASP Top 10 is not considered a ranking, there is a reason that Broken Access Control is #1. This is the most prevalent and impactful category in the list because it undermines the fundamental trust model of the application. When applied consistently, Oracle APEX’s native features provide a strong baseline for addressing Broken Access Control.

A02: Security Misconfiguration

In its testing, OWASP found that 100% (that’s every single one) of the applications in the contributed dataset contained at least one form of security misconfiguration, making this a very significant threat. Security Misconfiguration may appear in an application as:

• Unnecessary features enabled or installed.

• Default accounts enabled and their passwords unchanged.

• Lack of intercepting of error messages.

• Excessive prioritization of backward compatibility leading to insecure configuration.

• Security settings in servers or frameworks not set to secure values.

During development, Oracle APEX provides debugging capabilities that present information about processing. These diagnostics are invaluable when developing an application, but they should never be available to ordinary users in production. If debugging is left accessible, an actor may gain insight into application logic, page processing, database object names, PL/SQL packages, and error conditions.

Similarly, verbose error messages reveal stack traces and other private implementation information to users. Error handling should always be configured to give users a clean, informative error message that does not expose your application’s logic. See our previous blog on Error Handling in Oracle APEX for help with configuring this.

Finally, another common vulnerability is that environments are often configured differently. If certain configurations are set to different values in development and production, it is important that deployment processes are configured to automatically set the correct values. If a manual developer action is required to configure deployments into different environments, it becomes extremely easy to misconfigure the application and leave vulnerabilities open. It is essential that your application has a pipeline that will automate the configuration for all of your environments.

Security Misconfiguration is often considered a ‘silent’ vulnerability because nothing is technically broken, it can be difficult to recognise these vulnerabilities when they occur and can be even more difficult to configure them correctly, which is partly why this is considered such a large threat. By adopting repeatable hardening procedures and reviewing security configurations regularly, developers can greatly reduce attack surfaces of their Oracle APEX’s applications and reduce the likelihood of a configuration-related attack.

A03: Software Supply Chain Failures

In the Top 10 community survey, 50% of respondents ranked this vulnerability as #1. According to OWASP, "supply chain failures continue to be a challenge to identify," with testing showing that supply chain attacks had the highest average incidence rate of 5.19%. Supply chain failures are described as breakdowns or compromises in the process of building, distributing, or updating software. In the context of Oracle APEX, this can come in the form of outdated APEX / ORDS versions, third-party plugin dependencies, external JavaScript libraries, or CI/CD pipeline compromisation.

Oracle APEX applications typically have fewer external dependencies than applications built with modern JavaScript frameworks or other tools. Much of the functionality that would otherwise require third-party libraries, such as charts, reports, forms, authentication, and REST integration, is provided natively by the platform. This reduces the attack surface, but it does not eliminate software supply chain risks as a threat.

One of the most common vulnerabilities is running outdated versions of Oracle APEX, Oracle REST Data Services (ORDS), or the Oracle Database itself. Oracle regularly releases Critical Patch Updates (CPUs) that address newly discovered security vulnerabilities. Organisations should establish a regular patching strategy to ensure they remain on supported versions and apply security updates in a timely manner.

Third-party APEX plug-ins should also be treated with caution. While plug-ins are an excellent way to extend the functionality of an application, every plug-in introduces additional code that becomes part of your application's trusted codebase. Developers should only install plug-ins from reputable sources, review the source code where possible, and remove plug-ins that are no longer required. The same principle applies to any external JavaScript or CSS libraries included in an application.

Finally, many organisations now deploy Oracle APEX applications through automated CI/CD pipelines. These pipelines, along with source code repositories and developer workstations, form a critical part of the software supply chain. If an attacker compromises a source code repository, deployment credentials, or build server, malicious changes could be deployed into production without directly attacking the application itself. Development environments should therefore be secured with multi-factor authentication, role-based access control, branch protection, and code reviews to reduce the likelihood of unauthorised changes entering the deployment pipeline.

Software supply chain failures differ from traditional application vulnerabilities because they exploit the trust placed in the external software and services used to build and deploy applications, rather than weaknesses in the application's own code. Oracle APEX's comprehensive low-code platform helps reduce dependencies, but developers must still maintain a disciplined approach to patch management, dependency review, and secure deployment practices. By keeping the Oracle technology stack up to date, carefully evaluating third-party components, and securing development and deployment infrastructure, organisations can significantly reduce their exposure to software supply chain attacks.

Conclusion

This marks the end of the first part in this blog series on Tackling The OWASP Top 10 in Oracle APEX. Hopefully, you have learned a few things about application security and can apply these principles to your own applications. If you wish to learn more about the OWASP Top 10, watch this space for Part 2 in this blog series, or check the official OWASP website.

As usual, don’t forget to check the RADAPEX blog page and RADAPEX on LinkedIn to read more of our blogs and success stories.