APEXlang Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/apexlang/ Database-centric development Mon, 24 Aug 2026 05:38:18 +0000 en-US hourly 1 https://wordpress.org/?v=7.1 https://www.salvis.com/blog/wp-content/uploads/2014/04/favicon.png APEXlang Archives - Philipp Salvisberg's Blog https://www.salvis.com/blog/tag/apexlang/ 32 32 The Checkbox That Disables TLS https://www.salvis.com/blog/2026/08/23/the-checkbox-that-disables-tls/ https://www.salvis.com/blog/2026/08/23/the-checkbox-that-disables-tls/#respond Sun, 23 Aug 2026 21:20:28 +0000 https://www.salvis.com/blog/?p=23591 Introduction The dbLinter clients include a new setting named Allow Insecure TLS. It is disabled by default. As a result, all REST API calls verify the TLS certificate and hostname. The setting allows dbLinter to work in organisations that inspect TLS traffic using tools such as Zscaler. In larger organisations, arranging an […]

The post The Checkbox That Disables TLS appeared first on Philipp Salvisberg's Blog.

]]> Introduction

The dbLinter clients include a new setting named Allow Insecure TLS. It is disabled by default. As a result, all REST API calls verify the TLS certificate and hostname.

The setting allows dbLinter to work in organisations that inspect TLS traffic using tools such as Zscaler.

In larger organisations, arranging an inspection bypass can be cumbersome and is often too much effort for an ad-hoc trial of dbLinter. The checkbox provides a temporary workaround and should be enabled only on a trusted network.

However, allowing insecure TLS on untrusted networks, such as open Wi-Fi without client isolation, can let an attacker redirect traffic through their own machine using techniques like ARP spoofing. The attacker can also operate the access point themselves, for example, by creating a rogue Wi-Fi hotspot.

In this blog post, I demonstrate the effect of this checkbox.

Allow Insecure TLS

The latest version of dbLinter for VS Code has a checkbox that disables certificate and hostname verification.

Allow Insecure TLS Checkbox in VS Code

dbLinter’s allowInsecureTls setting is nothing unusual. Many common tools offer a similar option, including curl (--insecure), wget (--no-check-certificate), and git (--config http.sslVerify false).

Installing and Configuring a Proxy

I run this demo on macOS 26.6.2.

A simple proxy is mitmweb. We can install and configure it as follows:

brew install mitmproxy
networksetup -setsecurewebproxy "Wi-Fi" 127.0.0.1 8090
mitmweb --listen-port 8090 --web-port 8091 --allow-hosts '^api\.dblinter\.app'
[20:36:20.907] HTTP(S) proxy listening at *:8090.
[20:36:20.908] Web server listening at http://127.0.0.1:8091/?token=f83b02032aaaccd282ad3925a484fcdb

The mitmweb command starts the proxy and listens on port 8090 for TLS traffic between localhost and api.dblinter.app. All other traffic is bypassed.

The mitmweb proxy also opens the following web page:

mitmproxy after start up

Intercepting Traffic

To generate traffic, we launch VS Code and open a SQL file. This produces the following in the output panel for dbLinter:

2026-08-23 20:37:43.216 [Info ] Starting dbLinter Language Server.
2026-08-23 20:37:43.539 [Info ] connect.
2026-08-23 20:37:43.611 [Info ] initialize VSCode 1.10.0.
2026-08-23 20:37:43.646 [Info ] didOpen file:///.../dbl_client_types.sql.
2026-08-23 20:37:43.651 [Info ] AntlrCacheCoordinator initialized with parallel degree 1 and clearCacheThreshold 2048 of 16384 MB.
2026-08-23 20:37:43.671 [Warn ] TLS certificate and hostname verification are disabled for dbLinter repository API calls. Use this temporary workaround only when TLS interception cannot be bypassed.
2026-08-23 20:37:45.533 [Info ] Configuration dbLinter of tenant Grisselbav loaded with 294 check methods.
2026-08-23 20:37:45.534 [Info ] didChangeConfiguration.
2026-08-23 20:37:45.703 [Info ] tests returned 43 tests.
2026-08-23 20:37:45.796 [Info ] parseAndCheck file:///.../dbl_client_types.sql.
2026-08-23 20:37:45.910 [Info ] hasFeature Config returned true.
2026-08-23 20:37:46.286 [Info ] parseAndCheck completed in 0.489 sec including 0.052 sec for checks.
2026-08-23 20:37:46.289 [Info ] diagnostics for file:///.../dbl_client_types.sql with 2 issues.

The log contains a warning that TLS certificate and hostname verification are disabled.

dbLinter analyses SQL and APEXlang files locally. The captured traffic lets us verify what is sent to the dbLinter API. It contains the API key and session data, but not the contents of the analysed files. The source code therefore remains within the local network.

mitmproxy request message

It goes without saying that it is not good to expose the API key in plain text.

The proxy also shows the decrypted response:

mitmproxy response message

The session object in the response contains a signature. The client can therefore detect changes to the signed content, including the validators. This prevents the proxy from silently modifying the validators or injecting malicious code. However, the signature does not prevent the proxy from reading the request and response.

Enforce TLS Verification

Now let’s uncheck the Allow Insecure TLS checkbox and execute the Reload Window command.

disallow insecure TLS in VS Code

This produces the following in the output panel for dbLinter:

2026-08-23 20:52:37.281 [Info ] Starting dbLinter Language Server.
2026-08-23 20:52:37.550 [Info ] connect.
2026-08-23 20:52:37.606 [Info ] initialize VSCode 1.10.0.
2026-08-23 20:52:38.047 [Info ] didOpen file:///.../dbl_client_types.sql.
2026-08-23 20:52:38.049 [Info ] AntlrCacheCoordinator initialized with parallel degree 1 and clearCacheThreshold 2048 of 16384 MB.
2026-08-23 20:52:38.375 [Error] Failed to load configuration.

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://api.dblinter.app/api/client-session/open": (certificate_unknown) PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The proxy presented a certificate for api.dblinter.app which was not issued by a trusted certification authority.

The proxy console therefore shows the following log entry:

[20:52:38.217][127.0.0.1:60439] server connect api.dblinter.app:443 (91.98.90.2:443)
[20:52:38.360][127.0.0.1:60441] client connect
[20:52:38.375][127.0.0.1:60439] Client TLS handshake failed. The client does not trust the proxy's certificate for api.dblinter.app (OpenSSL Error([('SSL routines', '', 'ssl/tls alert certificate unknown')]))
[20:52:38.377][127.0.0.1:60439] client disconnect
[20:52:38.380][127.0.0.1:60439] server disconnect api.dblinter.app:443 (91.98.90.2:443)

The REST API call failed before the proxy received the HTTP request. Therefore, the API key and other request data were not exposed.

Reset Network Configuration and Uninstall Proxy

Let’s stop the proxy by pressing Ctrl-C in the terminal window running it. Then run the following:

networksetup -setsecurewebproxystate "Wi-Fi" off
brew uninstall mitmproxy
rm -rf ~/.mitmproxy

Conclusion

The Allow Insecure TLS option solves a practical problem in environments where TLS inspection cannot easily be bypassed. However, it disables certificate and hostname verification. A proxy or an attacker controlling the network can then read requests, including the API key.

The captured traffic also confirms that dbLinter analyses SQL and APEXlang files locally. Signed server responses protect the downloaded configuration from manipulation, but they do not protect confidential request data.

Therefore, enable this option only as a temporary workaround on a trusted network. The preferred solution is to configure a TLS inspection bypass. Disable the option again as soon as possible.

The post The Checkbox That Disables TLS appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/08/23/the-checkbox-that-disables-tls/feed/ 0 Detecting Security Vulnerabilities With the APEXlang Parser https://www.salvis.com/blog/2026/06/29/detecting-security-vulnerabilities-with-the-apexlang-parser/ https://www.salvis.com/blog/2026/06/29/detecting-security-vulnerabilities-with-the-apexlang-parser/#respond Mon, 29 Jun 2026 12:12:21 +0000 https://www.salvis.com/blog/?p=19914 Introduction A parser for the APEXlang grammar enables the development of tools beyond the scope of the APEXlang compiler included in SQLcl, SQL Developer for VS Code, and ORDS. These tools can perform static code analysis, convert code, generate documentation, and visualise different aspects of an APEX application. A linter, for example, […]

The post Detecting Security Vulnerabilities With the APEXlang Parser appeared first on Philipp Salvisberg's Blog.

]]> Introduction

A parser for the APEXlang grammar enables the development of tools beyond the scope of the APEXlang compiler included in SQLcl, SQL Developer for VS Code, and ORDS. These tools can perform static code analysis, convert code, generate documentation, and visualise different aspects of an APEX application.

A linter, for example, can check whether an APEXlang file conforms to defined quality standards. These standards may cover project- or company-specific conventions as well as more general concerns, such as detecting potential security vulnerabilities.

In this blog post, I explain the elements of an APEXlang file that are the basis of Grisselbav’s APEXlang parser. Then I demonstrate how to use the parser in a simple Java program to detect a security vulnerability.

Elements of an APEXlang File

An APEXlang file consists of three basic building blocks: components, properties, and groups. These elements can also be nested, as shown later.

Here’s an excerpt of Oracle’s Universal Theme demo application.apx file:

1) Excerpt of UT’s application.apx
app UT (
    name: Universal Theme 26.1 Reference
    version: 26.1.0
    group: @universal-theme
    logo {
        type: text
        text: Universal Theme
    }
    // ...removed code...
)
Component

There is one component in this example. It starts on line 1 and ends on line 10. app is the type of the component and UT the component name.

A component body starts with a left parenthesis ( and ends with a right parenthesis ).

Property

In this example, we have 5 properties. The property keys are name, version, group, type and text. The value of a property follows a colon :. For name The value is Universal Theme 26.1 Reference, for version the value is 26.1.0 and so on.

Please note that a property starts on a new line, and the property value starts after the colon and ends on a new line. This way, no delimiter characters are required for most property values. However, if leading or trailing spaces are significant, you have to pass the property value as a single-line string, which is enclosed in double quotes.

Group (of properties)

The properties type and text are part of a group named logo. The group in this example covers lines 5 to 8.

A group body starts with an open curly bracket { and ends with a close curly bracket }.

Properties which are not part of a group are called direct properties. This means they are defined directly in a component. Examples of direct properties are name, version and group.

Nested Elements

We have seen that a component may contain properties and groups. But it is also possible to nest elements.

  • Components may contain other components besides properties and groups
  • Property values may contain groups besides simple values

There is no limit to the number of levels for nested elements.

Here’s an example:

2) Nested Component and Group
app UT (
    // ...removed code...
    pwaShortcut getting-started (
        name: Getting Started
        sequence: 10
        shortcut {
            target: {
                page: 500
            }
            description: Getting Started Page - Initial Page
        }
        comments {
            comments: -
        }
    )
   // ...removed code...
)

A nested component starts on line 3 and a nested group on line 7.

APEXlang Grammar

apxFile rule of APEXlang grammar

While the grammar documented in apexlang. ebnf of the API Reference defines both the language structure and the valid APEXlang elements, the grammar used by Grisselbav’s APEXlang parser is limited to structural concerns.

Because the parser focuses solely on syntax rather than semantic validation, the grammar remains remarkably compact.

Click on the image above to view all the syntax diagrams. Alternatively, view the ANTLR4 source files, ApexLangLexer.g4 and ApexLangParser.g4, which were used to generate the parser available on Maven Central.

APEX-SERT

APEX-SERT is an APEX application that scans a selected APEX application for security vulnerabilities. A vulnerability is detected by querying APEX dictionary views. All rules are defined in the APEX-SERT Rules.json file.

To demonstrate a practical use case, let’s look at the security check “Embed in Frames” implemented by APEX-SERT.

When the property “Embed in Frames” is set to Allow, the application may be vulnerable to “clickjacking” attacks as explained in the help text of the page designer. See screenshot below.

I changed the original value from Allow from same origin to Allow to simulate a security vulnerability.

APEX-SERT runs a query similar to the following to find violations of this rule:

3) Find Violations with SQL
select application_id, application_name, browser_frame 
  from apex_applications
 where browser_frame not in ('Deny', 'Allow from same origin');
APPLICATION_ID APPLICATION_NAME               BROWSER_FRAME
-------------- ------------------------------ -------------
        101252 Universal Theme 26.1 Reference Allow

So, the value of Embed in Frames is provided in the browser_frame column of the APEX dictionary view apex_applications.

But where can we find this information in the APEXlang files?

Link Page Designer Property to APEXlang

We find the “Embed in Frames” property in the page designer by navigating to “Shared Components” -> “Application Definition” -> “Security” -> “Browser Security”.

According to the apexlang. ebnf there is a security group within the app component. Here’s the relevant excerpt:

3) Property embedInFrames within apexlang.ebnf
<app-security> ::= <indent> "security" <ws> "{" <line-end> { <app-security-property-line> } <indent> "}" <line-end>
<app-security-property-line> ::= <indent> <app-security-property> <line-end>
<app-security-property> ::= "deepLinking" ":" <ws> ( "true" | "false" ) (* required; type: SELECT LIST *)
  | "enableDictation" ":" <ws> <boolean> (* required; type: YES NO *)
  | "browserCache" ":" <ws> ( "true" | "false" ) (* required; type: SELECT LIST *)
  | "embedInFrames" ":" <ws> ( "deny" | "allowSameOrigin" | "allow" ) (* required; type: SELECT LIST *)
  | "referrerPolicy" ":" <ws> ( "noReferrer" | "noReferrerWhenDowngrade" | "origin" | "originWhenCrossOrigin" | "sameOrigin" | "strictOrigin" | "strictOriginWhenCrossOrigin" | "unsafeUrl" ) (* required; type: SELECT LIST *)
  | "htmlEscapingMode" ":" <ws> ( "basic" | "extended" ) (* required; type: SELECT LIST *)
  | "httpResponseHeaders" ":" <ws> <multiline-string> (* type: TEXT EDITOR *)
  | "runtimeApiUsage" ":" <ws> <array-of-string-like-value> (* type: CHECKBOXES *)

We find on line 352 the definition of the property embedInFrames with a list of valid values. In this case, the property key is unique. This means that no other component or group uses the property key embedInFrames. Therefore, we can search the folder containing the .apx files for the string embedInFrames: to find the position of this property.

The matching property is located in the application.apx file.

Here’s an excerpt.

4) Property embedInFrames in application.apx
    authorization {
        runOnPublicPages: true
    }
    security {
        deepLinking: true
        embedInFrames: allow
        runtimeApiUsage: modifyThisApp
    }
    sessionStateProtection {
        allowUrlsCreatedAfter: 1999-08-04T00:00:00
        checksumSalt: 75BAAC4002F8CA56EF54FD242CCE7719B1AB85BE339E930260B3EC8EA3879365
    }

Please note that properties with default values are skipped when an APEX application is exported. Therefore, we would not see the embedInFrames property if its value were Deny.

Find Vulnerability With APEXlang Parser

We now have all the information we need. We can write a small demo program. This program will find this vulnerability in an APEXlang file.

The parser exposes the parse tree through ANTLR4-generated context classes. Each parser rule becomes a context class. For example, the class ApexLangParser.PropertyContext represents the property parser rule. This makes it easy to traverse the ApexLangDocument using Java streams.

5) DemoFindVulnerability.java
//DEPS com.grisselbav:apexlang-parser:0.2.0

import com.grisselbav.apexlang.grammar.*;

class DemoFindVulnerability {
    public static void main(String[] args) {
        var apxSource = """
                app UT (
                    name: Universal Theme 26.1 Reference
                    version: 26.1.0
                    // ... removed code ...
                    authorization {
                        runOnPublicPages: true
                    }
                    security {
                        deepLinking: true
                        embedInFrames: allow
                        runtimeApiUsage: modifyThisApp
                    }
                    sessionStateProtection {
                        allowUrlsCreatedAfter: 1999-08-04T00:00:00
                        checksumSalt: 75BAAC4002F8CA56EF54FD242CCE7719B1AB85BE339E930260B3EC8EA3879365
                    }
                    // ... removed code ...
                )
                """;
        var doc = ApexLangDocument.parse(apxSource);
        var violations = doc.getAllContentsOfType(ApexLangParser.PropertyContext.class)
                .stream()
                .filter(p -> p.name.getText().equals("embedInFrames")
                        && p.value().getText().equals("allow"))
                .toList();
        for (var violation : violations) {
            System.err.println("Found vulnerability: " + violation.getText());
        }
    }
}

This program embeds the APEXlang source code to scan in the apxSource variable. To run the program, save it as DemoFindVulnerability.java, then run it with JBang. This will automatically resolve the Maven dependency on the first line.

jbang DemoFindVulnerability.java
[jbang] Resolving dependencies...
[jbang]    com.grisselbav:apexlang-parser:0.2.0
[jbang] Dependencies resolved
[jbang] Building jar for DemoFindVulnerability.java...
Found vulnerability: 
        embedInFrames: allow

Are Regular Expressions An Alternative?

In this case, we could have used a regular expression to identify the violation.

However, as soon as the rules become more complicated, e.g. if we want to ensure that the property is part of the security group and the security group is part of the app component, regular expressions are no longer suited. But a parser is. Because we can navigate the parse tree and adjust the filter settings as follows.

6) DemoFindVulnerability2.java with extended filter
//DEPS com.grisselbav:apexlang-parser:0.2.0

import com.grisselbav.apexlang.grammar.*;

class DemoFindVulnerability2 {
    public static void main(String[] args) {
        var apxSource = """
                app UT (
                    name: Universal Theme 26.1 Reference
                    version: 26.1.0
                    // ... removed code ...
                    authorization {
                        runOnPublicPages: true
                    }
                    security {
                        deepLinking: true
                        embedInFrames: allow
                        runtimeApiUsage: modifyThisApp
                    }
                    sessionStateProtection {
                        allowUrlsCreatedAfter: 1999-08-04T00:00:00
                        checksumSalt: 75BAAC4002F8CA56EF54FD242CCE7719B1AB85BE339E930260B3EC8EA3879365
                    }
                    // ... removed code ...
                )
                """;
        var doc = ApexLangDocument.parse(apxSource);
        var violations = doc.getAllContentsOfType(ApexLangParser.PropertyContext.class)
                .stream()
                .filter(p -> p.name.getText().equals("embedInFrames")
                        && p.value().getText().equals("allow")
                        && p.parent.parent instanceof ApexLangParser.GroupContext g
                        && g.name.getText().equals("security")
                        && g.parent.parent.parent instanceof ApexLangParser.ComponentContext c
                        && c.type.getText().equals("app"))
                .toList();
        for (var violation : violations) {
            System.err.println("Found vulnerability: " + violation.getText());
        }
    }
}

Integration Into dbLinter

The APEX-SERT “Embed in Frames” rule has been added to the dbLinter repository as rule A-0770: Never allow application pages within an HTML frame. The VS Code extension, the CLI and the SonarQube plugin now support checks implemented for APEXlang.

Here’s a short silent video that demonstrates how this security vulnerability is detected and quickly fixed.

Conclusion

The APEXlang grammar is intentionally simple through focusing on structural elements, leaving semantic validation, such as valid property values, to the APEXlang compiler in SQLcl, SQL Developer and VS Code.

Integrating the APEXlang parser into dbLinter was straightforward, as was implementing the first APEXlang-based dbLinter rule.

The next step is to identify which additional rules would be beneficial to bring to dbLinter. If you have any suggestions, please let me know. Even better, open a GitHub issue in the dbLinter GitHub repository.

Thank you.

Updated on 2026-07-29, fixed link to rule “Never allow application pages within an HTML frame” (A-1010 → A-0770).

The post Detecting Security Vulnerabilities With the APEXlang Parser appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/06/29/detecting-security-vulnerabilities-with-the-apexlang-parser/feed/ 0 Syntax Diagrams for APEXlang https://www.salvis.com/blog/2026/06/19/syntax-diagrams-for-apexlang/ https://www.salvis.com/blog/2026/06/19/syntax-diagrams-for-apexlang/#comments Fri, 19 Jun 2026 14:22:37 +0000 https://www.salvis.com/blog/?p=19515 Introduction The APEXlang API Reference documentation went live a few days ago. You can also download the APEXlang EBNF grammar. In this post, Kris Rice explains the value of having an EBNF. Since the APEXlang grammar is available as EBNF, it can be used to generate syntax diagrams. These diagrams (also known […]

The post Syntax Diagrams for APEXlang appeared first on Philipp Salvisberg's Blog.

]]> Introduction

The APEXlang API Reference documentation went live a few days ago. You can also download the APEXlang EBNF grammar. In this post, Kris Rice explains the value of having an EBNF.

Since the APEXlang grammar is available as EBNF, it can be used to generate syntax diagrams. These diagrams (also known as railroad diagrams) make the language easier to explore and provide a visual complement to the API Reference.

In this blog post, I explain how to produce the syntax diagrams for APEXlang.

What Is EBNF

Wikipedia describes the Extended Backus-Naur Form. However, it’s important to notice that there are several variants of EBNF.

APEXlang EBNF

The APEXlang EBNF grammar uses a variant of the BNF in the SQL:2023 standard, with some extensions explained at the top of the apexlang.ebnf file.

1) Syntax conventions in apexlang.ebnf
(* Syntax conventions
   <nl> is significant: component declarations, groups, properties, and closing delimiters are line-oriented.
   [ X ] means optional X. { X } means zero or more X. A | B means either A or B.
*)

Square brackets [] indicate optionality, while curly brackets {} enclose a repeated group as defined in ISO/IEC 14977. However, the apexlang.ebnf file does not fully use this ISO EBNF standard. apexlang.ebnf uses ::= while the ISO standard uses a simple = for symbol definitions. This variant resembles a Wirth EBNF with comments.

Here’s the definition of the app rule in the apexlang.ebnf file.

2) app rule in apexlang.ebnf
<app> ::= "app" [ <required-ws> <component-id> ] <ws> "(" <line-end> { <app-body-line> } <indent> ")" <line-end>

Syntax Diagram

This is the syntax diagram, or railroad diagram, for the app rule.

I produced this syntax diagram with the Railroad Diagram Generator (RR) by Gunter Rademacher. However, this tool requires a W3C EBNF as input. In other words, the original apexlang.ebnf produces runtime errors.

W3C EBNF

Fortunately, it is straightforward to convert the APEXlang EBNF grammar to W3C EBNF. For the current APEXlang grammar, the conversion can be performed entirely through automated text transformations without manual edits.

Here is a list of the most important replacement actions:

ActionExample FromExample To
Replace multiline comments(* ... *)/* ... */
Remove leading < and trailing > in symbol names<app>app
Use expression and ? to express optionality[ ... ]( ... )?
Use expression and * for repetitions{ ... }( ... )*

The rule app in W3C EBNF looks as follows after applying these changes:

3) app rule in apexlang.w3c.ebnf
app ::= "app" ( required-ws component-id )? ws "(" line-end ( app-body-line )* indent ")" line-end

See Convert.java for the complete conversion program.

Syntax Diagrams on GitHub

You cannot produce the complete syntax diagrams in the online version of the Railroad Diagram Generator because the APEXlang grammar is huge, and you will get a timeout when trying.

So, you need to run the tool locally. I’ve created a GitHub workflow that downloads apexlang.ebnf, converts it to a W3C EBNF, and generates an HTML file containing all syntax diagrams. Finally, the workflow publishes the result:

The advantage of syntax diagrams is that they show all usages of a symbol, allowing you to navigate quickly to the relevant definition.

Outlook

The next step is to build a parser for APEXlang and use this as the basis for linting. This would enable APEXlang source code to be automatically validated, helping both developers and AI agents to produce code that conforms to defined quality standards.

Looking further ahead, we are considering providing full support for APEXlang within the dbLinter tool suite. Currently, dbLinter analyses only SQL and PL/SQL code blocks embedded in APEXlang files. Full APEXlang support is a natural evolution. Stay tuned!

The post Syntax Diagrams for APEXlang appeared first on Philipp Salvisberg's Blog.

]]> https://www.salvis.com/blog/2026/06/19/syntax-diagrams-for-apexlang/feed/ 3