PowerBuilder applications are database-intensive and process large volumes of business-critical data, making them high-value targets for attackers. Security vulnerabilities in PowerBuilder code often go undetected for years, quietly accumulated through maintenance cycles, third-party integrations, and outdated practices inherited from earlier development eras.
Visual Expert addresses PowerBuilder code security at multiple levels through static application security testing (SAST):
- Detects security vulnerabilities in PowerBuilder code - hardcoded credentials, injection flaws, insecure cryptography, and more.
- Reduces the attack surface by identifying dead, duplicate, and obsolete code that increases exposure unnecessarily.
- Flags bad practices that degrade performance or make denial-of-service (DoS) attacks more feasible.
- Proposes concrete fixes for each issue identified.
- Covers both the PowerBuilder client and any connected Oracle or SQL Server database code in a single analysis.
Teams planning a structured remediation effort can find a full sequencing approach - covering code, deployment, access control, and audit readiness in the Guide to Securing PowerBuilder Applications.
PowerBuilder security vulnerability categories
Visual Expert's 300+ inspection rules cover five distinct categories of PowerBuilder security vulnerabilities.
The sections below detail the most critical rules in each category.
- Hardcoded credentials and sensitive data
- Encryption and cryptography weaknesses
- Injection and input validation flaws
- Deprecated and legacy components
- Access control and code exposure
Hardcoded credentials and sensitive data
Hardcoded secrets are among the most common and dangerous PowerBuilder security vulnerabilities. They persist silently in compiled executables, where decompilation tools can expose them. Any breach of the binary - physical or remote, becomes a credential leak.
- User IDs and Passwords should not be Hardcoded
Hardcoding sensitive information, such as usernames or passwords, IP addresses, and encryption keys can expose them to hackers. Anyone accessing the executable files may decompile them and find the sensitive information. Leaking data protected by official regulations like GDPR, SOX, HIPPA can generate severe legal consequences.
Visual Expert will search for hard coded user IDs and passwords, to let you remove these security breaches. - Encryption keys should not be hardcoded
The PowerBuilder code rule "Encryption keys should not be hardcoded" states that any encryption keys used in PowerBuilder code should not be stored as plain text in the code. Instead, the encryption keys should be stored in a secure location outside of the code and referenced from there. This ensures that the encryption keys are kept secure and not exposed to potential attackers who may be able to access the code. It also makes it easier to manage the keys in the event that they need to be changed or updated. - IP addresses should not be Hardcoded
Hardcoding sensitive information like IP addresses, encryption keys or pass codes may expose them to hackers.If someone can access your runtime files, they may decompile them and expose this info. Leaking information protected by official regulations like GDPR, SOX, HIPPA can lead to major legal consequences.
Visual Expert will search for any hard coded IP Address for you to remove this security breach. - Never use Console logging in production
Console logging is a method to discreetly find out what the code is doing and warn if a problem has occurred. It should be disabled in production, as it could expose sensitive data and reveal information about the inner workings of your application. Visual Expert will track such issues in your Powerbuilder code, to help you disabled them before going live.
Encryption and cryptography weaknesses
Weak or misconfigured encryption is one of the most technically subtle categories of PowerBuilder security vulnerabilities. An application can appear to use encryption while remaining practically unprotected if algorithms, modes, or key lengths are incorrect.
- Always use AES encryption algorithm in a secure mode
AES offers several modes (ECB, CBC, CFB…), some of them being faster or safer.
If you are using AES in your PowerBuilder code, your calls should use the most secure modes.
Visual Expert will scan your application, find less secure calls and highlight them in your code. - Encryption algorithms must be used with the appropriate secure mode and padding scheme
When securing your code with encryption algorithms, operation modes and padding schemes should be used correctly. Depending on the encryption algorithm used, Visual Expert will determine the proper padding and mode values, and verify that they are correctly used in your PowerBuilder code. - Encryption keys should be long enough
To make cryptographic keys robust against brute force attacks, they must have a sufficient key size. Visual Expert will tell you if non-robust keys are used in your PowerBuilder code. - DES (Data Encryption Standard) or 3DES should not be used
The Data Encryption Standard (DES) is a symmetric key algorithm for encrypting digital data.
Its short key length of 56 bits makes it insecure. It should not be used anymore.
Visual Expert will find all DES calls in your PowerBuilder code, so you can remove them. - Cryptographic Hash Functions should not use SHA-1 or Message-Digest Algorithms
The SHA-1 and Message-Digest algorithms: MD2, MD4, MD5 and MD6 algorithms are no longer considered secure. Visual Expert will check if such algorithms are used in your PowerBuilder code and locate the corresponding calls, to help you update them with more secure ones.
Injection and input validation flaws
PowerBuilder applications are, by nature, database-intensive - making SQL injection one of the most consequential categories of PowerBuilder security vulnerabilities. Unvalidated user input that reaches database queries or system commands can allow attackers to read, modify, or destroy data, or execute unauthorized operations on the underlying system.
- Database queries should not be vulnerable to injection attacks
Code Injection is an attack injecting malicious code that will be interpreted/executed by the application. In particular, SQL code injection allows performing illegal operations in your database (access to sensitive data, server takeover or shutdown…).
By nature, PowerBuilder applications are database-intensive and mission critical.
They handle large volumes of important data, which make them premium targets for hackers.
For instance, Visual Expert will search for string concatenations, used for building SQLs, and are not properly validated or escaped. They may create major loopholes for the SQL injection. Identifying and refactoring such queries will strengthen your database protection. Learn more: How to Protect PowerBuilder Apps against Code Injection Attacks. - User input should not allow path injection or path transversal attacks
Data entered by users such as URL parameters or cookies should be considered suspicious. If your code dynamically generates a file system path from this data, a hacker could inject specific values such as '../' and change the originally intended path.
These attacks are often called "path traversal" or "directory traversal". They allow the attacker to access forbidden directories to read, modify or delete sensitive data or execute operating system commands.
Visual Expert will identify the code introducing such vulnerabilities to let you sanitize it. A possible defense strategy consists in defining a whitelist of authorized paths or characters. - OS commands should not allow injection attacks
If your code executes operating system commands based on user input, it must check the name of each command. Otherwise, a hacker could inject his own commands to perform illegal operations and compromise your system.
Visual Expert will detect these flaws in your PowerBuilder code, so you can fix them. For example, you can define a whitelist of safe commands and sanitize shell meta-characters. - Regular expressions should not allow Denial of Service attacks
It is highly unrecommended to generate regular expressions from user data, because it can lead to Regular expression denial of service (ReDoS).This type of attack exploits the possibility to drastically slow down the evaluation of regular expressions by maliciously using specific characters. An attacker can induce this situation when a program uses a regular expression and blocks it for a very long time (hence the denial of service).
Visual Expert pin-points such calls in your PowerBuilder code, allowing you to remove them or sanitize the input by removing/annihilating regex meta-characters. - Generic exceptions should not be ignored
In terms of exception handling, CATCH blocks should always have a proper catching mechanism. Visual Expert identifies empty catch blocks to secure your code with a meaningful Exception handling.
Deprecated and legacy components
Many PowerBuilder applications still contain components that were standard practice in earlier versions but have since been deprecated or found to carry significant security risks. These are a common source of PowerBuilder security vulnerabilities in legacy codebases, particularly because they are difficult to identify without automated scanning.
- SOAP and INET objects should not be used
SOAP and INET PowerBuilder objects do not support use of TLS 1.2 and that makes it vulnerable to attacks. - The OLE web browser should not be used anymore (not secure)
The PowerBuilder code rule states that the OLE web browser should no longer be used, as it is not secure. This is because the OLE web browser is an outdated technology that is no longer supported or updated, and thus is vulnerable to security breaches. It is recommended that developers use more secure alternatives such as HTML or JavaScript. - EAServer - no longer supported - should not be used
EAServer is no longer supported since PowerBuilder 2017. The SSLServiceProvider object provides SSL/TLS services in older PowerBuilder versions. It may not support modern security protocols, making it unsuitable for contemporary secure communications. The CORBACurrent object is part of the CORBA standard for distributed objects. CORBA is outdated and not widely used in modern application architectures. The CORBAObject represents remote objects in a CORBA system. Its use is discouraged due to performance issues and obsolescence. The TransactionServer object handles transaction management in distributed applications. Modern frameworks provide more robust and scalable solutions. - Never use CoSetProxyBlanket or CoInitializeSecurity
Calls to subroutines CoSetProxyBlanket, CoInitializeSecurity and CoInitializeSecurityAlias can generate security breaches. Visual Expert will find such calls in PowerBuilder code to help remove them.
Access control and code exposure
These rules address how code structure itself can create security exposure through overly permissive field accessibility that allows unintended data modification from outside a class.
- Fields should not have public accessibility
This rule states that fields in PowerBuilder code should not be made publicly accessible. This means that they should not be declared as public variables, and should instead be declared as private or protected variables. This is important because making fields publicly accessible could open up the code to potential security risks, as it would allow external code to access and modify the fields without any restrictions. It is also important to ensure that fields are only accessible by code that is within the same class, as this will help to ensure that the code is secure and that it is only modified in the intended way.