Thick client penetration testing
Desktop applications get tested far less often than web ones, and the reason is not that they are safer. It is that fewer firms have the tooling to intercept a custom binary protocol, so the engagement costs more and gets deferred.
A thick client penetration test in Canada costs between $10,000 and $28,000 CAD and runs four to eight tester days. The range is wide because two things change the effort by a factor of two: whether the application talks HTTPS or a custom binary protocol, and whether the server side is in scope. It usually should be, because the majority of exploitable findings in a desktop application are server-side authorisation failures that the client was politely declining to attempt.
$10,000 to $28,000 Canadian thick client engagement, CAD
4 to 8 days Tester days, excluding server-side scope
1 to 2 days Added when the protocol is custom rather than HTTP
What counts as a thick client
An application installed on a workstation that does meaningful processing locally and communicates with a server for data or authorisation. Windows desktop software written in .NET, Java desktop applications, native C and C plus plus binaries, and the older client-server line-of-business systems that run Canadian manufacturing, dispatch, insurance broking and clinic administration. The category is defined by where the logic runs, not by how old the software looks.
One common case is not a thick client at all. If your desktop application is an Electron or similar wrapper displaying your own web application, you have a web application in a window. The findings, the tooling and the price belong to web application security testing, and paying a thick client premium for it is paying for the wrapper.
Where the findings actually are
Thick client reports separate cleanly into two columns, and buyers consistently expect the wrong one to be longer. Client-side findings are numerous, easy to demonstrate and usually cheap to fix. Server-side findings are fewer, harder to reach and are the ones that lose data.
| Finding class | Where it lives | What it usually costs you |
|---|---|---|
| Hardcoded database connection string in the binary or config file | Client | Direct database access from any workstation |
| API keys or service credentials recoverable by decompiling | Client | Whatever those credentials reach |
| Sensitive data cached unencrypted on disk or in memory | Client | Exposure on a lost or shared workstation |
| Writable install directory allowing library hijacking | Client | Local privilege escalation to administrator |
| Unauthenticated local listener or named pipe | Client | One user on the machine driving another user's session |
| Role and permission checks enforced only in the interface | Server | Any user performing any action. The expensive one |
| Object identifiers accepted without an ownership check | Server | One customer or branch reading another's records |
| Server trusting a price, quantity or approval flag sent by the client | Server | Financial loss, and it is rarely detected |
| Injection reachable through a field the client validates first | Server | Database compromise |
The pattern behind the server column is one sentence: the developers treated the client as trusted because they wrote it. Every validation the client performs is a suggestion once a tester is speaking to the server directly. The method of the engagement is to stop using the client and start using the protocol. That is the same reasoning that drives API penetration testing, and if your desktop application talks to a documented HTTP API, the two engagements overlap heavily and should be scoped together rather than bought twice.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Decompilation, and why obfuscation is not a control
.NET and Java both compile to an intermediate form that keeps enough structure to be turned back into readable source with free tooling. Method names, class names, string literals and embedded configuration come back almost intact. Native code is harder and takes longer, but the strings and the constants are still there for anyone with a disassembler.
What obfuscation buys and what it does not
Commercial obfuscators rename symbols, encrypt string tables and add control flow noise. That raises the cost of reverse engineering and is worth deploying. It does not protect a secret. The application has to decrypt anything it uses, and a tester watches it do so. If your defence for a hardcoded credential is that the binary is obfuscated, the finding stands, and the fix is to stop shipping the credential rather than to hide it better.
The protocol question decides the price
If the application speaks HTTPS, a tester puts a proxy in the middle, trusts their own certificate on the test machine, works around any certificate pinning in the client, and from that point the engagement resembles an API test with a strange user interface. That is the cheap version.
If it speaks a custom protocol over raw TCP, or a binary serialisation format, or an older remoting framework, there is no proxy to point at it. Someone has to build a tool that understands the framing before any testing happens, and that is one to two days of work before the first finding. It is also the reason some firms decline these engagements entirely, and the reason you should ask directly whether they have done it before, which is one of the checks on questions to ask a vendor.
A worked quote
| Line | Days | Amount |
|---|---|---|
| Installation, environment setup, protocol identification | 0.5 | $1,000 |
| Binary analysis and decompilation, secrets and configuration review | 1.5 | $3,000 |
| Local privilege and file permission testing | 0.5 | $1,000 |
| Server-side testing through the protocol, two roles | 3.0 | $6,000 |
| Reporting and executive summary | 1.5 | $3,000 |
| Retest within 60 days | 1.0 | $2,000 |
| Total at $2,000 CAD a day | 8.0 | $16,000 |
Add one to two days if the protocol is custom. Subtract two to three days if the server is out of scope, and understand that you are subtracting the part of the report that would have mattered. The full set of ranges by engagement type is on penetration testing cost in Canada, and the cost calculator shows the same arithmetic against your own scope.
What to supply before the engagement starts
Thick client engagements lose more time to setup than any other type, and the lost time comes out of your testing days rather than the firm's margin. Have these ready.
0 of 0 ready ·
The last line saves more money than the rest combined. A tester blocked on an undocumented message format for a day has spent $2,000 CAD of your budget waiting. Writing the scope properly in the first place is covered on how to write a penetration test scope.
Who should not buy this
If your desktop application is a browser wrapper, buy a web application test. If it is a thin front end over a documented REST API and it stores nothing locally, most of your budget belongs in API testing and a separate thick client engagement is duplicating it. If the application is internal-only, runs on twelve machines, and the server it talks to is already covered by an internal network engagement, the marginal finding is small.
Where it earns the money: software you sell to other companies, because your customers will eventually ask you for a report and a report or attestation letter naming the client is the artifact they want. Applications that handle payment, clinical or financial records on the workstation itself. Anything that runs as administrator or installs a service. And any application old enough that nobody currently employed has read all of it, which describes a large share of the client-server software still doing real work in Canada.
Scope a desktop application test
Tell us what the client is written in, what it talks to and who is asking for the test, and we will say what the engagement should cover.
Get matchedCommon questions
Is a thick client test different from a web application test?
The server-side portion is very similar and the client-side portion is not. A web browser is a known quantity that a tester does not have to reverse engineer, whereas a desktop binary has to be decompiled, its storage inspected and its protocol understood before the familiar work can begin. That setup is where the extra days and the price difference come from.
Do we need to give the tester our source code?
You do not have to, because they can decompile most of it anyway, but giving it saves a day and that day gets spent finding things instead. This is the white box argument set out on types of penetration test. For native applications the saving is larger, since disassembly is slower than reading the code you already own.
Our application uses certificate pinning. Can it still be tested?
Yes. Pinning is a control against an attacker on the network, not against someone who owns the machine the software runs on, and a tester with local administrator rights can work around it. Expect a few hours of effort rather than a blocker. Keep the pinning, because it does its actual job well.
Will this satisfy our SOC 2 requirement?
It can, if the desktop application is the system your customers rely on. Auditors look for an independent test of the system described in your scope statement, so what matters is that the tested thing is the thing your report describes. If your product is the desktop client and its server, testing them is the right evidence. The expectations are set out on SOC 2 penetration testing.
How do we handle the licence key for a commercial component?
Supply a test licence issued for the engagement, and tell the firm in writing which third party components are embedded. Testers must not attack a vendor's licensing infrastructure and reputable ones will not, but they do need the software to run. Third party components you did not write are normally excluded from scope, and that exclusion belongs in the rules of engagement.