Application security testing

Most real findings come from understanding what an application is supposed to do, then asking what happens when a user does something else. These are the classes I work through, scoped to your stack and the roles your users actually have.

• A01 · ACCESS

  Broken access control

  IDOR, horizontal and vertical privilege escalation, and the endpoints that check who you are but never what you own — the most common serious bug in any application.

• A02 · IDENTITY

  Authentication & sessions

  Login, registration, password reset, MFA and token handling, tested for takeover paths — plus the session and JWT weaknesses behind them.

• A03 · LOGIC

  Business logic flaws

  Workflows driven out of order, prices and quantities tampered with, limits bypassed, race conditions on anything that touches money or state.

• A04 · INJECT

  Injection & SSRF

  SQL and NoSQL injection, command injection, SSTI, XSS, XXE and server-side request forgery into internal services and cloud metadata.

• A05 · API

  REST & GraphQL APIs

  Mass assignment, excessive data exposure, missing object-level authorization, and GraphQL introspection, aliasing and depth abuse — the layer mobile and SPA clients really run on.

• A06 · CODE

  Secure code review

  Targeted review of the code behind the risky paths — authorization middleware, input handling, crypto and third-party dependencies — where source access is available.

Mapped to the OWASP Top 10, the OWASP API Security Top 10, ASVS and the WSTG.

1. 01

   Scope & role mapping

   We agree the applications, the environments and every user role in play — multi-tenant boundaries and role separation are where the serious findings usually hide.

2. 02

   Recon & surface mapping

   Mapping the real attack surface: endpoints, parameters, client-side code, hidden routes and the APIs the front end quietly talks to.

3. 03

   Manual testing per class

   Hands-on testing against each class above, with authenticated sessions for every role. Automation supports it; it never replaces it.

4. 04

   Report with reproducible proof

   Each finding ships with impact, evidence and the exact steps to reproduce it, ranked by what it would actually cost you.

5. 05

   Fix support & retest

   I work through the fixes with your engineers — as someone who ships them too, not just reports them — then retest to confirm they hold.

• A risk-ranked report with evidence and reproducible steps for every finding
• Impact written in business terms, not just a CVSS score
• Concrete remediation guidance at code level, not generic advice
• A readout call with the engineers who will do the fixing
• A free retest once the fixes are in

• OWASP Top 10
• OWASP API Security Top 10
• OWASP ASVS
• OWASP WSTG

I'm a Certified AppSec Practitioner and have completed TCM Academy's Practical API Hacking, and I work as a software and application security engineer at Invygo — 50+ vulnerabilities closed while keeping its microservices architecture running. Alongside that, bug-bounty work since 2020 for companies including Apple, TrendMicro and JustLife, and published research on GraphQL introspection leaks and an SSRF-driven organization takeover.

What is application security testing?

A hands-on security assessment of an application and its APIs: access control, authentication, business logic, injection and data exposure. It goes deeper than a scanner, because the findings that matter usually depend on understanding what the application is meant to do and then abusing that logic.

How is this different from a penetration test?

A penetration test looks at the whole path in, including network and infrastructure. This is depth on the application itself — every role, every workflow, every endpoint — which is where most breaches of a modern SaaS product actually start. If you need both, I scope them together.

Do you need access to our source code?

No, black-box and authenticated grey-box testing both work. But if you can share source, the review gets sharper and cheaper: I can read the authorization middleware and input handling directly instead of inferring them from the outside.

Can you test multi-tenant SaaS applications?

Yes, and it's worth prioritising. Tenant isolation and object-level authorization are the flaws I find most often in multi-tenant products, so testing runs with several accounts across every role to prove where the boundaries hold and where they don't.

Will you help fix the findings, or just report them?

Both. I'm an engineer as well as a tester — at Invygo I close the vulnerabilities I find. Expect remediation guidance at code level, a walk-through with your team, and a retest once the fixes land.

Do you work with companies in Morocco?

Yes. I'm based in Morocco, available on-site across the country and remote for clients anywhere. Reporting can be delivered in English or French.