Desktop Application Penetration Testing
Desktop application penetration testing.
Test the client your users install, the data it stores and the services it trusts. Get reproducible findings, prioritised fixes and an included retest, with scope agreed before testing.
Follow the trust boundary.
Map the package, local components and services the client trusts.
The application runs on a machine you do not control.
A desktop client gives an attacker its binaries, configuration and runtime. A hidden button, an encrypted local setting or a disabled menu is not a server-side permission check. We investigate what remains protected when the client is inspected, modified or run as an ordinary user.
The engagement follows the trust boundaries around the application: local files and credentials, privileged services, inter-process communication, installation and updates, and the backend API. We connect weaknesses only within the agreed scope and demonstrate impact with controlled test data.
What we can include
- Windows applications, including .NET and native clients
- Electron and other desktop clients built with web technologies
- Java thick clients; macOS and Linux builds by agreement
- Local databases, configuration, logs, caches and credential storage
- Installers, update packages, signatures and library loading
- Privileged services and inter-process communication (IPC)
- Authentication, sessions, authorisation and backend APIs
- Targeted reverse engineering and input testing where relevant
Why it matters
A trusted client must still cross untrusted boundaries.
An ordinary workstation user may be able to edit a configuration file, replace a library or send a message to a privileged service. A compromised renderer may be able to reach capabilities that were meant to stay inside the desktop shell. We test the boundary, not just the visible interface.
Backend permissions matter just as much. We replay relevant requests independently of the application to check roles, object ownership and business workflows. A client-side restriction is not proof that another user or tenant is protected.
PXLSec / DESKTOP
Explore three boundaries of trust.
Open a boundary to see what we test and what evidence you receive.
01The client and local data
What does the installed package reveal?
Embedded secrets, local databases, caches, logs, tokens and runtime behaviour. We document prerequisites and impact using controlled test data.
02The operating system and updates
Where does the application gain more authority?
File permissions, libraries, IPC, privileged services, installers and update validation. Active scenarios are agreed before testing.
03The backend and business workflows
Does the server authorise each important operation?
Roles, object ownership, sessions and data isolation. We replay requests independently of the interface using the agreed accounts and APIs.
How it works
Scope the application
Agree supported builds, operating systems, roles, test accounts, APIs and the permitted starting point.
Inspect and instrument
Review the delivered package, local storage and runtime; map privileged components and network communication.
Validate the boundaries
Test client-side assumptions, local permissions, update trust and server-side access controls with reproducible evidence.
Report, debrief and retest
Discuss the findings with your engineers, prioritise fixes and verify the agreed remediation.
Why PXLSec
The client and the system around it
Local secrets and sensitive data
Inspect files, databases, logs and memory where agreed. Verify whether recovered tokens or keys can reach anything useful, using test accounts.
Privilege and component isolation
Check file permissions, library search paths, privileged helpers and IPC. For Electron, assess renderer isolation, preload bridges and exposed native capabilities.
Installer and update trust
Review package origin, signature verification, writable paths and downgrade handling. Active update substitution is performed only in an authorised test environment.
The API behind the interface
Test authentication, session handling, role checks and data isolation by calling the backend directly. API targets and roles are agreed explicitly.
What you receive
Clear deliverables, agreed in the proposal, with no surprises at the end of the engagement.
- Executive summaryThe business impact and the decisions your leadership needs to make.
- Technical evidenceAffected builds, prerequisites, reproduction steps and controlled proof of impact.
- Practical remediationFixes for the underlying trust boundary, prioritised by risk and exploitability.
- Included remediation retestVerification of the reported fixes within the scope and window agreed in your proposal.
When you need this
When to test your desktop application
Scope the work around the decision you need to make.
Before a major release
Validate a new client, installer, privileged component or update mechanism before wider distribution.
An enterprise customer asks for evidence
Provide an independent technical report covering the builds and workflows your customer actually uses.
Moving to Electron or a new architecture
Check the new boundary between web content, native capabilities, local storage and backend services.
A regulated business depends on the client
Supply technical testing evidence for your assurance programme. Desktop testing alone is not regulated TLPT or a compliance certification.
Methodology & standards
A methodology fitted to desktop software
- PTES
- NIST SP 800-115
- OWASP testing principles for applicable APIs
- CWE weakness classification
- Platform and framework security guidance
FAQ
Questions we're often asked
Is this different from a web application penetration test?
Yes. Desktop testing includes the installed package, local data, operating-system permissions, privileged components and update mechanisms. The backend API can be included too; it does not replace testing the client.
Which platforms and technologies can you cover?
We scope Windows, .NET, native, Electron and Java clients according to the application. macOS and Linux builds, specialist binary analysis and targeted fuzzing are agreed after reviewing the technology and access requirements. We do not assume every platform is included in one test.
Do you need source code?
Not always. We can start with the installer or release build, test accounts and documentation. Source access can improve coverage of security-sensitive paths; we agree a black-box, grey-box or source-assisted approach in the proposal.
Will you test production or bypass our endpoint protection?
We prefer a representative isolated environment with controlled data. Production activity, endpoint-protection validation, persistence and network movement require explicit additional scope and rules of engagement; they are not implied by a desktop application test.
What should we send to obtain a proposal?
Tell us the application technology, operating systems, number of builds and roles, relevant backend APIs and release deadline. We can sign an NDA before receiving sensitive material. Do not send credentials or binaries through the public enquiry form.
What does the retest cover?
The proposal defines the remediation window and scope. We check the fixes for reported findings and document whether they are resolved, partially resolved or still open. New features or a substantially changed application may require additional scope.
Related services
Discuss your testing scope.
Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.
Confidential from the first conversation
We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.
How we protect your information · Privacy policy