Web application penetration testing

You have an application in production. It handles customer accounts, personal data, maybe payments. Nobody has ever seriously tried to break it, and the question is starting to come up. A client sends you a security questionnaire, an auditor asks for evidence, or you simply read the news this morning.

A penetration test answers one precise question: what can an attacker actually get, and how?

Not “do you have vulnerabilities”, the answer is always yes, but which ones are exploitable, in what order, and with what concrete impact on your business.

Why now

Vulnerability exploitation has become the number one way breaches start: 31%, ahead of phishing (16%) and credential abuse (13%). That is the finding of the Verizon DBIR 2026, built on more than 22,000 confirmed breaches across 145 countries between October 2024 and November 2025. The ranking has flipped: for years, stolen credentials led.

The same report gives the other side of the coin. In 2025, only 26% of critical vulnerabilities were fully remediated, down from 38% the year before. The median time to full resolution went from 32 to 43 days. Exploitation is accelerating while remediation slows down.

For small and medium businesses the report is even harder, three attack patterns for 100% of the breaches observed:

• system intrusion
• basic web application attacks
• social engineering

In France, ANSSI’s 2025 Panorama de la cybermenace records 1,366 confirmed incidents, flat against 2024 (1,361). Reports to the agency are down 18%, but ANSSI attributes part of that drop to the spike around the Paris 2024 Olympics, not to any easing. Meanwhile, data exfiltration incidents went from 130 to 196 in a single year.

The useful conclusion: your exposed web surface is the most frequently used entry point, and finding out what it lets through costs a lot less than learning it the other way.

When to run a test

The most common triggers:

• Before a major release: a new application, a rewrite, opening an API to partners.
• After an architecture change: cloud migration, a move to microservices, a new authentication provider.
• Because a third party asks: a tender, due diligence, an enterprise customer’s security questionnaire, an insurer’s requirement.
• For a regulatory obligation: GDPR article 32 requires appropriate technical measures, explicitly including “a process for regularly testing, assessing and evaluating the effectiveness” of those measures. The NIS2 and DORA frameworks reinforce that expectation of regular testing for the entities in their scope.
• After an incident: to measure the real extent and confirm the door is actually closed.
• On a cycle: once a year, or at every major release, depending on how fast you ship.

If none of these apply and nobody is asking, a penetration test may not be your priority. Starting with developer training costs less and avoids paying to have the same classes of flaw pointed out at every audit.

What I test

Scope is agreed with you up front. The following tests have been my hunting ground for 10 years for a typical web application, see my CVEs and my technical write-ups:

• Authentication and session management: user enumeration, password reset flows, rate limiting, cookie attributes, session fixation and hijacking, multi-factor…
• Access control: horizontal/vertical privilege escalation, insecure direct object references, isolation between accounts. This is category A01 of the OWASP Top 10:2025, and still the first source of serious findings in practice.
• Injection: SQL and NoSQL, OS commands, code, templates, client-side injection…
• File handling: arbitrary upload, path traversal, local and remote file inclusion, storage and serving of uploaded files.
• Business logic: bypassable step sequences, tampering with amounts or quantities, race conditions. This is what no scanner finds.
• Configuration and exposure: headers, Content Security Policy, CORS, verbose error messages, client-side secrets, reachable Git repositories and backups, API data leaks…
• Peripheral attack surface: forgotten subdomains, side services, inadvertently published secrets.

No, it does not look like this. In reality: a lot of code reading, a tracking spreadsheet, and three coffees before pointing out why a sequential order ID is a problem.

How it runs

1. Scoping: technical perimeter, test accounts, environment (staging or production), testing window, emergency contacts, signed audit agreement. Nothing starts before that signature.

2. Reconnaissance: mapping the surface that is genuinely exposed. This is often the first surprise: the inventory you have in mind and what is reachable from the internet rarely match.

3. Functional mapping: user journeys, roles, entry points, API endpoints. The goal is to understand the application before attacking it, otherwise you are testing at random.

4. Manual testing: the core of the work. Tooling is there to parallelise (Burp Suite Pro, SQLmap, purpose-built scripts), not to decide. Frameworks used: the OWASP Web Security Testing Guide for coverage, OWASP ASVS for the level of rigour, PTES for overall structure.

5. Measured exploitation: demonstrating impact without degrading the service. A proof of exploitation, not a show of force. Destructive actions are excluded by default and never attempted without explicit written approval.

6. Report and debrief: written deliverable, then a session with your developers.

The report

This is the deliverable, and it is the part most providers rush.

• A one-page summary, jargon-free, readable by a management team: what was tested, what was found, what to fix first.
• The vulnerability inventory, each item with its CVSS score, a severity contextualised to your environment, the full attack scenario and reproducible steps.
• Usable evidence, raw requests, screenshots, reproduction conditions. Your developer should be able to replay the finding without calling me.
• Prioritised recommendations, ranked by impact against remediation effort, rather than an alphabetical list of generic best practices.
• A live debrief with the technical team, for the questions that do not fit in a document.

A publicly reachable admin login page is an informational finding, not a critical vulnerability. Inflating scores fills the report and empties its value: by the third audit where everything is “high”, nobody reads it any more, and the one genuinely critical finding drowns in the noise. Accept short reports when the application is in good shape!

What a penetration test is not

Better said before you sign:

• It is not an automated scan with a new label. If the report looks like a tool export, you paid for a licence, not for expertise.
• It is not exhaustive. Time is bounded, so coverage is bounded too. A penetration test gives you a snapshot, at a date, on a perimeter, within a budget. It does not prove the absence of flaws, nothing does.
• It is not a code audit. The two are complementary: a pentest sees what is exploitable from the outside, a code audit sees what is fragile on the inside.
• It is not a bug bounty. A bug bounty programme buys you duration and diversity of approaches; a penetration test buys you depth and traceability on a defined perimeter. I have worked both sides and can tell you which one fits your situation, including when the answer is “neither, for now”.
• It fixes nothing by itself. Recall the number above: 74% of critical vulnerabilities go unremediated. A report that ends up in a shared drive has improved nobody’s security.

Why me

About 25 years of web development, then security full time.

• Auditor for the French Ministry of Armies, 2020 to 2024: penetration tests, configuration audits against ANSSI recommendations, and code audits on Linux systems and web applications.
• Bug hunter since 2016: several hundred reports submitted to startups, large enterprises and public institutions. Including subdomain takeovers, SQL injection, SSRF, remote command execution, full AWS account takeover and more…
• Published CVEs under my own name: see the list.
• Trainer since 2022: dozen of courses delivered, which means I know how to explain a flaw to the team that will have to fix it.
• A developer first: I read your code without a translator, and my recommendations account for what they cost to implement.

A public example of what that produces: my analysis of a critical French medical application.

Frequently asked questions

How long does it take? Three to ten days of testing depending on scope, plus reporting. A mid-sized business application is usually around five days.

What does it cost? Quote on request, fixed price. The drivers: number of features and roles, presence of an API, whether a test environment is available, and whether retesting is required. I give a range in our first exchange, before any commitment.

Black box or grey box? Grey box in the vast majority of cases, with test accounts for each role. A real attacker eventually obtains an account; refusing them to me spends your budget getting through a door instead of exploring what is behind it.

Can it break production? The risk is never zero, which is why a staging environment mirroring production is preferable. On production, intrusive tests are dropped, the window is agreed in advance, and you have my phone number throughout.

What if you find nothing serious? You get a report that says so, detailing what was tested and how. That is a useful document to put in front of a client or an auditor, and it’s the outcome I prefer.

Finally, if your teams want to build the skills to stop finding the same categories of flaw next year, that is exactly what my courses are for.

Let’s talk

Describe your application in a few lines - what it does, who uses it, what worries you and I will reply with a proposed scope and a price range.

Gwendal Le Coguic - contact@glc.st - quotes on request - SIRET 79778302400038