Desktop application penetration testing

Test a desktop application, sometimes called a thick client, from the position of someone who can use the workstation. Follow what the application stores locally, what it sends to a server and which checks either side enforces.

What remains on a shared workstation after sign-out?

A second standard user can open a cached export left behind by the first user.

Illustrative test report

Evidence: Record the application build, operating system, file location, permissions and affected workflow.
Decision: Local storage belongs with the desktop build owner. A backend authorisation issue belongs with the service owner.
Verification: Repeat sign-out and the second-user access check on the corrected build.

When to choose this service

You are releasing a desktop client, installer or update mechanism to staff or customers.
The application stores sensitive records offline or runs on shared workstations.
A new integration or user role changes which information the client can read or change.

Name the application build, supported operating systems, deployment method and backend services. Agree which functions run on the workstation and what can be tested on connected services, including supplier-owned dependencies.

What we examine

The local files, settings, caches and logs created during a representative workflow, including what remains available after sign-out.
Whether roles and access limits are enforced by connected services when the desktop interface is bypassed.
For the agreed platform, how the application installs and updates, what permissions it requests and how it establishes trust in packages or remote connections.

What to prepare

The exact application build, installer version, operating-system edition and patch level on the test workstation. Include a clean snapshot and the name of the release owner.
Test accounts for relevant roles, a sample workflow, test data and an authorised backend environment.
The expected local storage and update behaviour, a list of external services and any restrictions on examining binaries or components.

Agreed boundaries

Use an isolated test machine or snapshot, a representative build and synthetic records. Confirm your right to test packaged components. Keep changes to live software distribution and third-party services outside the exercise unless specifically authorised.

What you receive

Findings tie each issue to a build, operating system, user role and workflow. Evidence distinguishes problems in local storage or packaging from changes that the backend team needs to make.

A file left readable after sign-out goes to the desktop build owner. If the backend returns another user’s record after a fresh request, the service owner needs to correct and retest that permission check. Record both owners where a workflow crosses the client and server.

Follow-up

Provide the corrected build or service endpoint. The tester repeats the original workflow and checks whether the same user can still obtain access. Vambrace offers free retests of vulnerabilities found for 12 months.

Tell us the business question, the systems or sites involved and the decision that depends on the result.

Scope a desktop application test