Skip to content

Application

Thick-Client
Penetration Testing

Desktop application testing: .NET, Java, Electron, and native

Starts at $6,000, fixed scope, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When a desktop application needs testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • You ship a desktop application to customers or run one internally, and no outsider has attacked the client itself.
  • The app stores credentials, tokens, or license keys locally, and you do not know how well they are protected.
  • An enterprise buyer asked for third-party testing of the desktop client before deploying it to their staff.
  • The client runs a local service or auto-updater with high privileges, and a flaw there is a privilege-escalation path.
  • The app is inside your SOC 2 boundary and the auditor expects application-layer evidence beyond the web tier.

Definition

What is thick-client penetration testing?

Thick-client penetration testing, also called desktop application penetration testing, is a manual test of an application that runs on the user’s machine rather than in a browser. It covers the client itself: what it stores on disk, how it loads libraries, the services and inter-process channels it exposes, how it protects its traffic, and the backend API it depends on. The difference from a web test is the local attack surface, because the machine, and any attacker on it, fully controls the client.

We test .NET, Java, Electron, and native C++ or Delphi applications to the OWASP Desktop App Security Top 10, from $6,000 for a standard desktop app. When the source is available, a secure code review can be added; when only the backend needs depth, it can be scoped as an API penetration test instead.

What we look for

Thick-client vulnerabilities we hunt for

A desktop application runs on a machine the user, and any attacker on it, fully controls. We test the client to the OWASP Desktop App Security Top 10, from the secrets on disk to the service running as SYSTEM and the API behind it.

Local storage and secrets

What the client leaves on a disk the attacker owns: credentials, tokens, keys, and sensitive data in the clear.

We test for

  • Secrets in config files, the registry, and local databases
  • Credentials and tokens recoverable from memory
  • Weak or absent encryption of local data
  • Cached, logged, and temporary-file exposure
  • Hardcoded secrets in the shipped binary

Binary and code protection

How much the compiled application gives up under a decompiler, and the logic that assumes nobody is looking.

We test for

  • Decompilation of .NET, Java, and Electron builds
  • Client-side authorization and trust that can be patched out
  • Weak or custom cryptography in the client
  • Obfuscation and anti-tamper effectiveness
  • License and feature checks enforced only on the client

DLL hijacking and privilege escalation

The local attack surface a web app never has: the files, paths, and services that turn a normal user into an administrator.

We test for

  • DLL search-order hijacking and unsafe library loading
  • Insecure file and install-path permissions
  • Local services running as SYSTEM and their exposure
  • Unquoted service paths and writable executables
  • Privilege escalation from a standard user to admin

IPC and inter-process surfaces

The named pipes, COM objects, and local sockets the client talks to, where a low-privileged process can reach a high-privileged one.

We test for

  • Named pipe and COM interface authorization
  • Local socket and inter-process message handling
  • Auto-updater integrity and signature validation
  • Citrix and RDS published-application breakout
  • Shared-memory and helper-process trust

Traffic and transport

What the client sends over the wire, and whether it can be intercepted, replayed, or tampered with.

We test for

  • Traffic interception and TLS-pinning bypass
  • Custom and binary protocol analysis
  • Replay and tampering of client-server messages
  • Cleartext and downgraded connections
  • Certificate validation on the client

Backend API and server

The service the client depends on, where a tampered client reaches the furthest and most of the data actually lives.

We test for

  • Authorization on every endpoint the client calls
  • Broken object-level authorization across accounts
  • Server-side trust of client-supplied data
  • Token handling between client and API
  • Endpoints reachable once client checks are removed

Compare

Thick-client vs web vs mobile testing

Three client types, three attack surfaces. A thick-client test is closest to a mobile test: a client binary plus its API, on a device the attacker controls.

Web application

Where it runs
In the browser
Local attack surface
Minimal
Signature finding
Injection, broken access control
Backend tested
Yes
Starting price
From $5,200

Thick client (desktop)

Where it runs
On the user’s computer, as an installed app
Local attack surface
Large: storage, DLLs, services, privilege escalation
Signature finding
Secrets on disk, DLL hijack, service privesc
Backend tested
Yes, the API the client calls
Starting price
From $6,000

Mobile application

Where it runs
On the phone, as an installed app
Local attack surface
Large: storage, keychain, runtime
Signature finding
Insecure storage, pinning bypass
Backend tested
Yes, the API the app calls
Starting price
From $6,000

A desktop app that is really a web app in a wrapper (an Electron shell over a hosted site) is tested as both: the web logic and the desktop-specific surface the wrapper adds. Our guide to web application security testing covers the browser side.

Pricing

How thick-client testing is priced

Desktop scopes are sized by the client, its platforms, and its local surface, and fixed in writing before work begins.

Standard desktop app

One application on one OS, in .NET, Java, or Electron, up to two roles, a standard HTTPS backend, and no obfuscation: $6,000.

Custom protocol or privesc

A custom or binary protocol, IPC surfaces, a local service running as SYSTEM with privilege-escalation testing, an auto-updater, several roles, two operating systems, or Citrix and RDS breakout: $9,200.

Native or hardened

Native C++ or Delphi needing disassembly, obfuscation or anti-tamper, protocol fuzzing, several platforms, or a large backend API tested in depth, quoted from the scope.

If only the backend needs deep testing, it can be scoped as an API test from $4,000 so the days are not counted twice.

Methodology

Thick-client penetration testing methodology

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your Thick-Client penetration testing runs through.

  1. 01

    Scope & threat model

    The application, its OS, its roles, its backend, and the abuse cases that matter, with the fixed price in writing.

  2. 02

    Static analysis

    The binary decompiled and reviewed for secrets, client-side trust, weak crypto, and the logic an attacker would target.

  3. 03

    Local attack surface

    Storage, DLL loading, file permissions, IPC, and services tested for the paths that escalate privilege on the host.

  4. 04

    Traffic & backend

    Interception and protocol analysis, then the API the client calls, tested as a tampered client would use it.

  5. 05

    Report & retest

    Findings by severity with reproduction steps, hardening guidance, and a free retest once your fixes ship.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope & kickoff

    Targets, roles, and rules of engagement defined in writing, with a fixed scope and timeline.

  2. 02

    Testing goes live

    Findings post to your live platform dashboard the moment our testers confirm them.

  3. 03

    Track remediation

    Follow every finding from open to fixed, with severity, evidence, and status in one place.

  4. 04

    Report & retest

    Executive and technical reports land, then request a free retest in one click.

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study

FAQ

Frequently asked questions

What teams most often ask before scoping Thick-Client penetration testing.

Still have questions? 
01What is thick-client or desktop application penetration testing?

It is a manual test of an application that runs on the user’s machine rather than in a browser. Alongside the backend API, it covers the local attack surface a web test never sees: secrets in config files, the registry, local databases, and memory; DLL search-order hijacking and insecure file permissions; local services that can be abused to escalate privilege; inter-process channels such as named pipes and COM; and the traffic between the client and its server. We test it to the OWASP Desktop App Security Top 10.

02Which languages and frameworks do you test?

The common desktop stacks: .NET (WPF, WinForms), Java, and Electron, plus native C++ and Delphi. .NET, Java, and Electron builds decompile cleanly, which makes the client-side logic and any shipped secrets straightforward to review; native code needing disassembly, obfuscation, or anti-tamper is scoped at the larger tier.

03How is it different from a web application test?

A web application test focuses on the browser-facing application and its server. A thick-client test adds everything the desktop brings with it: what the client writes to a disk the attacker controls, how it loads libraries, the services and IPC surfaces it exposes, whether a normal user can escalate to administrator through it, and how well it protects its traffic. The backend API is tested in both. It is closest to a mobile test, which is also a client binary plus its API.

04Do you need the source code?

No. We test the shipped application by decompiling and instrumenting it, which is what a real attacker does. When the source is available, adding a secure code review finds the issues that are hard to reach from the binary alone and explains why the ones we do find recur; that is scoped at the source-code review prices. Either way we agree the inputs during scoping.

05Do you test the backend API too?

Yes. A desktop client is only as secure as the service behind it, so the API the client calls is part of the engagement, tested as a tampered client would use it, including the authorization on every endpoint. If the backend is large and needs depth on its own, it can be scoped as a separate API penetration test so the effort is not counted twice.

06Can you test Citrix or RDS published applications?

Yes, in the $9,200 tier. A published application is a common breakout target: the goal is to escape the constrained session and reach the underlying server or its file system. We test the breakout paths alongside the client itself.

07How much does thick-client penetration testing cost?

A standard desktop app, one OS, up to two roles, a standard HTTPS backend, and no obfuscation, is $6,000, fixed before work begins, with a free retest. A custom or binary protocol, IPC and local-service privilege escalation, an auto-updater, several roles, or two operating systems is $9,200. Native C++ or Delphi with disassembly, obfuscation, or protocol fuzzing is quoted from the scope. Our thick-client testing cost page explains what moves the price.

08What standard do you test against?

The OWASP Desktop App Security Top 10, which covers injection, broken authentication, sensitive data exposure, improper cryptography, improper authorization, security misconfiguration, insecure communication, poor code quality, known-vulnerable components, and insufficient logging. Findings are rated with CVSS and mapped to the weakness class, with a secure-design recommendation for each.

Ready to test your defenses?

Talk to our team about scoping Thick-Client penetration testing.

Prefer the full scoping questionnaire? 

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.