23 June 2026 Security Tips .

Types of pentest: a complete guide to choosing the right penetration test

Web, API, DNS, OSINT, cloud, mobile, subdomain takeover: this guide covers 18 types of penetration tests, what each approach actually tests, and how to choose based on your context.

11:02am. You're a CISO and you need to sign off on a new application going into production. Your client asks for one thing before signing: proof of a recent penetration test.

9:14am. You're a CEO. A vendor calls to ask if your website is secure, because they just noticed a subdomain behaving oddly. You say you'll launch an offensive audit to check.

4:40pm. You're a compliance manager. A regulatory control asks you to justify the last test date on your exposed perimeter. You realize the answer depends on what type of pentest you were delivered, and what it actually covered.

Three moments, three roles, the same underlying question: which type of pentest answers this specific situation?

In 2025, 97% of organizations suffered a breach linked to their supply chain or to an unmanaged asset (SecurityScorecard 2025). In most documented cases, the compromised asset wasn't in the scope of any previous pentest.

Key takeaways

  • There are 3 base methodologies: black-box (zero info), grey-box (partial info), white-box (full info)

  • Scope defines what gets tested: web, API, DNS, OSINT, cloud, network, mobile, social engineering, and more

  • For most organizations: start with the external perimeter (web, API, DNS, OSINT), continuously

  • A one-off pentest is obsolete the day after it's delivered: the attack surface keeps changing

  • Some scopes (deep cloud, DevOps, IoT) require initial access to go beyond exposure detection

What is a pentest?

A penetration test (pentest) is a controlled attack simulation carried out by information security experts to identify exploitable vulnerabilities in a system, application, or infrastructure. It's the digital equivalent of hiring a professional burglar to test your house: they try the windows, force the lock if needed, check whether the alarm goes off, and then hand you a report on what a real thief could have exploited. Running a penetration test lets you concretely validate how well your information system withstands a malicious attacker, rather than settling for a theoretical analysis.

"A pentest" doesn't really exist as a single thing. There are dozens, differing by methodology (what the tester knows going in), scope (which assets are tested), and depth (how far the exploitation goes). This guide covers the 3 base methodologies, 18 types of scope grouped into families, and a summary coverage table at the end of the article.

Black-box, grey-box, white-box: which pentest methodology should you choose?

The first distinction to master is methodology, also referred to as "boxes" (black box, grey box, white box) based on how much information is given to the tester before the test starts. Black box pentesting is the most widely used methodology for assessing the security of a system exposed on the internet.

Black-box: zero information provided

The tester has no prior information about the target: architecture, technologies, access. They operate exactly like an external attacker: starting from zero, with only a domain name or IP address as a starting point.

This is the methodology that gives the most realistic picture of your actual exposure. It also reveals assets you haven't declared in your inventory.

Ideal for: simulating a realistic external attack, testing internet exposure, validating external security posture, discovering unknown assets and hardening the perimeter accordingly.

Grey-box: partial information provided

The tester has partial information: standard user access, limited architecture documentation, or knowledge of certain technologies in use. Simulates an attacker with initial access: a malicious employee, a stolen credential, a compromised partner account.

Ideal for: application testing with authenticated access, simulating an insider threat (malicious or compromised employee), testing features reserved for logged-in users.

White-box: full information provided

The tester has all the information: source code, complete architecture, admin access, technical documentation. Allows maximum coverage, including vulnerabilities not visible from the outside.

Ideal for: code audits, architecture reviews, ISO 27001 compliance, PASSI audits (Prestataire d'Audit de la Sécurité des Systèmes d'Information, the French ANSSI qualification mandatory under certain French regulations).

ObjectiveRecommended methodologyWhy
Simulate a realistic external attack Black-box Reproduces an attacker's perspective with no prior information
Test an application with login Grey-box Covers authenticated features and privileges
Code audit before going to production White-box Exhaustive coverage of source code and architecture
NIS2/DORA compliance Grey-box + White-box Frameworks require documented coverage
Continuous validation of internet exposure Continuous black-box The attack surface keeps changing. Only continuous testing guarantees coverage

External pentest scopes: web applications, API, DNS, and OSINT

These four families cover what an attacker sees first: your public exposure on the internet, with no need for initial access.

Web application and website pentest: the most visible surface

Web pentesting tests the security of everything accessible through a browser: corporate site, business application, transactional platform. It's historically the most-tested scope in cybersecurity, and the one with the largest number of documented vulnerabilities.

Who's concerned: any organization with a corporate site, platform, or publicly accessible application. It's the most frequent target of opportunistic attacks.

Web pentesting comes in several depth levels. A test on a brochure or corporate website mainly targets OWASP Top 10 flaws (the list of the 10 most critical web vulnerabilities) and server misconfigurations: weak SSL/TLS, poor NGINX or Apache hardening. A test on a web application goes further: it targets business logic, authentication, and user interactions to assess resistance to injection and data-oriented attacks. A test on a web platform (e-commerce, SaaS, extranet) combines application, infrastructure, and APIs. Real actions are tested rather than a simple informational analysis, because these platforms handle critical data and transaction flows.

TypeVectors testedTechnical impactBusiness impact
Website OWASP Top 10, weak SSL/TLS, server config Server compromised, content defaced Site offline or defaced, publicly visible loss of credibility
Web application Injection, broken authentication, error handling Database accessed, user accounts hijacked Theft of customer data (emails, passwords, contact details), hijacked user accounts
Web platform Logic flaws, privilege escalation, session management Unauthorized access to admin functions, bypassed business controls Financial fraud, leaked payment or transaction data, loss of user trust

Tools and techniques: OWASP ZAP, Burp Suite, Nuclei for automated OWASP Top 10 detection. XSS (script injection), SQLi (SQL injection), CSRF (request forgery), LFI/RFI (malicious file inclusion), IDOR (unauthorized access via identifier manipulation), SSRF (forcing the server to make internal requests) are the most frequently tested vectors.

API pentest: the gateway of modern applications

API pentesting tests the programming interfaces that let applications communicate with each other, independently of any visual interface. An API can be attacked directly, without ever going through the website or application that uses it.

Who's concerned: any SaaS vendor, mobile app, or platform exposing functionality via REST, GraphQL, or SOAP APIs. That's nearly every modern digital service.

APIs expose functionality and data to mobile, web, and third-party applications. Tests target business logic, authentication, and resilience against abuse and brute-forcing (automated attempts to guess a password).

Vectors tested: Broken Authentication, absent rate limiting, injections, Broken Object Level Authorization (BOLA, accessing other users' resources by manipulating identifiers).

Technical impact: API taken offline (denial of service), full API takeover by a third party, access to other users' data without authorization.

Business impact: leaked personal or financial data belonging to your customers, service unavailable for all users during the incident, mandatory regulatory notification when personal data is involved.

DNS pentest: the first step before the website

DNS pentesting tests the resilience of the system that translates a domain name into a network address. It's a layer often overlooked in security audits, even though it gates access to every other service.

Who's concerned: any organization with a public domain name, which means essentially everyone.

In practice, this test assesses your name resolution infrastructure's resilience against attacks such as zone transfer (exposing the full list of subdomains), cache poisoning (corrupting cached DNS responses), and DNS hijacking. In an attacker's exploitation logic, DNS is often tested even before the website. It's the entry point that reveals a domain's full architecture.

Technical impact: traffic redirected to infrastructure controlled by the attacker, falsified DNS responses for every visitor.

Business impact: your customers redirected to a fake site that steals their credentials or payment data, intercepted emails, complete impersonation of your online presence during the incident.

Automated OSINT: what an attacker finds without touching you

OSINT testing covers what an attacker can learn about your organization without ever interacting with your systems, using only public sources. No connection, no request to your servers: everything happens from the outside, silently.

Who's concerned: any organization with a public presence, which in practice means every organization.

OSINT (Open Source Intelligence) is the automated collection of public information about a company and its assets, using tools like Shodan or Censys that continuously index services exposed on the internet.

What's found: exposed metadata, sensitive information in service banners, technologies in use, an org chart deducible from job postings.

Technical impact: a complete map of your infrastructure and technologies, available to prepare a later targeted attack.

Business impact: no direct or immediate damage, but it's the reconnaissance step that almost always precedes a more serious incident. OSINT alone breaks nothing: it prepares what's going to break something next.

Brand Protection, Shadow IT, and Subdomain Takeover

These three scopes target a common problem: what your organization exposes without knowing it or without controlling it.

Shadow IT Discovery: the inventory nobody did

Shadow IT discovery tests what your organization exposes on the internet without the security team or IT department knowing about it. It's less a classic penetration test than a mapping exercise, but the result directly feeds into the other types of external pentest.

Who's concerned: any organization with more than 50 internet-facing assets, autonomous dev teams, or a history of mergers and acquisitions.

Shadow IT discovery identifies uninventoried, publicly exposed external assets: subdomains created for a pilot project, SaaS services subscribed to without IT validation, public IP addresses never documented. This discovery relies on the same techniques as OSINT, specifically oriented toward exhaustive perimeter mapping.

Technical impact: unpatched, unmonitored assets, often with default configurations that were never hardened.

Business impact: a service nobody knew was exposed becomes the entry point of an incident, with no team in a position to detect it quickly, or even to know who owns the compromised asset.

Subdomain Takeover: the subdomain that's no longer really yours

Subdomain takeover testing identifies subdomains whose DNS entry still points to a third-party service that no longer exists. It's the digital equivalent of keeping a mailbox under your name after moving out: the new occupant can receive your mail, and nobody else notices. It's an attack vector that requires no technical flaw in the classic sense, just an administrative oversight.

Who's concerned: any organization that used a third-party service (CDN, hosting provider, SaaS platform) for a subdomain, then discontinued that service without removing the associated DNS entry.

A subdomain takeover happens when a subdomain points to a third-party service that no longer exists or is no longer configured. Concrete example: promo.mycompany.com used to point to an instance of a marketing email service discontinued a year ago. The DNS entry still exists. An attacker can create an account on that same service, claim the subdomain, and use it to host a phishing site under a domain name that looks perfectly legitimate.

Technical impact: the subdomain is fully controlled by a third party, with no classic technical flaw ever exploited.

Business impact: customers receive an email or visit a phishing page hosted under your own domain name, legitimately believing they're dealing with your company. It's one of the most underestimated vectors because it doesn't depend on any technical vulnerability, just a forgotten DNS entry.

Dark web monitoring and credential leaks

Dark web monitoring tests whether credentials linked to your organization are already circulating in leak databases or criminal marketplaces, independently of any vulnerability present in your own systems.

Who's concerned: every organization, particularly those with a history of third-party incidents or employees reusing passwords.

Dark web monitoring identifies credentials linked to your organization circulating in leak databases or criminal marketplaces, often originating from a breach at a third party entirely outside your IT system.

Technical impact: an attacker logs in directly with valid credentials, with no need to exploit any technical vulnerability.

Business impact: full access to an employee or customer account as if it were the legitimate owner, making the intrusion nearly undetectable until suspicious activity is noticed.

Network, infrastructure, and global information system pentest

Network pentesting tests the resilience of the infrastructure connecting your systems together: equipment, segmentation, filtering rules. It can cover only what's exposed on the internet, or extend to the entire information system.

Who's concerned: organizations with structured network infrastructure, multiple zones (DMZ, LAN, WAN), or the need for an overview of exposure across the whole IT system.

Network pentesting comes in two depth levels. Externally, it targets internet-exposed services: SSH versions, exposed SMB shares, FTP servers, non-standard ports, without touching the web application layer. Internally, it extends to Active Directory (the Windows identity management directory), internal servers, and network segmentation.

Global information system pentesting combines technical tests, process audits, and organizational tests to assess a company's entire IT system, including mapping domain names and their relationships, Shadow IT, and access management processes.

Pentest typeCoverageCondition
Website✓ YesRecurring automated external scans
Web application✓ YesAutomated OWASP Top 10 detection
Web platform◐ PartialExternal scans, no in-depth business logic testing
API✓ YesAutomated OWASP API Top 10 tests
DNS✓ YesAutomated tests on public configurations
Automated OSINT✓ YesVia integrated external tools (Censys, Shodan)
Shadow IT Discovery✓ YesAutomatic inventory via scanners and OSINT
Subdomain Takeover✓ YesAutomated detection
Dark Web / credential leaks◇ VariableDepends on specific integration
External network✓ YesPerimeter scans (ports, exposed services)
Internal network✕ NoRequires on-site intervention or dedicated VPN
Global IT system◐ PartialView limited to external exposure
Cloud (exposure detection)✓ YesPublicly exposed S3, Blob, Elasticsearch
Cloud (deep IAM audit)✕ NoRequires initial access (keys depending on permissions)
DevOps (exposure detection)◐ PartialDetection of publicly exposed assets
DevOps (pipeline audit)✕ NoRequires initial access found via another flaw
Internet-exposed IoT✓ YesExposed cameras, printers, industrial equipment
IoT (firmware, physical)✕ NoRequires a dedicated analysis
Social engineering✕ NoRequires human-led tests
Thick client✕ NoRequires dedicated analysis of local software
Mobile application✕ NoRequires binary analysis
Full red team✕ NoRequires a dedicated multi-vector scenario
Physical✕ NoRequires an on-site audit

For scopes marked "Yes" or "Partial" and automated, Patrowl provides continuous detection with human validation on critical findings. For scopes marked "No", a PASSI-qualified or specialized provider is recommended as a complement.

Validate your external attack surface continuously

Black-box · Zero false positives · First report in under 24h

Manual, automated, hybrid: three approaches to running a pentest

Beyond the scope tested, one last dimension determines the quality and frequency of your security tests: who or what runs the pentest.

The manual approach. A certified pentester (OSCP, OSWE, PASSI) runs the test entirely by hand, using their expertise and creativity to chain attack vectors the way a real attacker would. It's the approach that best detects complex logic flaws and exploitation chains nobody anticipated. Its limit: cost and time. A full manual audit takes several days, costs a lot, and captures a frozen state at a single point in time.

The automated approach. Automated tools continuously scan the perimeter, detecting known vulnerabilities, risky configurations, and exposed assets. It's fast, cheap at scale, and enables permanent monitoring that's impossible to sustain manually. Its limit: an automated tool on its own generates noise. It surfaces CVEs that aren't exploitable in the real context, and misses business logic flaws a human would spot in minutes.

The AI-augmented hybrid approach. This combines both: automated tools and AI models for continuous discovery, contextual prioritization, and real-time threat intelligence correlation, paired with systematic human validation by certified pentesters on every critical finding. Automation handles the volume, humans handle the judgment. This is what lets you have both the frequency of an automated tool and the reliability of a manual audit.

Patrowl brings exactly these three dimensions together. Continuous automated discovery and testing across the entire external perimeter, AI-driven enrichment for contextual prioritization and real-time threat intelligence, and systematic human validation by certified pentesters before any critical finding reaches your teams. All without ever sacrificing one for the other.

In conclusion

No single type of pentest covers everything, and that's precisely the most common trap: choosing one type of test and considering the matter settled. An annual web audit tells you nothing about your DNS exposure. An internal network test won't reveal an abandoned subdomain ready to be hijacked. An ISO certification obtained on a white-box scope doesn't guarantee the absence of a public S3 bucket left open for six months.

The right approach combines several types of security tests based on what's actually exposed, at a frequency matched to how fast your organization changes. For most organizations, that means continuous monitoring of everything visible from the internet (web, API, DNS, OSINT, exposed cloud), complemented by deeper one-off audits on internal systems, mobile, or organizational aspects depending on regulatory context and maturity level.

The coverage table above isn't a fixed list. It's a starting point to map what you're testing today, what's missing, and in what order to fill the gaps.

FAQ

What's the difference between a black-box, grey-box, and white-box pentest?

In black-box testing, the tester has no prior information. They operate like a real external attacker. In grey-box, they have partial information to simulate a malicious employee or an attacker with initial access. In white-box, they have everything: source code, admin access, technical documentation. Black-box gives the most realistic view of your external exposure.

What is a subdomain takeover?

A subdomain takeover happens when a subdomain points to a third-party service (CDN, hosting provider, SaaS) that no longer exists or is no longer configured. An attacker can then claim that third-party service and take control of the subdomain, using it for phishing or brand impersonation under a domain name that looks legitimate. It's one of the most underestimated vectors because it doesn't depend on any classic technical vulnerability.

What's the difference between a pentest and a security audit?

A security audit assesses compliance against frameworks without necessarily exploiting vulnerabilities. A pentest is an active attack simulation: the tester actually attempts to exploit the flaws. The two are complementary.

Should you start with an external or internal pentest?

For the vast majority of organizations, start with the external perimeter: web, API, DNS, OSINT. It's the scope most exposed to real attackers. Internal pentesting becomes a priority when there's a proven insider threat risk or a specific regulatory requirement.

Does automated pentesting replace all types of pentests?

No. It excellently covers the external attack surface: web, API, DNS, OSINT, exposed cloud, external network. It doesn't cover deep internal systems, mobile, social engineering, full red team exercises, or physical testing. The optimal architecture combines continuous automated pentesting for the external perimeter with a qualified provider for the rest.

What should a CISO check before choosing a pentest provider?

Pentester certifications (OSCP, OSWE, PASSI), a zero-false-positive process, the exact scope covered and excluded, data sovereignty, and continuity between two audits.

Sources : OWASP Top 10 et OWASP API Top 10 · ANSSI qualification PASSI · SecurityScorecard Global Third-Party Breach Report 2025 · NIS2 (UE 2022/2555) · DORA (UE 2022/2554) · OWASP Mobile Application Security (MAS)