APEX Security

KScope 2025

Philipp Hartenfeller | Kevin Thyssen

18-JUN-2025 | Grapevine, TX

$whoarewe

Philipp Hartenfeller

  • Düsseldorf, Germany
  • Oracle APEX Dev since 2016
  • Product Lead at United Codes
  • WebDev and Databases

$whoarewe

Kevin Thyssen

  • Kapellen, Belgium
  • 15+ years with Oracle APEX
  • Senior APEX Consultant at United Codes
  • Cycling enthousiast
LinkedIn: kevinthyssen
United Codes

Agenda

(Shift + A: jump to Agenda, Shift + O: overview)

Introduction

CIA Triad

What can go wrong?

  • System Failure
  • System Misuse/Abuse
  • Sabotage
  • Espionage
  • Fraud
  • Theft

Scope

In these slides: Only APEX

Other areas:

Non-technical Technical
  • Physical Access Protection
  • Social Engineering
  • Site Selection
  • Enterprise Architectures / Personnel Roles
  • ...
  • Networks
  • Operating Systems
  • Encryption
  • Database Admin + Monitoring
  • Webserver Settings
  • ...

Read on

  • Expert Oracle Application Express Security
  • Author: Scott Spendolini
  • 22nd of April, 2013
  • ISBN: 978-1430247319

Know the architecture

Client vs. Server

What runs where?

Server Client
  • SQL and PL/SQL
  • Server-side conditions and authN/authZ-schemes
  • JavaScript and jQuery (exception: MLE)
  • Almost all dynamic actions
  • Items of type hidden

The client is the wild wild west

  • Filter sensitive data on the server
  • (Hackers can use browser dev tools, JS can be disabled)
  • Always check on the server if a user is allowed to do something
  • (Client-side checks can be tampered with)
  • Avoid using the javascript: pseudo-protocol
  • (e.g. javascript:$s('P1_ITEM', 'value');)

Demo

Client-side issues

Session State Protection / Checksums

What is SSR / a checksum

  • Goal: prevent user to change parameters (when they are not supposed to)
  • Works through hashing/checksums
  • Cryptic string consisting of value + server secret
  • Clients don't know the server secret, thus can't guess the checksum for a changed value
  • Example - link: /...?p12_id=3...&cs=1ldsBsao2j...

Demo

Checksums

Checksums to protect editing

Also apply for read-only items and hidden with protection enabled

            
              $s("P13_SAL", 1234);
              apex.page.submit({request: "SAVE"});
            
          

APEX Dashboard

SQL Injections

SQL Injections?

Users are able to input SQL that is executed

Source

Correctly bind in APEX

Use :P1_ITEM in SQL sources in APEX

Be careful when using dynamic SQL

When you see dynamic SQL anywhere your 🧠️ should be ⚠️️

  • Do you really need dynamic SQL?
  • Manually validate inputs
  • Bind values with :var (e.g. when using execute immediate)
  • Use dbms_assert
  • Use apex_exec or dbms_sql

Demo

SQL Injections

Cross Site Scripting (XSS)

XSS?

  • Users can input JS that gets executed
  • Basically JS-Injection
  • <script>alert('XSS')</script> in inputs

Where can it occur?

  • htp.p → use apex_escape pkg
  • Report columns, display items (RTE) → Attribute "Escape special characters"

Also possible

Demo

XSS

Additional Tips

Use DB features

  • Multiple schemas
  • Only grant necessary things to other schemas
  • Virtual Private Database

Scanners

Set up Single-Sign-On

  • Central AuthN
  • Less passwords

Smart APEX AuthZ

  • Rights: (see dashboard, see users, edit user, etc.)
  • Roles: (analyst, admin, guest, etc.)
  • Assign rights to roles
  • Assign roles to users
  • Shared Components -> Application Access Control

Logging

Infrastructure

Production

  • Don't develop in prod
  • Don't keep copies of apps in prod
  • You can easily scan for apps

Code

  • KISS - Keep it simple, stupid
  • Every piece of code you write is a liability
  • Pull-requests with code reviews

ORDS REST endpoints

  • Double check if all your endpoints require Auth
  • A simple API key check makes the difference
  • Implement rate limiting

OWASP Top 10

Q&A

Thank you!

philipp@united-codes.com

kevin.thyssen@united-codes.com

Slides at hartenfeller.dev