Services
Overview Cybersecurity solutions Penetration testing SOC Digital forensics & incident response Audit & Advisory GRC Security awareness & training Social engineering IT staffing & placement
Partners
Overview Fortinet Palo Alto Networks WALLIX Netskope Rapid7 Tenable Proofpoint Netwrix Illumio Claroty Microsoft Tufin
Use cases
Overview Infrastructure & network Unified secure network Industrial infrastructure Wi-Fi network Zero Trust access (ZTNA) Cloud & identity Microsoft 365 / Azure migration Privileged access (PAM) Active Directory Corporate email Detection & response Detection capability (SOC) Responding to a compromise Vulnerability management Compliance & resilience Preparing for ISO 27001 ICT Minimum Standard DORA regulation Business continuity (BCP/DRP) Human factor Reducing human risk Offensive testing Web application testing Generative AI application Red Team
Clients
Company
About Certifications Careers CSR commitments
Contact
FRENDE
Application & web

Testing a web application before go-live

An application goes live with its features validated and its security assumed. Application penetration testing turns that assumption into a finding, before someone else does it for you.

The challenge

What a scanner will never find

Automated analysis covers most known technical defects: outdated libraries, missing headers, classic injection. It is useful, it is fast, and it should be done. But a scanner does not know your business.

And the defects that cost the most are precisely the ones rooted in your logic: an order identifier you can increment to read the next client's file, a role that checks authorisation on display but not on action, a price recalculated in the browser, a validation step that can be skipped. None of these has a signature; they are found by understanding what the application is meant to do.

To that add the surface the browser does not show: the APIs. They often carry looser controls than the interface calling them, because nobody expects them to be called directly. That expectation holds up poorly.

What is at stake
  • Another client's data reached by simply changing an identifier
  • Authorisation checked on display, absent on the action itself
  • API less protected than the interface consuming it
  • Business rule bypassed by skipping a step
  • Fixes shipped without any check that they hold
Diagram

Five steps, one of them often forgotten

How an application penetration test unfolds 1Scoping& accounts2Functionalmapping3Manualexploitation4Prioritiseddebrief5Retestof the fixes
The retest is no formality: it is what separates a report that was read from a risk that was actually closed.
Our approach

How we proceed

The test is best run against a staging environment faithful to production, with representative data but no real client records.

01

Scoping and access

Perimeter, environment, roles to test and rules of engagement. We ask for accounts at every privilege level: that is what makes it possible to check that an ordinary user cannot do what an administrator does.

02

Functional mapping

Walking the application as a user, then recording entry points, the APIs underneath and the business rules governing them. This step conditions everything that follows: you only test well what you have understood.

03

Manual exploitation

Hunting for authorisation and business-logic defects, authentication and session weaknesses, injection and vulnerable dependencies. Every finding is exploited until its real impact is demonstrated, never left as a suspicion.

04

Prioritised debrief

A report with two readings: what an attacker could reach and what needs deciding, then the technical detail with reproducible proof and a proposed fix. The ranking follows the risk in your context, not a raw score.

05

Retest

Once fixes are in, we replay the agreed scenarios to confirm they hold and have not simply moved the problem elsewhere.

Services involved

Several disciplines, a single point of contact

The test reveals, code review traces it to the root, training prevents the repeat.

Penetration testing Security awareness & training Cybersecurity solutions Audit & Advisory GRC
Deliverables
  • Report prioritised by real risk
  • Proof of exploitation your teams can reproduce
  • A proposed fix for every finding
  • Technical and executive debriefs
  • Retest to confirm the fixes
Frequently asked questions

Frequently asked questions

Staging, provided the environment is faithful and the data representative. It is the more comfortable setting: we can probe without restraint. A production test remains possible, under tighter rules of engagement — destructive actions excluded, agreed window, a reachable contact on both sides.

Accounts, yes, and at every privilege level: without them we cannot check authorisation rules, which are the leading source of serious defects. Source code is not required, but it speeds things up and goes deeper — that is what a code review is for, as a complement.

An annual test photographs an application that has changed fifty times since. On a fast release cadence, automated analysis holds the continuous coverage, and manual testing concentrates on structural changes: a new journey, a new role, a new exposure.

No, the two complement each other. The scanner covers known defects broadly and continuously; manual testing finds what is rooted in your business logic and that no signature describes. Dropping the first costs coverage, dropping the second costs depth.

Your application goes live next week?

Describe its scope and we will tell you what a test can cover before then.

Contact us