Web penetration testing, run like a real attack.
A web penetration test means attacking your application under the same conditions as a real adversary, with your written authorization and a defined perimeter, to find the flaws that can be exploited before someone exploits them against you. I do it manually, because the vulnerabilities that cost real money are not the ones a tool or an AI knows how to recognize.
The scanner said "all clear". That means nothing.
A vulnerability scanner compares your application against a catalogue of known signatures. It spots an outdated component version, a missing header, sometimes an obvious injection. That is useful, and it should be running continuously on your side: a scan and a pentest answer different questions.
But a scanner does not know what an order, a medical record or a contract is. It never asks whether ID 4172 in a URL can be swapped for 4173 to read the document belonging to the customer next door. It does not notice that a user with a read-only role can call the delete action directly, because the button was hidden in the interface but never blocked on the server. These flaws have no signature: they are specific to your business.
That is exactly where I look. The reports I hand over consist mostly of that kind of finding, and those are the ones that turn into real incidents.
What I test.
On a typical web application, most of the risk concentrates into a handful of vulnerability families. These are the ones I cover every time.
- Horizontal and vertical access control: IDOR, 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 XSS.
- Business logic: negative prices, stackable discounts, skipped checkout steps, bypassed quotas, replayable workflows.
- Upload and file handling: execution, path traversal, overwriting existing files.
- Configuration and exposure: SSRF, permissive CORS, reachable backups, verbose errors, secrets shipped to the browser.
How an engagement runs.
Scoping
A conversation to understand what your application does, what worries you, and what would actually hurt if it happened. We fix the exact perimeter, the domains in play, what is excluded, and the testing window. Testing agreement and NDA signed before any access.
Reconnaissance
Full mapping: subdomains, entry points, technologies, roles, data flows. The goal is to end up with a more complete map than your own team has, because an attacker does not stop at the pages in the menu.
Manual exploitation
The long part. I manipulate requests, swap identifiers, replay workflows out of order, authenticate as one role and act with another one's rights. Every hypothesis gets tested until it yields a proof or a certainty that it does not work.
Impact qualification
A flaw only matters through what it allows. For each finding I establish what an attacker would actually obtain, with a proof of concept reproducible step by step.
Report and debrief
A report prioritized by real severity, with business impact in plain language for your decision makers and concrete remediation for your developers. Then a live debrief with the team to answer questions.
Retest
Once your fixes ship, I 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.
What this looks like in practice.
Real findings, reported and fixed. Client identities and perimeters are never disclosed.
What it costs.
Quoted per engagement, and here is why: a flat published rate with no knowledge of the perimeter would be wrong in both directions. What moves the number:
The number of roles to test, first. Every extra role multiplies the access control combinations to verify, and that is where the most serious flaws hide. Then functional size: a brochure site with a contact form has nothing in common with a forty-screen business platform. Then the presence of an API, a checkout flow, SSO or third-party integrations, each of which adds its own surface. Finally the depth you want: a fast qualification pass, or deep research.
The first conversation carries no commitment and exists precisely to work this out. If your need is lighter than you thought, I will say so.
Common questions.
Can a pentest break my production site?
No. I work in read mode and with minimal proof of concept: I demonstrate that access is possible, I do not exploit it 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?
Strongly recommended. A grey-box test with one account per role finds far more access control flaws than a purely external test, because the most serious flaws sit 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 will never notice that an order ID in a URL lets one customer read another customer's order. Manual research exists for exactly that.
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.
The other services.
API security audit
If your business logic lives behind REST, JSON or GraphQL endpoints consumed by a front end or a mobile app, that is where to look.
Read moreWebsite security audit
If your perimeter is a brochure site, an online store or a CMS-based site rather than an application with several roles, that is the engagement you want.
Read moreGet your application tested.
Describe the perimeter: what the application does, how many roles it has, and what worries you. I come back with a scope and a quote. First conversation carries no commitment, full confidentiality.