Thick Client Penetration Testing for Desktop Apps

Thick client penetration testing is an authorized security assessment of a desktop application that runs part of its logic on the user's machine. It covers the installed files, local data, process memory and libraries, the traffic between client and server, and the backend services the client trusts. The aim is to show which weaknesses a real attacker could use, from secrets stored on disk to a server that accepts whatever the client sends. A useful test also explains the business impact of each finding, gives developers fixes they can apply, and retests those fixes before the report is closed.

What Is a Thick Client Application?

A thick client, also called a fat or rich client, is software installed on an endpoint that does meaningful processing locally instead of only rendering pages from a server. It usually stores some data on the device, enforces part of the business logic in the client and talks to one or more backend services.

Common examples include:

• trading and banking terminals used by front-office staff
• ERP, point-of-sale and warehouse clients
• clinical workstation software that reads and writes patient records
• engineering, design and other heavy desktop tools
• administrative consoles for servers, databases or security products
• chat, collaboration and productivity apps built with Electron

The architecture matters because it decides where the attack surface sits.

How Thick Client Testing Differs From Web and Mobile Testing

A web application test assumes the attacker controls the browser and the HTTP traffic. A thick client test adds everything that lives on the endpoint: binaries, configuration files, the registry, local services, memory and the way the operating system loads code. A mobile test covers similar ground, but on platforms with stronger sandboxing and app-store controls than a typical Windows or macOS desktop.

If your desktop app is a shell around a web front end, you need both views. For the backend half, see our API penetration testing guide. For the mobile counterpart, see mobile application penetration testing.

The Four Trust Boundaries Every Desktop App Test Should Cross

The most useful way to plan a thick client test is to follow the places where trust changes hands. A finding almost always sits on one of these four boundaries.

1. Endpoint and installation. Everything written to disk at install or update time: program folders, configuration files, logs, caches, registry keys, scheduled tasks and services. The question is who can read or change them.
2. Process and memory. What the running application holds and loads: decrypted secrets in memory, libraries pulled from the search path, plug-ins, scripting engines and debug features left enabled in release builds.
3. Network channel. Every connection the client opens: HTTPS, raw sockets, database drivers, message queues and update servers. The question is whether traffic is protected, whether certificates are checked and whether an intercepted request can be replayed or changed.
4. Backend services. The APIs and databases that act on the client's requests. The question is whether the server enforces authentication and authorization itself, or simply trusts what the client says.

The fourth boundary produces many of the highest-impact findings. MITRE's weakness catalog lists this pattern as CWE-602: Client-Side Enforcement of Server-Side Security: a server that relies on the client to apply a protection meant to protect the server. Any control that exists only inside the desktop app can be removed by someone who controls the endpoint.

What a Thick Client Penetration Test Covers

Use this checklist to agree scope with a provider and to read a report critically.

Common Thick Client Vulnerabilities

The OWASP Desktop App Security Top 10 (2021) is a community list that maps the most common desktop risks. It is still an incubator project rather than a flagship standard, so treat it as a checklist, not a compliance requirement. Its ten categories are:

Three issues show up often enough to describe in more detail.

Hard-coded credentials. Developers sometimes embed database passwords, service-account keys or API tokens in the binary or a configuration file so the client can connect. Anyone with the installer can usually recover them. MITRE tracks this as CWE-798: Use of Hard-coded Credentials. The fix is to remove shared secrets from the client and give each user or device its own revocable credential, with the server enforcing what that credential can do.

Insecure library loading. Microsoft explains that when an application loads a DLL without a fully qualified path, Windows searches a defined list of directories, and an attacker who controls one of those directories can plant a malicious copy. Microsoft calls this a DLL preloading or binary planting attack and notes it can lead to local privilege elevation when the application runs with administrator rights (Microsoft Learn: Dynamic-Link Library Security). MITRE ATT&CK tracks the attacker behavior as T1574.001, Hijack Execution Flow: DLL, and the underlying weakness is CWE-427: Uncontrolled Search Path Element.

Weak local protection of secrets. Storing tokens in plain files or the registry exposes them to anyone who can read that location. On Windows, the Data Protection API (DPAPI) lets an application encrypt data with keys tied to the current user or the machine, which avoids generating and storing its own key (Microsoft Learn: How to use data protection). With the current-user scope, DPAPI protects data at rest against other users of the machine; with the machine scope, any account on that computer can decrypt it. Neither scope protects against malware already running as the same user, so testers check which scope the app uses and what an attacker on the same account could reach.

Framework-Specific Checks

The technology stack changes which checks matter most.

For Electron, the project's own security checklist is the best baseline. It recommends enabling context isolation and process sandboxing, never enabling Node.js integration for remote content, defining a restrictive Content Security Policy, validating the sender of every IPC message and keeping Electron current. Context isolation has been on by default since Electron 12, Node.js integration off by default since Electron 5 and renderer sandboxing on by default since Electron 20, so many real-world findings come from apps that turned those protections off or still run old versions. Our Electron application penetration testing guide walks through these checks in depth.

How a Thick Client Penetration Test Runs

Most providers follow a general testing framework such as NIST SP 800-115 and adapt it to the desktop stack. A typical engagement runs in eight stages.

1. Authorization and rules of engagement. Written approval names the application version, test accounts, environments, backend hosts in scope, testing windows and any production limits. Reverse engineering of third-party components is agreed in advance.
2. Architecture review. The team maps tiers, protocols, data stores, update channels, privileged components and integrations, usually with developer input.
3. Lab setup. The client is installed on dedicated test machines that mirror real deployments, including the operating system versions and permission levels real users have.
4. Static analysis. Testers inspect binaries, configuration and bundled libraries for secrets, hidden functions, outdated components and client-side security decisions.
5. Local dynamic analysis. While the app runs, testers watch file, registry, process and library activity, inspect memory for sensitive data, and check local interfaces and privilege boundaries.
6. Traffic analysis. Testers route or capture client traffic, check encryption and certificate validation, and try changing requests to see what the server accepts.
7. Backend and business-logic testing. Testers confirm whether the server enforces authentication, authorization, input validation and workflow rules on its own.
8. Reporting and retest. Each validated finding gets evidence, severity, business impact and a fix. After remediation, the same scenarios are retested and the report records what was closed.

Production safety matters more for desktop apps than many teams expect. A client may write to shared databases or trigger real transactions. Agree in writing which actions are allowed against live backends and use test accounts with synthetic data wherever possible.

Tools Testers Use

Tools support the work; they do not replace it. Most of the value comes from understanding how the client and server trust each other.

Microsoft itself suggests using Process Monitor to spot suspicious DLL load attempts, such as a load from the current directory. Automated scanners help with dependency and configuration checks, but they cannot judge whether a hidden admin button is enforced on the server. For more on that trade-off, see manual vs automated penetration testing.

Illustrative Finding: An Admin Check That Lived Only in the Client

The following example is illustrative and simplified; it does not describe a specific client.

A finance team uses a .NET desktop client that talks to a REST API. The client hides the "approve payment" button unless the signed-in user has the approver role. During static analysis, the tester sees that the role check happens only in the client. In the lab, using two test accounts, the tester captures the approval request made by an approver and replays it with a standard user's session. The server accepts it.

• Root cause: the server trusted the client to enforce the role (CWE-602).
• Impact: any authenticated user could approve payments, bypassing segregation of duties.
• Fix: enforce role and object-level checks in the API for every approval request, and log the approving identity on the server.
• Retest: repeat the same request with the standard user's session and confirm a 403-style rejection plus a server-side audit entry.

Nothing in this finding required breaking encryption or exploiting memory. It required looking at the client the way an attacker who owns the endpoint would.

How to Scope a Desktop Application Pentest

Good scoping keeps cost predictable and results useful. Before you request proposals, collect answers to these questions:

• Which application versions, editions and operating systems are in scope?
• Is the client standalone, two-tier, three-tier or a web-based shell such as Electron?
• Which backend APIs, databases and update servers does it use, and which of them are in scope?
• How many user roles exist, and can you provide test accounts for each?
• Will you share source code, symbols or architecture documents (white-box), or should testers work from the installer only (black-box)?
• Does the app run privileged services, drivers or helper tools?
• Which environment can be tested safely, and are there production limits?
• Which compliance or customer requirements does the report need to support?

Our penetration testing scope guide explains how to turn these answers into rules of engagement and a statement of work. If you are deciding how much internal knowledge to share, see black box vs white box testing.

What the Report Should Include

A thick client report should let a developer reproduce each issue and a manager decide what to fix first. Look for:

• the exact application build, operating systems, accounts and environments tested
• a clear description of the architecture and trust boundaries examined
• for each finding: affected component, evidence, reproduction steps, severity with rationale, business impact and a specific fix
• separation between findings on the client and findings on the backend, since different teams usually own them
• limitations, such as components out of scope or tests not run against production
• retest results showing which findings are closed, partly fixed or still open

For a full breakdown of report sections, see our penetration testing report guide.

Frequently Asked Questions

What does thick client mean?

A thick client is installed software that does real processing on the user's machine, stores some data locally and talks to backend services. It contrasts with a thin client, such as a browser-based app, where almost all logic runs on the server.

Which security issues are common in thick clients?

Common issues include hard-coded credentials, sensitive data stored without adequate protection, insecure library loading, weak or disabled transport security, outdated bundled components and authorization checks that exist only in the client. The OWASP Desktop App Security Top 10 (2021) groups these into ten categories.

How is thick client testing different from web application testing?

A web test focuses on the browser, HTTP traffic and the server. A thick client test adds the endpoint itself: installed files, the registry, memory, local services, library loading and non-HTTP protocols. It also checks whether the backend trusts decisions made inside the client.

Do testers need the source code?

No, but it helps. Testers can decompile many .NET and Java clients and analyze native binaries without source. Sharing source or symbols in a white-box test usually finds more issues in the same time, especially in complex business logic.

Can a thick client test run against production?

Sometimes, with strict limits. Desktop clients often write to shared databases or trigger real transactions, so most testing should use a staging backend and test accounts. Any production testing needs written approval, defined windows and stop conditions.

Are Electron apps thick clients?

Yes, in practice. Electron apps install on the desktop and can reach operating-system features, so they carry both web risks and desktop risks. They need checks on renderer settings, inter-process communication and navigation in addition to standard thick client tests.

Next Step: Test Your Desktop Application Safely

Desktop applications move part of your security model onto machines you do not control, so the backend has to enforce every decision that matters. A focused thick client penetration test shows where that assumption breaks and gives your developers specific fixes to verify.

If you are planning a desktop application assessment, contact DeepStrike to discuss scope, access and retesting, or review our penetration testing services.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• OWASP Desktop App Security Top 10
• Microsoft Learn: Dynamic-Link Library Security
• Microsoft Learn: Dynamic-link library search order
• Microsoft Learn: How to use data protection (DPAPI)
• MITRE ATT&CK T1574.001: Hijack Execution Flow: DLL
• MITRE CWE-602: Client-Side Enforcement of Server-Side Security
• MITRE CWE-798: Use of Hard-coded Credentials
• MITRE CWE-427: Uncontrolled Search Path Element
• Electron: Security checklist
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment