Web penetration testing, run like a real attack.
A web penetration test, or web pentest, attacks your application the way a real adversary would, with your written authorization and within an agreed scope, to find the exploitable flaws before someone else does. We combine our in-house tools with hands-on expertise: many serious flaws, like broken access control between two accounts, only show up once you understand the application.
At a glance
- ScopeA live web application: its user accounts, its user flows and its back office.
- What we look forAccess controls that can be bypassed, authentication that can be broken, injection, and business rules that can be bent.
- What we need from youOne account per role. The code is not required.
- What you getA report with proof for every finding, a debrief with your team and a retest within 60 days.
Vulnerabilities found across these sectors
- Public services (.gouv.fr)
- CAC 40 groups
- Luxury leaders
- National media
- Local authorities
Your application is unique. Your testing should be too.
No tool knows your business rules, your roles or your user journeys. An attacker will take the time to learn them. We do it before they do.
A vulnerability scanner spots an outdated component version, a missing header, sometimes an obvious injection. That is useful, and you should have one running all the time: a scan and a pentest answer different questions.
But it never asks whether ID 4172 in a URL can be swapped for 4173 to read the next customer's document. It does not notice that a read-only role can call the delete action directly, because the button was hidden in the interface but never blocked on the server.
A good share of the flaws in our reports are exactly this kind.
Before the fix
Another customer's order comes back with a 200: nothing checks who owns it.
After the fix
The server now checks who owns each order and refuses anyone else's.
The same request, with the next ID along. Flip the card to see the fix.
When to run a penetration test.
Not a one-off: at the key moments in your application's life.
Before going live
The cheapest moment to fix anything: nothing is exposed yet, no real data is at stake.
After a redesign or a new feature
A new journey, a new role or an integration opens a surface that has not been tested yet.
Before a funding round or a major client
Investors, buyers and large customers increasingly ask for proof that the application has been tested.
Once a year
Frameworks such as ISO 27001 or PCI DSS expect regular testing, and your code changes every week.
After an incident or an alert
Find out how they got in, and make sure no other door was left open.
What we test.
Six families of vulnerabilities we look for on every engagement, and where each one hides in your application.
Access control
Horizontal and vertical: Changing an identifier in a request to reach another user's data., reading another user's data, privilege escalation.
Authentication and sessions
Password reset, second factor bypass, predictable tokens, incomplete logout.
Injection
SQL, NoSQL, operating system commands, server-side templates, stored and reflected A script slipped into a page and run in your visitors' browsers..
Business logic
Negative prices, stackable discounts, skipped checkout steps, bypassed quotas, replayable workflows.
Upload and file handling
Execution of uploaded files, path traversal, overwriting existing files.
Configuration and exposure
Making your server call an address the attacker chooses, often your internal network., permissive The rule that decides which other sites may read your application's responses from a browser., reachable backups, verbose errors, secrets shipped to the browser.
How an engagement runs.
Six steps, from scoping to retest, the same on every engagement.
Read the full methodology- 01
Scoping
A conversation to understand what your application does, what worries you, and what would actually hurt if it happened. We agree on the exact scope, the domains involved, what is excluded and the testing window. NDA as soon as we get into technical details, penetration test authorization agreement once the quote is signed, before any access.
- 02
Reconnaissance
Full mapping: subdomains, entry points, technologies, roles, data flows. The goal is a more complete map than your own team has, because an attacker does not stop at the pages in your site's menu.
- 03
Exploitation
The long part. Our in-house tools cover the surface. Where they stop, we manipulate requests, swap identifiers, skip or repeat steps in your user flows and act with another role's rights, until the impact is proven.
- 04
Impact & proof
A flaw only matters for what it lets an attacker do. For each finding we establish what an attacker would actually obtain, with a proof of concept your team can replay.
- 05
Report and debrief
A report ranked by real severity, with the impact spelled out for your leadership and concrete fixes for your developers. Then a live debrief with your team. See an example report.
- 06
Retest & closure
Once your fixes ship, we check every finding again. A fix that only covers one case out of two is not a fix, and that happens more often than people expect. The retest is included.
Black, grey or white box.
What you give us up front determines how far the test can reach. Our advice, in almost every case: grey box.
Black box: just the URL
- You provide
- The application's URL. No accounts, no code.
- The test reaches
- What an anonymous visitor sees: public pages, forms, exposed APIs. Everything behind the login stays out of reach, unless a flaw gets us past it.
- Choose it when
- You want to know what a stranger can do from the internet. The days spent on reconnaissance cut into the time left for everything else.
Grey box: one account per role Our advice
- You provide
- A test account for each role: customer, manager, administrator. The code stays with you.
- The test reaches
- Everything each role sees, and above all what it should not see. Most of your sensitive data sits behind the login.
- Choose it when
- In almost every case. It is the best balance between the realism of an attack and the coverage of the test.
White box: the accounts and the code
- You provide
- The test accounts, plus access to the source code and the documentation.
- The test reaches
- Everything above, plus the rare paths the interface never exposes and the logic written in the code.
- Choose it when
- On sensitive, bespoke code, when depth matters more than realism.
What this looks like in practice.
Real findings, all fixed since.
reports sent with a critical vulnerability
Out of more than 485 reports sent, in penetration tests and bug bounty.
reports sent in total
In penetration tests and bug bounty.
Active in bug bounty
Researchers on YesWeHack and Intigriti, two European bug bounty platforms where every flaw is checked before it is accepted.
- CriticalFixed
IDOR
Access to the complete records of other citizens on a French public service (.gouv.fr).
- CriticalFixed
SQL injection
Read access to an entire company database.
- HighFixed
XSS
Full account takeover with no action required from the victim.
- HighFixed
Business logic
A validation step in a checkout flow that could be skipped: orders completed without paying.
We never disclose a client's name, nor any detail that would let anyone recognize them.
The report you receive.
Every finding proven, explained and prioritized: a document your leadership and your developers can both read and use.
The complete records of other citizens on a public service, readable by changing a single identifier. Personal data exposed: a regulatory risk and a blow to users' trust.
SeverityCritical, one changed ID
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains each of them, ready to replay.
Check on the server, on every request, that the signed-in user is allowed to read the requested record, and deny by default.
PriorityImmediate, retest included
A company's entire database, readable from the application itself through a manipulated query.
SeverityCritical, full database
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains each of them, ready to replay.
Replace every hand-built query with parameterized queries, and cut the database account's rights down to what it strictly needs.
PriorityImmediate, retest included
An order could be completed without paying, by skipping a validation step: a direct loss of revenue.
SeverityHigh, no payment needed
Requests, screenshots and reproduction steps: redacted in this sample. Your report contains each of them, ready to replay.
Enforce the order of the steps on the server, and confirm an order only once the payment provider has confirmed the payment.
PriorityHigh, retest included
Prioritized report
Every flaw in the application ranked by real severity: what an attacker would actually get, not a theoretical score.
Reproducible proof of concept
The exact requests, which your developers can replay in their own environment to see the flaw for themselves.
Business impact
Which accounts, which data, which orders are exposed, spelled out plainly for your leadership.
Concrete remediation
The server-side fix to apply, explained in detail for the team that maintains the application.
Retest included
Once your fixes are live, every flaw is replayed: it is closed only when the proof no longer works.
Debrief with your team
A session with your developers to walk through the findings, answer their questions and prioritize the fixes.
What it costs.
Every engagement is quoted, and here is why: a flat rate set without knowing your scope would be wrong one way or the other. To give you a first idea, here is our pricing by kind of engagement.
From€2,700 incl. tax
Brochure site or store
Four to six days. The public site, its forms, its customer area and its checkout flow.
From€3,200 incl. tax
Focused API
Four to eight days. The spread comes from the number of sensitive endpoints multiplied by the number of roles.
From€7,500 incl. tax
Business application or SaaS
Ten to fifteen days or more. Several roles, overlapping permissions, whole journeys to break through.
What moves the price
First, the number of roles to test. Every extra role multiplies the access control combinations to verify.
Then the functional size: a brochure site is nothing like a forty-screen business platform. Then whether there is an API, a checkout flow, Single sign-on: one account to get into several applications, often through Google, Microsoft or Okta. or third-party integrations, each adding its own attack surface. Finally, how deep you want us to go.
The first call commits you to nothing and exists to work all of this out. If you need less than you thought, we will tell you.
25access checks
Same role, different accountOne role against another
Every square is a question. Can this role reach that role's data or actions? Two roles make four squares, five roles make twenty-five, and any square can hide a flaw.
Evidence for your audits.
Several frameworks require you to test your security controls regularly. Our report is evidence your auditors know how to read: scope, method, proof and verified fixes.
ISO/IEC 27001
Annex A, controls 8.8 and 8.29
Management of technical vulnerabilities and security testing. The report shows what was tested, found, then fixed.
PCI DSS
Requirement 11.4
Regular penetration testing, with exploitable flaws fixed. The included retest documents the fix.
SOC 2
Criterion CC4.1
Auditors often ask for a recent penetration test as an independent evaluation of your controls.
GDPR
Article 32
Regularly testing, assessing and evaluating the effectiveness of security measures. The report is a dated record of it.
NIS 2
Article 21
Assessing the effectiveness of your cybersecurity risk-management measures, vulnerability handling included.
DORA
Articles 24 and 25
For financial entities, a digital resilience testing program that includes penetration testing.
We do not issue certifications: we provide the technical evidence your auditors ask for. Our method follows the A non-profit foundation that publishes the most widely used web security references, including the testing guide we follow. Web Security Testing Guide and the structure of Penetration Testing Execution Standard: the outline of a penetration test engagement, from scoping to report., detailed here.
Can a pentest break my production site?
No. We stick to read access and minimal proofs of concept: we show that access is possible and go no further. Tests that could degrade the service, such as denial of service or bulk sending, are excluded by default and only run on written request within an agreed window.
How long does a web penetration test take?
Anywhere from a few days to several weeks depending on the perimeter. A brochure site with one form is quick. A back-office with ten roles, a checkout flow and an API takes considerably longer. The duration is fixed during scoping, before anything is signed.
Do I need to provide test accounts?
It is strongly recommended. A grey-box test with one account per role finds far more access control flaws than a purely external test, because most sensitive data sits behind authentication. Without accounts, everything reserved for logged-in users stays out of reach.
How is this different from a vulnerability scanner?
A scanner compares your application against a database of known signatures. It does not understand your business logic, so it usually misses an order ID in a URL that lets one customer read another customer's order. That is exactly what hands-on testing is for.
Is the retest charged separately?
No. Verifying that your fixes hold is part of the engagement. A report whose fixes nobody verifies has not done its job.
Black, grey or white box: which one should I choose?
Grey box in almost every case: you give us one test account per role, with no access to the code. It is the best balance between the realism of an attack and the coverage of the test. Black box loses days on reconnaissance for little extra realism, and white box only pays off on sensitive, bespoke code.
Is your report enough for an ISO 27001 or PCI DSS audit?
It is one piece of it, not a certification. The report documents the scope, the method, every finding with its proof and its fix verified at retest: what auditors ask for under security testing requirements, such as Annex A of ISO 27001 or requirement 11.4 of PCI DSS.
What happens if you find a critical flaw during the test?
You hear from us the same day, without waiting for the report, with enough to understand and contain it immediately. That is a rule set before the engagement starts, and it is why we always ask for a contact who is reachable during the testing window.
The other services.
Depending on what you expose, another engagement may suit you better.
API security audit
REST, JSON and GraphQL: what every endpoint really exposes, and to whom.
See the serviceWordPress penetration testing
Plugins, themes, roles and the admin surface left open to the internet.
See the serviceWebsite security audit
Brochure site, online store or CMS: the security of what your visitors see.
See the serviceAuthentication and access control
IDOR, privilege escalation, accounts that reach what they should not.
See the serviceGet your application tested.
Your app is a target.
Tell us about the scope: what the application does, how many roles it has and what worries you. We'll get back to you with a scoping proposal and a quote. The first call commits you to nothing.