The phrase "types of penetration testing" is used for two unrelated distinctions. The first is how much information the tester starts with: black box, grey box, or white box. The second is what they are aimed at: a web application, an API, a network, a mobile app, or your staff. You pick one from each list, and confusing the two is a common way to buy the wrong test.
By knowledge: black, grey, white
Black box. The tester starts with what an outside attacker would have: a domain name, maybe a login page. No credentials, no documentation, no source code. It simulates an unauthenticated stranger and it is the most realistic starting point for one specific threat.
Grey box. The tester gets partial information - working credentials for each user role, an architecture overview, sometimes API documentation. It simulates an attacker who has already gained a foothold, or an ordinary user probing for more access than they should have.
White box. Full visibility, including source code and configuration. Nothing is hidden, and the test focuses entirely on finding flaws rather than discovering the shape of the system.
| Starts with | Simulates | Best at finding | |
|---|---|---|---|
| Black box | Public information only | An external stranger | Exposure at the perimeter |
| Grey box | Credentials and architecture | A user or a foothold | Authorisation and logic flaws |
| White box | Everything, including source | An informed reviewer | Depth and completeness |
Why grey box is usually the right answer
Full black box has an intuitive appeal - it feels like the honest test. In practice it spends a meaningful share of the budget rediscovering things you already know and could have simply handed over.
It also structurally under-tests the most common serious flaw. Broken authorisation only appears when you have at least two accounts and can try to reach one from the other. Without credentials, most of that surface is invisible. If you buy a black box test and receive a clean report, one plausible explanation is that the interesting part was never reachable.
A useful rule: withhold information to test your perimeter, and provide it to test your application. Most teams need the second and buy the first.
By target
Web application testing covers the browser-facing application: authentication, session handling, authorisation between users and tenants, injection, and business logic. The detail of scoping that against a published standard is in OWASP ASVS testing.
API testing covers the interfaces behind and beside it. It matters increasingly more than the web layer, because an API frequently exposes operations the user interface never offers, and object-level authorisation is where a great many real breaches now happen.
Network and infrastructure testing covers hosts, services, segmentation and configuration rather than application logic. Different discipline, different tooling.
Mobile testing covers the application on the device plus everything it talks to.
Social engineering targets people rather than systems - phishing, pretexting, and physical access where that is in scope.
Where we deliberately do not play
Worth stating plainly, because it affects which of the above we are the right answer for: Intrudify is scoped to web applications and APIs. We are not a network scanner, not an infrastructure product, and not a social engineering service. That boundary is on our services page rather than buried in a footnote, because a vendor who claims every category is telling you something about their depth in each one.
If your immediate need is network or physical, you want a different provider for that piece. If it is the application and the API, that is the whole of what we build.