Security & Compliance
Types of Penetration Testing: A Guide
Every type of penetration test explained — network, web, mobile, API, cloud, wireless and social engineering — plus black, grey and white box methods and when to use each.
'Penetration testing' is not one service. Asking a provider for 'a pen test' without specifying the type is how organisations end up paying for a scan of their website when their real risk was in Active Directory. Here is the full map: what each type actually tests, the trigger that should make you commission it, and what it costs.
By target
Types of penetration testing by what is tested
There are eight commonly commissioned types of penetration test, defined by the target: external network, internal network, web application, API, mobile application, cloud configuration, wireless, and social engineering (with physical testing as its close cousin). Whatever the target, a professional engagement follows the same lifecycle — scoping through remediation retest — described in our 8-phase penetration testing process guide. The table gives you the map; the sections after it tell you when each type is the right call.
Penetration test types at a glance
| Type | What it tests | Typical trigger | Indicative pricing (India) |
|---|---|---|---|
| External network | Perimeter: firewalls, VPN gateways, exposed services | Internet-facing estate never tested; annual compliance cycle | Part of a combined network + web VAPT at ₹5–15 lakh (USD 6,000–18,000) |
| Internal network | Active Directory, lateral movement, privilege escalation | Phishing incident; PCI DSS internal scope | Part of the same combined ₹5–15 lakh (USD 6,000–18,000) engagement |
| Web application | Authentication, access control, injection, business logic | New launch or major release; payments or PII in the browser | ₹1.5–4 lakh (USD 2,000–5,000) for a focused test |
| API | BOLA/BFLA authorisation flaws, rate limiting, data exposure | API-first product; partner or public API launch | Varies — often bundled with the web or cloud scope |
| Mobile application | On-device storage, pinning, permissions, plus backend APIs | Customer-facing app launch or major release | Varies — scoped per platform |
| Cloud configuration | IAM policies, storage exposure, security groups, secrets | Cloud migration; multi-team account sprawl | Varies with account and workload count |
| Wireless | Wi-Fi encryption and authentication, rogue APs, guest isolation | Offices, warehouses or retail sites with local networks | Varies — priced per site |
| Social engineering / physical | Phishing, pretexting, tailgating, badge cloning | Mature technical controls; recent phishing incident | Varies — per campaign and head count |
Network penetration testing
Network testing targets the infrastructure layer: routers, switches, firewalls, VPN gateways, servers, workstations and — on internal engagements — Active Directory. The external scope validates the perimeter an internet attacker sees: exposed services, unpatched CVEs, weak VPN authentication. The internal scope measures how far a foothold travels once inside: lateral movement, privilege escalation, Kerberoastable service accounts and over-permissive file shares. Pick it when you run on-premise or hybrid infrastructure, own a public IP range, or a framework such as PCI DSS Requirement 11.4 demands it. Our step-by-step network penetration testing walkthrough covers the full methodology.
Web application penetration testing
Web application testing probes authentication, session management, access control, injection and business logic against the vulnerability classes catalogued in the OWASP Top 10. Automated scanners cover the known-vulnerability layer; the value of the engagement is manual logic work — IDOR, privilege escalation between user roles, workflow bypasses and price manipulation that no tool flags. Pick it when you have launched or significantly changed a customer-facing application, take payments or handle PII through a browser, or an auditor asks for application-layer evidence. Our web application penetration testing checklist shows exactly what a thorough test covers.
API penetration testing
API testing treats your REST or GraphQL surface as the primary target rather than an afterthought behind the web front end. The critical classes are authorisation flaws — broken object-level authorisation (BOLA) and broken function-level authorisation (BFLA) — plus missing rate limiting, excessive data exposure and weak token handling. Pick it when you are API-first, expose partner or public APIs, or your web and mobile clients share one API layer that has never been tested in its own right. If your mobile app has been tested but its APIs have not, you have tested the wrapper and not the product.
Mobile application penetration testing
Mobile testing covers the Android or iOS app itself — local data storage, certificate pinning, reverse-engineering resistance, platform permission abuse — and always the backend APIs the app calls, which is where most exploitable findings actually live. The OWASP Mobile Application Security project (MASVS and MASTG) defines the standard test criteria. Pick it when you ship a customer-facing app, store anything sensitive on the device, or your app talks to APIs no other scope covers. Scope each platform separately: a clean Android result does not prove the iOS build is clean.
Cloud penetration testing
Cloud testing focuses on the configuration layer: IAM policies and privilege-escalation paths, public storage buckets, security-group rules, exposed metadata endpoints, secrets committed to code and over-permissive service roles. It is misconfiguration hunting more than exploit development, because under the shared-responsibility model the provider secures the infrastructure and you secure everything you build on it. Pick it when you are cloud-native or mid-migration, after a period of account sprawl, or when multiple teams create resources without central review. Check your provider's penetration testing policy during scoping — AWS, Azure and GCP each publish one, and some techniques need advance notice.
Wireless penetration testing
Wireless testing examines Wi-Fi encryption and authentication (WPA2/WPA3, enterprise versus pre-shared key), rogue and evil-twin access points, guest network isolation, and how far your signal — and therefore your attack surface — extends beyond your walls. Pick it when you run offices, warehouses or retail sites where staff and visitors join local networks, or when a flat Wi-Fi network bridges directly into the corporate LAN. It is usually a short, per-site engagement and pairs naturally with internal network testing, because a breached access point is simply another internal foothold.
External vs internal testing
External testing simulates an attacker on the internet with no prior access; it validates your perimeter. Internal testing assumes an attacker already has a foothold — a phished employee, a compromised contractor — and measures how far they could move. Most compliance frameworks, including PCI DSS Requirement 11.4, require both scopes.
By method
Black box, grey box and white box
- Black box — the tester gets no prior knowledge, exactly like an outside attacker. Most realistic, but time is spent on discovery rather than depth.
- Grey box — the tester gets limited knowledge, typically user-level credentials. Simulates a compromised employee and is the most common engagement type because it balances realism and coverage.
- White box — the tester gets full architecture, credentials and sometimes source code. Maximum coverage per rupee spent; ideal before a product launch.
Which type do you actually need?
- You have internet-facing servers and have never tested — start with external network testing.
- You just launched or majorly changed a web app — web application testing, grey box.
- You handle payments — PCI DSS requires both internal and external network testing annually, plus quarterly scans.
- You had a phishing incident — internal network testing, to see how far that foothold could have gone.
- You are cloud-native with no on-prem estate — cloud configuration plus API testing beats classic network testing.
- You built a mobile app — mobile application testing, and make sure the APIs behind it are in scope too.
What each type typically costs
In India, a focused web application penetration test typically costs ₹1.5–4 lakh (USD 2,000–5,000). A combined network + web application VAPT for a mid-size environment runs ₹5–15 lakh (USD 6,000–18,000), and large multi-scope programmes covering cloud, API and mobile go beyond ₹25 lakh (USD 30,000+). US/EU-market engagements for comparable scope typically price two to three times higher. The final number depends on scope, asset count and whether a remediation retest is included.
For reference, published US/EU-market rates for individual scopes typically run: external network USD 3,000–15,000, internal network USD 8,000–30,000 (Active Directory complexity drives the spread), web application USD 5,000–25,000, and mobile USD 5,000–20,000 per platform. Cloud configuration reviews vary widely with account and workload count, and social engineering is usually priced per campaign and per head tested.
Whichever type you commission, make the quote state whether a remediation retest is included. The engagement is not finished until fixes are verified, and a retest-excluded quote is not comparable with a retest-included one.
Infronest
Conclusion
Whichever types you commission, the operational load is the same: scoping documents, findings, CVSS scores, evidence, reports and retests — multiplied by every engagement and every client. Infronest's Security and VAPT module keeps all of it in one tenant-isolated workspace with audit-ready reporting.
Start a 14-day free trial at infronest.com — no credit card required.
Sources
The methodology references in this article come from the following published standards. We cite them so you can verify the claims rather than take them on trust.
Frequently Asked Questions
- What are the main types of penetration testing?
- By target: network (external and internal), web application, mobile application, API, cloud, wireless, social engineering and physical. By method: black box (no knowledge), grey box (limited knowledge) and white box (full knowledge). Most organisations combine two or three target types per year rather than buying all of them.
- Which type of penetration test is most common?
- Grey-box web application testing and external network testing are the two most commonly commissioned, because web apps are the most exploited attack surface and the external perimeter is what any internet attacker reaches first.
- How many types of penetration testing do I need?
- Test what you actually run. A SaaS company usually needs web application, API and cloud testing. A company with on-premise infrastructure needs external and internal network testing. Compliance frameworks such as PCI DSS specify the minimum scopes you must cover.
- How much does a penetration test cost in India?
- In India, a focused web application penetration test typically costs ₹1.5–4 lakh (USD 2,000–5,000). A combined network + web application VAPT for a mid-size environment runs ₹5–15 lakh (USD 6,000–18,000), and large multi-scope programmes covering cloud, API and mobile go beyond ₹25 lakh (USD 30,000+). US/EU-market engagements for comparable scope typically price two to three times higher. The final number depends on scope, asset count and whether a remediation retest is included.
- What is the difference between black box, grey box and white box penetration testing?
- The difference is how much the tester knows in advance. Black box gives no prior knowledge and is the most realistic simulation of an outside attacker, but spends budget on discovery. Grey box gives limited knowledge such as user credentials, simulating a compromised employee — the most common choice because it balances realism and coverage. White box gives full architecture and credentials, buying maximum coverage per hour; use it before a product launch.
- Does a cloud environment need penetration testing if AWS or Azure secures the infrastructure?
- Yes. Under the shared-responsibility model, the provider secures the underlying infrastructure but you are responsible for everything you configure on it — IAM policies, storage permissions, security groups, secrets and workload hardening, which is where cloud breaches typically originate. Cloud penetration testing targets exactly that configuration layer. Check the provider's published testing policy before the engagement starts.
Social engineering and physical testing
Social engineering targets people instead of systems: phishing campaigns measured by click, credential-entry and reporting rates, voice pretexting, and baiting scenarios. Physical testing attempts tailgating, badge cloning and access to server rooms or unattended workstations. Pick them when your technical controls have matured and people are now the likely first foothold, or after a real phishing incident exposes the gap. Define the boundaries in writing — which staff groups, which premises, what is off-limits — because these are the engagement types where consent and scope matter most.