POCFORGE / DESKTOP AND ELECTRON

Desktop and Electron penetration testing

Human-led testing of Electron and classic thick clients: renderer isolation, IPC as a private API, local secrets and update channels. A privilege boundary, proved, then retested.

TYPICAL INVESTMENT: $4K – $7.5K · taxes as applicable · India indicative ₹40,000 – ₹95,000 + GST · final quote based on platforms and privilege boundaries.

India-intent buyers: Desktop application pentesting in India. Global pages stay scope-based; published INR bands live on the India lander and the India cost guide.

What we test

Desktop apps fail where a web renderer, a plugin or a deep link is trusted with local privilege. We map that boundary and show a path across it when one exists. The method notes behind the Electron work are public: Electron security deep dive and threat model and architecture.

Privilege map

Windows, webviews, preload scripts, IPC, custom protocols, deep links, plugins and update paths — and which of those run with a local privilege the renderer should not have.

Renderer isolation

BrowserWindow and webPreferences such as contextIsolation, sandbox and nodeIntegration, and whether a preload bridge hands Node, the filesystem or a shell to page content.

IPC as a private API

Handlers treated like authenticated endpoints: argument checks, caller context, paths and URL controls. A channel the UI never shows is still a channel.

Local secrets

Tokens and files on disk, in SQLite or IndexedDB, in keychains and in logs another local user or a second app can read.

Files, archives and plugins

Import, export, archive extraction and plugin install paths for traversal, unsafe destinations and missing provenance checks.

Deep links and updates

Custom protocols, navigation into privileged content, and update-channel authenticity when that channel is in scope.

Classic thick clients

Insecure local IPC, weak local auth, search-order issues and unsafe native integrations, held to the same evidence standard as Electron.

Proof of impact

A path from attacker-controlled renderer or file input to a privileged action, demonstrated safely. Scanner-only noise does not make the report.

Why Electron is not a web test

The UI is often web technology. The privilege is not. A cross-site scripting bug that is a nuisance in a browser can be a local compromise when the renderer can call into Node or a native bridge. Testing only the hosted marketing site, or only the API, leaves that boundary unexamined. Classic thick clients deserve the same honesty: local trust is the subject, not a footnote.

We remove the duplicated “one slogan” method block this page used to carry. There is one engagement sequence, below, and it is the one we run.

How an engagement runs

Human testers lead. Tooling is there to widen coverage, not to replace judgement. Every finding that ships in the report was reproduced, and in-scope fixes are retested.

ENGAGEMENTSelect a step

Steps are also written below if scripts are off.

  1. Scope and build access. Platforms (Windows, macOS, Linux), build channel, test accounts, update exclusions and rules before active testing.
  2. Surface mapping. UI flows, preload APIs, IPC, protocols, storage and native bridges, written as a privilege map.
  3. Controlled testing. Trust-boundary failures and safe proofs. No destructive behaviour, no testing of customer machines.
  4. Report. Severity, evidence and a remediation note an Electron or desktop engineer can implement.
  5. Retest. The build you ship back is checked against the original paths.
  6. Sibling scopes. The API or web service the desktop app calls is included only when named. Otherwise it is a separate assessment.

Deliverables

  • Executive summary of desktop risk and the notable boundary crossings.
  • Technical findings with reproduction on the build we were given.
  • Privilege-boundary notes: IPC, preload and privileged surfaces observed.
  • Retest confirmation.

A report can support SOC 2 and ISO 27001 evidence. It does not certify the company, and it does not replace the auditor. PoCForge is not a certification body and does not claim CERT-In empanelment. If a contract names an empanelled auditor, read when CERT-In empanelment is required and check the official list before you shortlist.

Who this fits

Teams shipping Electron productivity, fintech, security or SaaS companion apps, and teams with a classic thick client that still holds local privilege. Source helps and is not required. If the product is only a website, use web application testing instead.

Investment

Indicative $4,000 – $7,500 before taxes. India indicative ₹40,000 – ₹95,000 + GST. Extra platforms, plugin ecosystems and a combined API pass move the quote. Pricing calculator · India desktop page · India cost guide.

Preparing a useful desktop scope

Send the installer or store build for each operating system you want covered, the version string, and whether auto-update is enabled in that build. Name test accounts if the app syncs to a backend. Say if plugin installation, custom protocols or a helper service running as a higher local user is part of the product. If a component is a third-party embed you cannot change, mark it so the report does not assign you a fix you do not own.

Tell us what must not be touched: a production update server, a licensing backend shared with paying customers, or crash-reporting that would alert real users. We would rather exclude a host than discover the boundary during the test. If the same team owns the API the desktop client calls, decide in the scope review whether that API is in this engagement or in a paired API test. Leaving it implicit is how findings fall between two tickets.

On Electron, a short architecture note saves time: which windows are privileged, which preload scripts exist, and whether you already set contextIsolation and a sandbox. We will still verify the binary. The note stops us arguing with a diagram that was never shipped. Classic thick-client scopes should name the IPC mechanism, the service account, and any search path you already know is fragile.

How to read the report

Lead with the boundary crossings, not the longest list. A missing security header inside a renderer that has no privilege is not the same item as a preload bridge that exposes a shell. Severity follows what a local attacker, another local user, or a hostile file can reach. Remediation is aimed at the setting, the handler or the API check that breaks the path. The retest is against those items on the build you nominate, and the closure note says what was fixed, what was accepted, and what was not ready.

This page used to repeat the engagement sequence twice. It is once, in the steps above. India buyers who need the INR narrative and the local procurement context should use the India lander; the method does not change between the two URLs.

Related

Frequently asked questions

What is desktop or thick-client penetration testing?

It is a test of a locally installed application and the privilege it holds: Electron bridges, classic IPC, storage, files and updates. The question is what untrusted content can make the app do.

Why is Electron called out separately?

Because a renderer compromise can become a local compromise when isolation or the preload bridge is wrong. A normal web test does not see that boundary.

Do you need source code?

No. An installable build is required. Source shortens the work when you choose to provide it.

Will testing disrupt users?

No. We test the build you give us, not customer desktops.

Do you claim CERT-In empanelment?

No. PoCForge does not claim CERT-In empanelment.

Scope a desktop assessment

Tell us the platforms, the build, and whether Electron, a classic client, or both.

Get a free scope review →