5 Recurring Vulnerabilities in Delphi Applications. And why they might fly under the AppSec radar?

Vulnerabilities in Delphi applications rarely appear on the security radar, but that does not mean they do not exist. Delphi systems can be found in critical operations across banks, insurance companies, healthcare organizations, and industrial companies. Many of these systems have been running in production for more than a decade. They are stable, time-tested, and difficult to replace.

But “stable” does not mean “secure.”

The problem is that most of the AppSec market—including SAST tools, security teams, and technical content—simply does not address Delphi. Furthermore, the best-known platforms—Fortify, Checkmarx, HCL AppScan, and Synopsys Coverity—do not support the language. As a result, Delphi systems remain outside the security radar, not because they are less vulnerable, but because no one is analyzing them.

In this article, we have compiled the most common vulnerabilities found in legacy Delphi applications. These are the areas that every technology or security team should review before an audit, a compliance certification process, or, ideally, before an incident occurs.

Why these vulnerabilities go unnoticed

1. SQL injection through direct query concatenation

This is by far one of the most common vulnerabilities in older Delphi applications. Data access components such as BDE, ADO, or dbExpress were frequently implemented using queries built through string concatenation, without parameters (Params) or prepared statements.This creates opportunities for SQL injection through form fields, especially in systems where input validation has been implemented inconsistently across different screens.How to identify it: search the code for “SQL.Text :=” or “SQL.Add” statements that directly concatenate variables without using ParamByName.

2. Credentials and secrets stored without protection

It is not uncommon to find connection strings, database passwords, or API keys embedded directly in the source code, stored in plaintext .ini/.cfg files, or even saved as properties within .dfm files.This pattern was common in applications developed before modern secrets management practices became widely adopted. As a result, it becomes a critical risk whenever the executable or source code can be accessed—including through binary reverse engineering.How to identify it: scan the project’s source files, .dfm, .ini, and .reg files for suspicious string patterns such as passwords, connection strings, and tokens.

3. Lack of encryption in network communications

Delphi applications that use socket components, such as those provided by the Indy library, for client-server communications sometimes transmit sensitive data without TLS or rely on outdated TLS versions retained for compatibility with legacy clients.This is particularly critical in financial and healthcare systems, where customer data is often transmitted between workstations and internal servers under the mistaken assumption that “an internal network does not require encryption.”How to identify it: review the configuration of TIdTCPClient/TIdTCPServer components and verify whether TIdSSLIOHandlerSocketOpenSSL, or an equivalent component, is being used with up-to-date protocol versions.

4. Business rules and security validation implemented on the client side

In many Delphi desktop applications, authorization rules—such as who can view specific information or approve certain actions—were implemented in the presentation layer, directly within the client executable, rather than being validated by the server or database.

This means that, in theory, modifying the behavior of a screen or intercepting a request may be enough to bypass a business rule that should serve as a security control.

How to identify it: map where the system’s permission and authorization validations are implemented. If they are concentrated on the client side, this should be treated as a warning sign.

5. Outdated third-party components and libraries

Many legacy Delphi systems depend on third-party components, including DLLs, VCL packages, and integration libraries, that have not been updated for years. In some cases, this is because the vendor no longer exists.This creates a supply chain risk: known vulnerabilities in older versions of these dependencies remain exposed, even when the company’s proprietary code is well written.How to identify it: creating an inventory of components, or a Software Bill of Materials (SBOM), is the first step. Without one, it is virtually impossible to determine which dependencies are outdated or compromised.

6. Lack of automated security testing in the development lifecycle

This is not exactly a vulnerability in the code itself, but it is the root cause of nearly all the issues listed above: most teams responsible for maintaining Delphi systems do not have a SAST tool running continuously, simply because the best-known solutions on the market do not support the language.Without recurring static analysis, each of the issues above can only be discovered manually. This usually happens too late—during a one-time penetration test, a compliance audit, or, in the worst-case scenario, after an incident.

What to do with this list

None of these issues is, by itself, a reason to rewrite the entire system from scratch. In fact, that is rarely a realistic option for organizations that depend on a critical Delphi application running in production. The most practical approach is to identify these vulnerabilities through static application security testing (SAST) that supports Delphi, prioritize remediation based on actual risk, and, when the source code is no longer available, rely on binary analysis.This is precisely the gap that traditional AppSec solutions leave unaddressed. That is why Better Now introduced DerScanner to the Brazilian market—one of the few SAST tools available with native support for Delphi, among 43 supported programming languages, including binary analysis for cases in which the source code is no longer available.

If your company maintains critical Delphi systems that have never undergone a structured security assessment, learn more about the solution → Better Now & DerScanner