Web application and API penetration testing

A web application is exposed to the whole Internet, all the time. I assess it from the point of view of a malicious user, with or without an account, to check that no customer can reach another customer’s data and that sensitive features are properly protected.

What I assess

Authentication: Login, password reset, MFA, SSO.
Access control: Separation between users, tenants and roles.
Business logic: Payments, quotas, approval workflows: what scanners do not understand.
Data handling: Input validation, file handling, information exposure.
APIs: REST and GraphQL, undocumented endpoints, rate limiting.
Configuration: Security headers, up-to-date components, secrets management.

How I work

Grey-box by default: you give me test accounts for each role. It is the best balance between depth and budget.
OWASP Web Security Testing Guide (WSTG) methodology, with a large share of manual testing.
Testing on staging when possible, production otherwise, with rules agreed in writing beforehand.

Full methodology and deliverable

What you get

A PDF report: executive summary, then one entry per vulnerability (proof, CVSS score, impact, fix).
A debrief meeting with your technical team.
A retest of your fixes, offered in the quote.

FAQ

Frequently asked questions

Should you test production or staging?

Staging is better if it mirrors production: testing does not touch real data. In production we agree in advance on what is off-limits.

Do you test mobile apps?

I assess the API behind the mobile app, which carries most of the risk. If in-depth analysis of the app itself is needed, I will tell you during scoping.

Is an automated scanner not enough?

A scanner finds generic, known issues. It does not understand your business, for instance that a customer must never see another customer’s invoices. That kind of flaw is often the most severe, and it is found by hand.

Another question? Send me a message