Application security testing
We probe your application the way an attacker would: business logic, roles and permissions, the API and whatever happens on the user device. You get evidence, not a list of theoretical vulnerabilities.
- ISO/IEC 27001
- 3000+ workstations under care
- NIS2 and national cybersecurity
- DPO as standard
- Since 2017
The application your clients or your warehouse rely on is a more common target today than the server in the rack. We test web apps, portals, APIs, Android apps and warehouse or terminal systems, so the holes surface with us rather than with someone who will not introduce themselves.
What we test
We tailor the scope to how the application is built and where the real risk for the business sits.
-
Web apps and portals
Client panels, shops, internal systems. Authentication, sessions, roles, access to other people data and injection style flaws.
-
APIs and integrations
REST interfaces and webhooks the app uses to talk to other systems. Per resource authorisation, rate limits, data leaking through responses.
-
Android mobile apps
Package analysis, data stored on the device, traffic to the server, certificate pinning and whatever can be bypassed on the client side.
-
Warehouse and terminal systems
WMS apps, data collectors and terminals. Access control, behaviour on the plant network, isolation from the rest of the environment.
-
Kiosk stations and Windows PE
Kiosk mode workstations and preinstallation environments. Whether the shell can be escaped, the image swapped or the file system reached.
-
A report with evidence
Every finding with reproduction steps, a risk rating and a concrete recommendation, plus a retest after the fix to confirm the hole is closed.
What is application security testing?
Application security testing is a controlled attempt to break one specific program: a web application, a portal, an API, a mobile app or a warehouse system. We check whether one user can reach another user data, bypass permissions, perform an action without authorisation or extract data from the system. The output is not a list of theoretical vulnerabilities but confirmed attack paths with reproduction steps.
We work in three modes: with no knowledge of the system (black box), with an account and documentation (grey box) and with access to the source code (white box). The middle one usually gives the most value: having an account lets us examine what fails most often, which is permissions and business logic rather than just the input layer.
How this differs from infrastructure penetration testing
An infrastructure penetration test looks at the environment: servers, network, internet facing services, configuration. It answers whether someone can get into the company. Application security testing looks at one program and its logic: whether a logged in client can see another client invoice, whether a price can be changed in the basket, whether a warehouse worker can perform an action reserved for a manager.
These are complementary, not alternatives. A company with a secure infrastructure and a leaky application loses data just as effectively as a company with the opposite problem. If you are not sure where to start, we usually suggest the application that handles client data, because that is the one exposed to the world around the clock.
Warehouse, terminal and kiosk applications
This is the area companies think about least and it is often the weakest link. A data collector or a shop floor terminal usually signs in with one shared account, has the database password stored locally and sits on the same network as the rest of the company. All it takes is escaping the app into the operating system and an attacker has a foothold.
We test exactly those scenarios: whether kiosk mode can be escaped, what is stored in the device configuration, how it talks to the server and whether warehouse hardware is separated from the office segment. With Windows PE and installation images we also look for embedded credentials, a classic that can survive in a company for years.
When it is worth testing an application
The usual moments are: before launching a new application or client portal, after a large change to roles and permissions, ahead of a corporate client audit that asks about testing in a security questionnaire, and while preparing for NIS2 or ISO 27001.
A separate case is an application inherited with an acquisition or left behind by a previous supplier. Nobody knows what is inside it, yet the responsibility already sits with you. A test gives you a starting point: what the biggest exposure is and whether the code is worth maintaining at all or better scheduled for modernisation.
What you get after the tests
A technical report listing every finding with reproduction steps, evidence and a risk rating that makes sense for your business rather than only for a scoring table. Plus a summary for the board: what is genuinely dangerous, what can wait and what the fixes realistically cost.
We include a fix plan split into what can be corrected straight away in configuration and what needs changes in the code. After your fixes we retest those findings to confirm the holes are actually closed rather than merely covered up.
If someone else wrote the application, we phrase the findings so they can be handed to that supplier without translation. We can also talk to their developers directly if you would rather shorten the path.
How we run the tests
Scope and rules are agreed in writing before we start, so the test surprises neither you nor your users.
- scope in writingagreed before we begin
- no downtimeon a copy or in a service window
- evidencereproduction steps for every finding
- retestconfirmation after the fix, included
- Scope and consent first. We agree what is tested, in which hours and what stays untouched. All in writing, including consent from the system owner.
- We test safely. We work on a copy of the environment or in an agreed window. We do not destroy data or take production down to prove a point.
- Critical findings reported at once. If we find a hole that risks a leak, we call the same day rather than saving it for the final report.
- We verify after the fix. Once you have made the corrections we come back and confirm the findings are closed. The retest is part of the service.
Billing
We price testing at a fixed fee after a short scoping questionnaire. You know the amount before we start and it is not billed by consultant hour.
Included
- Testing within the agreed scope
- Technical report and board summary
- Prioritised fix plan
- Retest of the findings after the fix
Beyond the plan
- Fixing defects in the application code
- Further rounds after major changes
- Recurring tests under a subscription
The quote depends on the number of roles, screens and integrations, and on whether the mobile layer and devices are in scope.
Frequently asked questions
How does application security testing differ from penetration testing?
Penetration testing looks at the environment: servers, network and internet facing services. Application security testing looks at one program and its logic: permissions, roles, the API and whether a logged in user can reach someone else data. They complement each other rather than replace each other.
Do you test Android mobile apps?
Yes. We analyse the application package, data stored on the device, traffic to the server and what can be bypassed on the client side, for example a check performed only inside the app. We also test the API the app talks to, because that is usually where the real risk sits.
Do you test warehouse systems and terminals?
Yes, this is one of our areas. We look at WMS apps, data collectors, terminals and kiosk stations: whether the app can be escaped into the operating system, what sits in the device configuration, how authentication works and whether warehouse hardware is separated from the office network. With Windows PE images we also look for embedded credentials.
Will the test disrupt our operations?
We plan it so that it does not. Testing runs on a copy of the environment or in an agreed service window, and the scope and hours are set in writing beforehand. We do not delete data or take production down to prove a point.
How long does application security testing take?
For a typical web application with a few roles, usually one to two weeks: a few days of testing, then the report. An application with a large API, a mobile part and warehouse devices needs more. We give you the timeline together with the quote.
How much does it cost?
We price it at a fixed fee after a scoping questionnaire rather than by the hour. The amount depends on the number of roles and screens, the number of integrations and whether the mobile layer and devices are included. The retest after fixes is part of the service, not a separate line.
What if another supplier wrote the application?
Very common and not a problem. We write the report so it can be handed to that supplier without technical translation, and we can talk to their team directly if needed. If the code turns out to be in a state where patching makes no sense, we will say so plainly and show what modernisation would cost.
Will you help fix what you find?
Yes, if that is what you want. We can fix an application we maintain, support your team or advise you in the conversation with an external supplier. Fixing is quoted separately, because its scope is only known after the tests.
Related services
Let us talk about your project
Answer 2 questions about your company. You will see a simple estimate right away, and we will prepare a full proposal within 24 business hours.
- 2 minutes, no commitment
- You talk to an engineer, not a salesperson
- No spam, one contact about your quote