Key Findings:
- A web pentest and a desktop pentest answer different questions. The web test assumes a browser sandbox the attacker does not control. On the desktop, that boundary ships inside your binary and runs on the attacker’s hardware.
- The most productive area in an Electron engagement is the inter-process communication boundary, which is the desktop equivalent of a broken authorization check on an API.
- Local credential storage is a desktop-only finding class. A token encrypted with a key stored next to it is obfuscated, not protected.
- The desktop client and its backend API are two scopes, not one. Testing the client does not tell you what a modified client can ask the server for.
A web application penetration test does not cover an Electron or thick-client desktop application, and the gap is larger than most founders expect. A web test assumes a browser sandbox that the attacker does not control and that a browser vendor patches independently of you. In a desktop application that boundary ships inside the artefact you released, frozen at whatever runtime version your last build bundled, running on hardware the attacker owns. Five finding classes exist only on the desktop side: inter-process communication boundary flaws between renderer and privileged main process, contextIsolation and renderer sandbox settings disabled in production builds, credentials and tokens written to local disk, privilege boundaries a low-privilege local account can cross, and an auto-update channel that installs what it is given. The desktop client is one scope, the backend it talks to is another, and most products need both.
Cybersecify is a founder-led penetration testing firm in Bengaluru. Desktop application penetration testing covers Electron builds and thick clients, and it is the scope buyers most often assume is already covered by something else. It usually is not.
Does a web application pentest cover an Electron desktop app?
No. The two tests share vocabulary and almost nothing else.
A web pentest tests what a browser can reach over the network. The browser itself is a security boundary: it is built by someone else, patched by someone else, and the attacker does not get to change its settings. Your web application sits inside that boundary whether you thought about it or not.
A desktop application moves that boundary inside the artefact you shipped. You chose the runtime version. You chose the security settings. You shipped both to a machine the attacker fully controls, where they can read your files, attach a debugger, modify configuration and restart the process as many times as they like.
That relocation creates a whole class of findings a web engagement cannot see:
- Whether the renderer process can invoke privileged operations through the inter-process communication channel
- Whether contextIsolation and the renderer sandbox are actually enabled in the shipped production build
- What tokens, keys and configuration are written to disk, and whether they survive tampering
- Whether DevTools opens in a production build
- Whether the auto-update channel verifies what it installs
- What a low-privilege local account on a shared machine can read out of your application’s data directory
You still need the web or API pentest on your backend. It is evidence about a different attack surface, and both surfaces are real.
What is a desktop application penetration test?
A test of the application binary as it runs on a machine the attacker controls, plus everything that binary trusts. For an Electron or thick-client application it breaks into five parts.
Build and configuration review. The packaged application is inspected for Node integration exposure, contextIsolation and sandbox settings, DevTools accessibility, and whether the renderer loads remote content in production. This is done against the shipped build, not against the repository, because what is in the build is what your customers run.
Inter-process communication boundary testing. Map the channel surface between the renderer and the privileged main process, then test whether the renderer can reach operations it should not.
Local storage and credential handling. How authentication tokens, session state and configuration persist on disk, and whether they survive tampering by a local user.
Privilege boundary assessment. What a low-privilege local account can read, modify or exfiltrate, including host configuration relevant to a user with console or shell access.
Client-side logic review. Validation, state machines and decision logic that run on the device rather than on the server, where a determined user controls the runtime.
What is contextIsolation and why does it matter?
contextIsolation keeps the JavaScript context your preload script runs in separate from the context the loaded page runs in.
With it disabled, code running in the page can reach the objects and functions the preload script exposed, and through them whatever capability sits behind them. That is the setting that converts an ordinary web bug into a local one. A cross-site scripting flaw in a browser steals a session. The same flaw in an Electron renderer without contextIsolation reaches the file system.
Electron’s security documentation makes contextIsolation the default from Electron 12 and enables the renderer sandbox by default from Electron 20. Two things follow, and both are reasons to test rather than to assume:
- A build can turn either off. Usually it was turned off years ago to make one feature work, and nobody revisited it.
- Applications that upgraded across those versions frequently carry old settings forward. The default changed. Your explicit configuration did not.
So the first job of a desktop test is to read the shipped build rather than the documented intent. This is the same reasoning behind why scanner output is not a security assessment: what is configured and what is believed to be configured are different facts.
What is an IPC boundary flaw in an Electron app?
It is the desktop equivalent of a broken authorization check on an API endpoint, and it is the most productive single area in a desktop engagement.
An Electron application splits into a privileged main process that can touch the file system, spawn processes and reach the operating system, and one or more renderer processes that draw the interface. They communicate over inter-process communication channels the developer defines.
An IPC boundary flaw is a channel that performs a privileged operation on request without adequately validating what was asked, who asked, or from which window. The shapes repeat:
- A handler that takes a file path from the renderer and reads or writes it
- A handler that takes a command or argument string and executes it
- A handler that accepts a URL and opens it, or loads it into a window
- A handler that trusts a window identifier the renderer supplied
The test is to enumerate every channel the renderer can reach and then try to reach the privileged side through each one with input the developer did not anticipate. It is the same instinct as testing for broken object level authorization on an API: not “can I call this”, but “what happens when I call it with something that is not mine”.
What is a renderer sandbox escape?
It is what happens when code running inside the renderer process, which is supposed to be confined to rendering, gets execution outside that confinement and onto the host.
In practice it is rarely a single exotic bug. It is a chain:
- Remote or injected content runs in a renderer
- The renderer has more capability than it should, because a security setting was disabled or a preload script exposed too much
- An inter-process communication handler on the privileged side performs an operation on request without validating it
Each step reads as minor in isolation. A settings note, an over-broad preload export, a handler that could validate more. The chain is arbitrary code running on your customer’s machine with your application’s privileges.
Reporting the chain rather than three separate configuration findings is what makes a desktop report actionable, because the chain shows which single change breaks it.
Where does an Electron app store credentials and why is that a finding?
Usually in the application’s user data directory. The finding is about what protects it there.
Patterns we see repeatedly:
- Authentication or refresh tokens in a plaintext JSON file
- Session state in a local database with no encryption
- API keys in a configuration file the user can read
- Secrets committed into the packaged application bundle, extractable by anyone who downloads your installer
The important question is not only whether a value is encrypted. It is what the encryption is bound to. A token encrypted with a key stored beside it in the same directory is obfuscated, not protected. Anyone who can read the token can read the key.
Whether that matters depends on a threat model most desktop teams have not written down: a shared or managed machine, a stolen laptop, or malware running as the same user. In all three, the difference between obfuscation and protection is the whole finding.
Testing this requires the installed application on a real machine with a real user profile. It is structurally impossible in a web engagement.
What is DASVS and why do you use it for desktop apps?
DASVS is the Desktop Application Security Verification Standard published by AFINE. It gives desktop testing what ASVS gives web testing: a structured list of verification requirements, so coverage is a checklist rather than a matter of the individual tester’s habits.
We use it alongside the OWASP Desktop App Security Top 10 as the methodology baseline for desktop and thick-client work. Our desktop findings are mapped to DASVS verification requirements, tagged with CWE identifiers, and scored with CVSS v3.1.
The reason this matters to a buyer rather than only to a tester is comparability. When a vendor says they tested your desktop application and names no standard, you have no way to ask what was covered and no way to compare two quotes against each other. When they name one, you can read it yourself and ask which requirements were in scope. How to evaluate a penetration testing firm covers the rest of that conversation.
Is a desktop app pentest one scope or two?
The desktop client is one scope. The backend it talks to is another.
This trips up buyers because the desktop application feels like the whole product. It is not, and the two halves fail differently:
| Desktop client scope | Backend API scope | |
|---|---|---|
| Question | What can a user with the binary do to the app and their own host? | What can a modified or replaced client ask the server for? |
| Signature findings | IPC boundary flaws, sandbox settings, local credential storage, update channel | Broken object level authorization, tenant isolation, business logic |
| Who is at risk | The user running it, and their machine | Every other customer |
Testing the client tells you what a local attacker gets. Testing the backend tells you whether a client someone rewrote can reach another customer’s data, which is the question that decides how bad a single compromised user becomes.
Most desktop products need both. That is two scopes and 10 business days, which is what our Growth Pentest at INR 1,79,999 covers. A client-only engagement is one scope and 5 business days under the Startup Pentest at INR 74,999.
Does a desktop pentest cover the auto-update channel?
Yes, and it deserves attention out of proportion to how often it comes up, because the update channel is the one component of your product with permission to replace your product.
What gets tested:
- Whether the update is fetched over a channel that authenticates the server
- Whether the downloaded artefact is signature-verified before installation rather than only checksummed
- Whether verification can be skipped by pointing the client at a different endpoint, or by tampering with local configuration
- Whether the code-signing setup on the shipped binaries is intact across every platform you ship
A weakness here is not one compromised user. It is a delivery mechanism for whatever an attacker wants to install, running with whatever privileges your updater holds. It is the finding on a desktop report that a security-conscious enterprise buyer reads first.
Our desktop app is just a wrapper around our web app. Do we still need a separate test?
Usually yes, and the wrapper framing is exactly what makes it risky.
The interface may be identical. The security model is not:
- In a browser, your users run your web content inside a sandbox built and maintained by a browser vendor and patched independently of your release cycle.
- In a wrapper, you have taken responsibility for that sandbox. You shipped a specific runtime version, frozen at whatever your last release bundled.
- And you added capability the browser never had: file system access, native menus, local credential storage, a background process, an auto-updater.
Every one of those is new attack surface that exists only in the desktop build. The wrapper also inherits every web vulnerability in the underlying application, and the impact of each is higher because the sandbox around them is weaker and older.
The desktop test is not a repeat of the web test. It covers the delta the wrapper created, which is precisely the part nobody has looked at.
How long does a desktop application penetration test take?
- Desktop client alone: one scope, 5 business days, Startup Pentest INR 74,999
- Client plus backend API: two scopes, 10 business days, Growth Pentest INR 1,79,999, which also includes SOC 2 and ISO 27001 evidence mapping
- Three scopes: 15 business days. Four scopes: 20 business days
Scopes run sequentially by default. Parallel testing is available on request and is never guaranteed. Both plans include one free retest within one month of the v1.0 report.
What to have ready before the start date:
- An installable build in production configuration for each operating system in scope. Not a development build, because development builds have different security settings and testing one tells you nothing about what shipped.
- Test accounts, including at least two at different privilege levels if your product has roles.
- A named engineer we can ask when something the application does looks deliberate rather than broken.
What does a desktop application pentest report contain?
- Executive summary with a desktop-specific risk overview
- Technical findings with reproduction steps, CWE identifiers and CVSS v3.1 ratings, mapped to DASVS verification requirements
- Build and configuration review: Node integration, contextIsolation, sandbox settings, DevTools accessibility, remote content loading in the production build
- Inter-process communication and privilege boundary assessment
- Local storage and credential handling review
- Remediation guidance specific to the framework you actually use
- One free retest within one month of the v1.0 report, delivered as a v2.0 report that supersedes v1.0 with per-finding retest status and fresh evidence of the fixed state
Findings map to ISO 27001:2022 A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance), and support SOC 2 CC7.1 (Vulnerability Detection). A pentest report does not evidence A.8.25, secure development life cycle, which is evidenced by process rather than by a test result.
We are not CERT-In empanelled, and we are not ourselves ISO 27001 or SOC 2 certified. We deliver the testing evidence and the control mapping; a separate accredited certification body or licensed CPA firm issues the certificate or attestation.
Rathnakara (OSCP, M.Sc Cyber Security) leads the testing and both founders are on every engagement. If you want to see the deliverable before committing to any vendor, our sample report is ungated.
Desktop application pentest service | View pricing | See a sample report | How to scope your first pentest | Book a 30-minute scoping call