Your Enterprise Desktop App Has Never Been Security Tested
Your web application pentest is on the calendar. Your API security review happened last quarter. Your mobile app was assessed when it shipped two years ago.
The desktop client your accounting department uses to connect to the financial system has never been tested. Neither has the Java-based ERP client your supply chain team runs on Windows. Or the thick client your HR platform vendor shipped when they could not make the browser interface fast enough.
Thick client applications are everywhere in enterprise environments, and they are almost never security tested with the methods those tests actually require. The methodology is different from web app testing. The tooling is different. The findings are different. Most security teams treat these applications as out of scope by default, and most vendors assume nobody will ever look closely enough to notice.
What a Thick Client Actually Is
A thick client is any application that runs significant logic locally on the endpoint rather than in a browser or on a server. The category includes legacy .NET and Java desktop apps, Electron-based applications (which are essentially Chromium with Node.js bundled inside), native Windows executables, and proprietary vendor clients for ERP systems, financial platforms, and healthcare software.
They share one characteristic that matters for security: they run code you cannot see without effort. A web application sends HTML, CSS, and JavaScript to your browser. A thick client sends a compiled binary or an interpreted runtime. Understanding what it does requires decompilation, traffic interception, and often some runtime analysis.
The Traffic Is Not Always What It Looks Like
The first thing a web app tester does is point a proxy at the browser. Thick clients require more work.
Some thick clients use standard HTTP/HTTPS and will respect a system proxy setting. You configure Burp Suite, route the traffic through it, and you are capturing and modifying requests like a web app test. This works for maybe half of the thick clients in a typical enterprise environment.
The other half use custom protocols, binary serialization formats, direct TCP connections, or SOAP endpoints that predate REST. Some implement SSL pinning or certificate validation that rejects proxying. Some talk directly to database servers using ODBC or proprietary drivers. Each of these requires a different approach to intercept and understand the traffic.
Getting to the point where you can see what a thick client is actually sending is often a third of the work in the assessment.
The Decompilation Problem
The application logic that runs on the endpoint is a finding surface that does not exist in web applications. With a .NET or Java application, you can decompile the binary back to something close to source code. Tools like ILSpy, dnSpy, JD-GUI, and Procyon produce readable code from compiled bytecode. Native Windows binaries require a disassembler and more patience.
What you find in that code is frequently uncomfortable. Hardcoded credentials. Connection strings with database passwords embedded directly in the binary. Encryption keys stored as string literals. API tokens for backend services. Secret values that the developers assumed nobody would ever look for because the application would never be reverse engineered.
This happens because the threat model for most enterprise desktop applications - particularly older ones - assumed that only authorized employees would ever run the client. The security model was: if you can run this application, you are authorized, so the application can trust you completely. That model fails when the application ends up in the hands of a malicious insider, an attacker who compromised an endpoint, or a security researcher with ILSpy.
Local Storage and the Registry
Thick clients store data locally. Configuration files, cached credentials, session tokens, user-specific settings, and sometimes copies of sensitive data retrieved from backend systems. This data lands in predictable locations: the user's AppData folder, the Windows registry, flat files alongside the application installation, and SQLite databases that the application uses as a local cache.
The assessment includes looking at what gets written to disk, whether it is encrypted, and whether the encryption is meaningful. A credential stored in AppData, encrypted with a key derived from the machine's hostname and the username, is not meaningfully encrypted: anyone who can read the file can derive the key. This pattern is common enough to be expected in applications of a certain vintage.
Business Logic That Lives on the Client
Web applications implement business logic on the server. The client submits a request and the server decides whether it is valid. Thick clients frequently implement business logic on the client side, validating inputs locally before submitting them to the backend.
Client-side validation is not a security control. An attacker with a proxy or a runtime hook can bypass the validation and submit values the client would have rejected. A field that the UI limits to four digits because the business rule requires it can often be submitted with arbitrary values if you intercept the request after the validation fires.
This finding pattern is endemic in older thick client applications because it was not obvious to developers at the time that client-side validation had no security value. The server trusted the client because the client was supposed to enforce the rules, and enforcing them again on the server was considered redundant.
Why These Tests Do Not Happen
The short version: they require different skills, a different toolset, and more upfront effort to even get started. A web app tester without thick client experience will find some things and miss others. Vendors know this and count on it. The application passes a generic application security assessment that was scoped for web targets and gets a report that does not reflect what is actually inside the binary.
If you have enterprise desktop applications handling sensitive data, the assessment needs to be scoped explicitly for thick client methodology. That means decompilation review, traffic analysis appropriate to the protocol, local storage examination, and attention to client-side logic. The alternative is having an application that has never been seriously looked at sitting on every endpoint in your finance department.
The most common response when organizations see thick client findings for the first time is that nobody asked about this before. That is usually accurate. The question is whether that is a comfortable answer now that you know what asking would have turned up.