OWASP Desktop App Security Top 10
OWASP Desktop App Security Top 10 - An OWASP incubator project
Issues such as SQL, LDAP, XML, OS command injection, etc. occur when untrusted input is passed to the interpreter as a part of a query/command. An attacker can trick interpreters to execute arbitrary commands to perform unwanted operations or gather unauthorized data.
It includes issues such as insecure authentication implementation, authentication bypass, improper session, etc. An attacker can exploit insecure implementation in order to compromise user sessions, passwords and keys or to assume the identity of the user of the application.
Unintentional exposure of sensitive information such as PII, financial information, healthcare information or application keys and secrets. This may include data in memory post app logout, logs with sensitive info., hardcoded secrets in files (dll, binaries, configuration files), etc. An attacker can use this information to carry out identity frauds.
Issues such as usage of weak cryptographic algorithms, weak keys or secrets, custom cryptographic functions and insecure key management. An attacker can exploit these flaws to retrieve the sensitive information or to attack the users of the different instances of the same application.
Flaws include misconfigured group policies / registry / firewall rules etc., missing file-content type check for file processing apps, misconfigured named-pipes, misconfigured supporting services used by the application, misconfigured third party services (SQL, AD, etc). An attacker can gain system access by exploiting these flaws.
Insecure communication issues include usage of weak TLS or DTLS cipher-suites/protocols, plaintext database connections, usage of plaintext communication protocols such as HTTP, COAP, MQTT,etc. These flaws allow an attacker to perform MiTM attacks in order to sniff and manipulate the data of an active connection.
Issues related to absence of secure coding practices such as missing code-signing and verification of file integrity, missing code obfuscation, lack of binary protection, memory leaks, buffer overflows, etc. An attacker can reverse engineer the application in order to obtain information about the application logic, business specific proprietary logic or can exploit application processing using binary attacks like dll-preloading or injections, overflow/underflows and memory corruption.
It includes usage of outdated softwares, obsolete components/services of OS/Third-party vendors. An attacker can exploit the vulnerable components/services to retrieve information or to compromise the target system either locally or remotely depending upon the exploit.
Includes missing or insecure implementation of logs, improper parameters within audit logs, missing regular monitoring to detect abuse, etc. Centralized Logging and monitoring are used to detect/analyze an incident and to detect an active attack respectively, sometimes attackers try to manipulate this data to prevent alarms with many techniques like timestomping and many others, such issues also have to be focused.
Issues such as SQL, LDAP, XML, OS command injection, etc. occur when untrusted input is passed to the interpreter as a part of a query/command. In general Desktop apps widely use 2 or 3 Tier architecture, so depending upon the sink, it would be impacted.
Desktop apps may use XML to save configuration/data hence all kinds of XML injections would apply. They also quite often use databases like MySQL/MSSQL/etc., so they are equally vulnerable to SQL injections. Many Desktop apps provide functionality which may use system calls in background, leaving wide exposure to OS command injection. Sometimes desktop apps are made to render HTML content (e.g. email clients), so HTML injections are also possible. Sometimes the sink can be scripting templates, XPath, LDAP, etc., so those would be equally impacted. So just like Web applications, Desktop apps are quite vulnerable to all common Injection attacks. If Desktop apps consume web API/microservices, so all relevant attacks of the web would also be applicable here.
Since desktop apps may be used under multiple situations, it might need an user to login or sometimes a guest user like a public kiosk.
Based upon sink, either it may end up into a successful privileged command execution, unauthorized data access, entire system compromise or denial of service.
Desktop apps either have their own application layer authentication or they inherit Authentication of Windows / *nix OS or sometimes they intake authentication from external things like RFID Authentication cards / USB Keys etc. or sometimes they explicitly do not ask authentication just relying upon platform security.
Issues such as insecure authentication implementation, authentication bypass, improper session, etc. falls into this vulnerability category. An attacker can exploit insecure implementation in order to compromise user sessions, credentials and keys or to assume the identity of the user of the application.
Taking example of desktop apps which are deployed to be used by public users e.g. ticketing kiosk / dispensers / tourist information kiosk etc., such systems might miss out implementing authentication properly or some emergency devices like in medical systems, where authentication is considered a little relaxed, if it comes at risk to patient life while performing a treatment or power plants, production line, law enforcement system apps etc..
Since a desktop may be used under multiple situations, it might need an attacker to login or sometimes a guest user like a public kiosk with physical access.
Unintentional exposure of sensitive information such as PII, application keys and secrets, financial / personal / healthcare information, etc would be classified as sensitive data exposure. An attacker can use this information to carry out frauds like data, identity, financial theft, etc.
Many Desktop apps tend to save sensitive information like encryption keys/connection string etc. in hardcoded form inside app binaries (executables, dll, config files, etc.) or sometimes within comments and then forget to remove them.
It may also happen that desktop apps process any form of sensitive information like PII/Financial records/documents etc., but they do not have data encryption in place, this may lead unauthorized person to access such information in cleartext. Ideally drive level encryption and application layer encryption for data at rest is required.
In case if the system which runs the desktop app is poorly configured, it may allow dumping memory of a process. In case if post app logout/session expiry memory dump contains sensitive information, it would cause loss of data confidentiality violation. Depending upon language/platform garbage collector recycles stale memory, however upon explicit logout or after use sensitive data should be freed.
Since a desktop may be used under multiple situations, it might need an user to login or sometimes a guest user like a public kiosk with physical access.
Suppose hardcoded keys are identified by an attacker, this would leave all possible installations in vulnerable condition, since they would use the same installer which had hardcoded value.
It may end up in a successful unauthorized data access within a system or having such hardcoded keys someone can either decrypt the ciphers or bypass validations across all systems using the key-values.
Improper Cryptography usage, may it be because of Outdated Cryptographic Algorithms or Weak Keys, Inappropriate usage of Cryptographic Functions, reuse of Cryptographic Parameters across all Installations, Improper usage of Cryptography for Integrity check, etc.
Choosing an incorrect form of Cryptographic Function may also cause problems, like using encryption instead of hashing (e.g. passwords storage, de-identification purpose, etc.) or improper management of key storage will cause serious risks. Many times custom made cryptographic functions are used, even when accepted industrial standards are available, which may open threats.
If libraries with support for old/obsolete cryptographic functions are used, choosing weak keys, sometimes an attacker can downgrade and exploit to perform cryptanalysis, etc. All such use cases would allow an attacker to brute force or use common techniques for cryptanalysis.
Primarily it may be a violation of data confidentiality or integrity, since via exploitation an attacker can retrieve sensitive information or can tamper with data.
Authorization flaws include weak file/folder permission per user role, missing principle of least privilege approach, improper user roles, unauthorized registry or environment variables access, etc. Below are some most common vulnerabilities:
Having limited access to the system/app, an attacker can try exploiting the mentioned mis-configuration to gain privileged access. It might be possible to exploit this with system local access or remotely as well based on a few limited scenarios.
Improper authorization vulnerabilities will enable the attacker to escalate the privilege on the target system/app. After escalating the privilege an attacker can attack systems on the network, other users on the compromised system. Upon having system full privileged access, one can steal data or tamper with it causing loss of CIA. Exploitation can also be used to bypass various restrictions.
Flaws include misconfigured group policies / registry / firewall rules etc., missing file type/content check for file processing apps, misconfigured named-pipes, misconfigured supporting services used by the application, misconfigured third party services (SQL, AD, etc). An attacker can gain system access by exploiting these flaws. Security configuration issues spans across
Since a desktop may be used under multiple situations, it might need an user to login or sometimes a guest user like a public kiosk with physical access. Exploiting security misconfigurations can be simple sometimes, as it might be enforced only through obscurity. And sometimes it may also happen that the attacker can be a trusted insider.
An attacker can bypass restrictions & hence run arbitrary code by abusing misconfigured features or even escalate privilege on the system running the target application.
When any Application needs to communicate with the remote services such as remote SQL servers, web services, file transfer, sending commands or any other process running on the remote server, but uses plaintext communication protocols to consume services, such vulnerabilities fall under Insecure Communication. Insecure communication issues include usage of plaintext communication protocols such as FTP, TELNET, HTTP, MQTT, WS, etc. or usage of weak TLS/DTLS cipher-suites/protocols, plaintext database connections, using self signed certificates for secure channel communication, etc. These flaws allow an attacker to perform Man-in-The-Middle (MiTM) attacks in order to sniff and manipulate the data of an active connection.
An attacker present within the network can access the communication via MiTM attack. If it is already unencrypted, it becomes easier to sniff confidential information or replay packets. Otherwise in case of weak encryption communication, an attacker can downgrade the connection and thereby sniff the traffic.
An attacker can retrieve user credentials, service credentials, communication strings, user session information by sniffing the communication between the application and remote service. Moreover, an attacker can manipulate or replay an active communication by carrying out a MiTM attack.
Application build without following secure code practices. Issues such as but not limited to:
An attacker needs access to the binary or installer of the target application. Subject to the kind of language used i.e. managed or unmanaged, reverse engineering may yield either assembly level or original source code equivalent. And in absence of code integrity, it may allow an attacker to run arbitrary code.
An attacker can reverse engineer the application and can glean information about the application logic, business proprietary logic, secrets used in the application. Bypass certain restrictions using run time debugging e.g. bypassing license check. It may also allow execution of malware in place of legitimate code or may help in privilege escalation.
Either any component/service offered by the underlying OS or an external 3rd party component which had a publicly known vulnerability (with/without exploit available), will impose very high risk on the products/assets. As part of the product life cycle any such affected component would be complemented with a security patch or newer version of that component. Some of them are automated, where the end-user doesn’t have to bother about it, however sometimes manually patching is required due to various reasons. Third party components are the reusable software components generally used to save time and budget, while developing any product/solution. There are two categories of third party components:
Using any of the above kinds of components can introduce new vulnerabilities and attack surfaces. It is necessary for the developers of the application to patch the discovered vulnerability in the open source components and use the latest/patched version of commercial components.
An attacker needs to know the vulnerable component version, which is being used within the product, thereby allowing it to exploit based on the public available details.
It may also happen that there can be transitive dependencies, for instance in your product ‘A’ you may be using 3rd party product/component ‘B’, in turn product ‘B’ uses another 3rd party product/component ‘C’. If a vulnerability within product ‘C’ is disclosed, by default product ‘A’ is vulnerable as it inherits via using component ‘B’.
An attacker can exploit the publicly disclosed vulnerability in the OS offered/third party component in order to take over the system running the application, cause loss of data confidentiality/integrity or even may cause service unavailability depending upon the kind of exploit published.
Logging of the user operations, background tasks, etc are considered as important aspects of any application. As it records all the activities performed within the context of the application. Logging enables the application to resolve runtime functional errors and monitor the activities of the user for auditing purposes.
There are different kinds of log such as
In addition, a monitoring mechanism will use logs and enable the owner of the application to receive alerts like:
Common Logging and Monitoring issues comprise of:
Since a desktop may be used under multiple situations, it might need an user to login or sometimes a guest user like a public kiosk with physical access.
Logging allows us to track the operations performed within the context of the application. It is very useful to detect/analyze any occurrence of the incident. Without a secure & robust logging mechanism, it will be easier for an attacker to manipulate the logs in order to cover tracks of the operation performed. Inappropriate or weak monitoring mechanisms will fail to detect an attack in real time and will not allow the owner of the application to take appropriate action to prevent the attack.
Project Resources
Project Leaders
ization
ized data
improper user roles
etc
ized data access
ized person
ized to configure
access logs
ization failures
input validation failures
Kartik Lalan
Project Leader
Project Information
Incubator Project
Classification
Other
Language
HTML
License
MIT License
Contributors
5
GitHub Stars
8
Downloads
0
Corporate Supporters
OWASP is a nonprofit foundation improving software security through open-source projects, global communities, and education. All resources are free and open to everyone.
Quick Links
Legal & Governance
SlackOWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, OWASP Boston Application Security Conference, and LASCON are trademarks of the OWASP Foundation, Inc.
© 2026, OWASP Foundation Inc. All rights reserved.