Thick client (desktop app) testing assesses software that runs on the user's machine and talks to a backend - so the attack surface spans the local device, the network, and the server, not just a web UI. Because the attacker fully controls the machine, any client-side control can be bypassed. Testing covers: insecure local storage (credentials/data in files, registry, memory), hardcoded secrets in the binary, weak binary protections (easy reverse engineering/tampering), bypassable client-side controls, insecure comms (missing/unvalidated TLS), and - the biggest - a backend that trusts the client and fails to independently enforce authorisation. Many serious findings are really backend authorisation flaws exposed via the client. A thorough test covers client, channel and server together. Details below - related to mobile testing.
// 01 Why the desktop threat model is different
The defining fact of thick client security: the application runs on hardware the attacker controls. A thin client (a web browser) runs most logic on your server; a thick client runs substantial code, and often stores data and configuration, on the user's device. That device can be fully owned by a determined user - they can read every file, dump the app's memory, decompile the binary, and intercept its traffic. The consequence is stark and drives everything: any security control enforced only on the client can be defeated. A “you're not an admin” check in the desktop UI means nothing if the server doesn't independently verify it. So thick client testing spans the local machine, the communication channel, and the backend - a broader surface than web testing, and one a generic web scanner can't touch.
// 02 The attack surface
Local storage
Credentials, tokens and sensitive data in files, the registry, config or memory - readable on a controlled device.
The binary
Hardcoded secrets, API keys and connection strings; weak protections that make reverse engineering and tampering easy.
Network comms
How the client talks to the backend - missing or improperly validated TLS, exposed or manipulable requests.
The backend
Whether the server independently enforces auth and validation, or trusts the client - usually where impact is highest.
Four layers, one theme: the client can't be trusted, so the assessment checks what the attacker can extract from it, and whether the server holds the line when they manipulate it.
// 03 How it differs from web app testing
Web application testing focuses on the server-side, because that's where a web app lives. Thick client testing keeps that server focus and adds the client. Concretely, the extra work: inspecting local storage for credentials and sensitive data; decompiling the binary to hunt hardcoded secrets and understand logic; assessing binary protections (obfuscation, anti-tamper); manipulating the running application in memory to bypass client-side checks; and intercepting the client-server traffic to test the API directly. But the pivotal insight is shared with mobile testing: the client is just a front door, and the attacker can go around it. So the highest-value question is always “does the backend independently enforce authorisation and validation, or does it trust the client?” A control that only exists in the desktop app is not a control at all.
// 04 The common flaws
Thick client findings are strikingly consistent. Insecure local storage: credentials, tokens or sensitive data sitting in plaintext in files, the registry or memory on a device the attacker reads freely. Hardcoded secrets: API keys, passwords and connection strings baked into the binary, extractable by anyone who decompiles it - sometimes granting direct backend or database access. Missing binary protections: no obfuscation or anti-tamper, making reverse engineering trivial. Bypassable client-side controls: security checks - licensing, role restrictions, validation - enforced only in the client and defeated by memory manipulation or crafted requests. Insecure communication: missing or improperly validated TLS, so traffic can be intercepted (like certificate-pinning failures on mobile). And, most impactful, a trusting backend: the server assumes the client behaves, so an attacker who manipulates the client reaches data or functions they shouldn't. That last one turns a desktop app flaw into a full data breach.
// 05 How the engagement runs
A thick client assessment blends reverse engineering, dynamic analysis and API testing. We inspect what the app stores locally, decompile the binary for secrets and logic, assess binary protections, manipulate the running app to test whether client-side controls can be bypassed, and intercept the client-server channel to test the backend directly - because that's where the attacker ultimately aims. Crucially, we treat the backend as a first-class target: does it enforce authorisation and validation independently of the client? Many serious thick client findings are really backend authorisation flaws exposed by going around the client. The output maps each finding to its real impact and to any compliance obligations, with findings retested to closure, per our methodology.
// 06 Frequently asked questions
What is thick client penetration testing?
The security assessment of a desktop application that runs software on the user's machine and talks to a backend - unlike a thin client (web browser) where most logic runs server-side. Because it executes code locally and often stores data on the device, its attack surface spans the local machine and network, not just a web interface. Testing examines local storage, memory, the binary, communication and security controls, since a determined user fully controls the device.
How is it different from web app testing?
A web app runs almost entirely server-side; a thick client runs substantial logic on the user's machine, which the attacker fully controls, so testing must also cover the client: insecure local storage, hardcoded secrets in the binary, weak binary protections, bypassable client-side controls, and insecure backend communication. Any control enforced only on the client can be defeated, so testing pays close attention to whether the server independently enforces authorisation and validation.
What are the common thick client vulnerabilities?
Sensitive data or credentials stored insecurely locally (files, registry, memory); hardcoded secrets, API keys or connection strings in the binary; missing binary protections; client-side-only controls bypassable by manipulating the app; insecure communication (missing/unvalidated TLS); and a backend that trusts the client and fails to independently enforce authorisation - so a manipulated client reaches data or functions it shouldn't.
Does it include the backend server?
It should - that's often where the highest-impact findings are. A thick client is a client to a backend, and an attacker who controls it can craft requests directly to the server, bypassing client-side checks. Testing must assess whether the backend independently enforces authentication, authorisation and validation. Many serious thick client findings are really backend authorisation flaws exposed by manipulating the client.
// 07 Related reading
- Mobile app security testing checklist — the same “client on hostile hardware” model.
- OWASP API Security Top 10 — the backend the client calls.
- Source code review and our methodology.