Types of Penetration Testing: Web, API, Cloud and More

Modern attack surfaces rarely fit inside one perimeter. A SaaS product may expose a browser application, APIs, cloud identities, mobile clients, and connected devices, each with different trust boundaries and failure modes. Choosing the right test starts with identifying what you are evaluating and how much context the tester receives.

For most modern organizations, the web application is a useful place to begin because it often connects users, business logic, data, and downstream services. Its visible interface is only one perspective, however. The sections below explain what each target-specific test examines and how the results can inform a defensible testing plan.

Web Application Penetration Testing

Web application testing examines how an application behaves under realistic attempts to access data, functions, and administrative capabilities without authorization. Scope can include public-facing applications, authenticated customer portals, and administrative interfaces. Testing both anonymous and authenticated perspectives matters because a control that holds before login may fail once a user, support agent, or administrator has access.

The assessment can cover modern application architectures and the interfaces behind them, including REST, GraphQL, and SOAP APIs. Testers evaluate how identity, authorization, input handling, configuration, and application workflows interact. Common findings may include injection, broken authentication, insecure configuration, sensitive data exposure, insecure direct object references (IDOR), server-side request forgery (SSRF), and business-logic flaws. A business-logic issue, for example, may allow a valid feature to be used in an unintended sequence even when individual requests appear properly authenticated.

Scope should reflect how the application is used

A useful scope identifies user roles, sensitive workflows, integrations, API documentation, test accounts, and the environments that can be safely assessed. It should also distinguish what is publicly reachable from what requires authentication. This gives the testing team enough context to examine privilege boundaries without treating every endpoint as an isolated technical check.

For teams evaluating the web application penetration testing among the types of penetration testing, the key question is whether the selected scope represents the application's real attack surface. AI-assisted testing can help broaden coverage, while human validation is important for confirming exploitability, business impact, and remediation priorities.

API Penetration Testing Finds What App Testing Can Miss

A visible application is only one client of the systems behind it. An API may expose the same business logic to web applications, mobile apps, integrations, and automated workflows, each with different authentication and authorization paths. Testing the interface alone can miss weaknesses that appear only when requests are modified or sent directly to an endpoint.

One priority is broken object-level authorization. A tester changes an object identifier, such as an account, invoice, or user ID, to determine whether the server verifies ownership instead of trusting the request. Excessive data exposure is another concern: an endpoint may return fields that the client does not display. Including internal attributes or information belonging to a broader record than the user needs.

API testing also involves discovering the attack surface. Testers review documentation, traffic, schemas, versioning, and error behavior, then probe expected and less obvious endpoints. Fuzzing can reveal undocumented parameters, weak input validation, inconsistent authentication, and differences between legacy and current versions. The scope may include REST, GraphQL, and SOAP/XML services, because each technology introduces distinct request structures and failure modes.

The OWASP API Security Top 10 provides a useful reference for organizing API risk, but it is not a substitute for engagement-specific scoping or human analysis. A practical assessment connects technical findings to trust boundaries, affected workflows, and remediation priorities. Teams evaluating API penetration testing should identify every production API, supported client, authentication method, and test environment before work begins. No single test can promise complete coverage, but focused API testing can expose authorization and data-handling failures that application-level testing may not reach.

Network Penetration Testing: External and Internal Scope

Network penetration testing examines how an attacker could enter an environment, move through it, and reach sensitive systems. The right scope depends on the trust boundaries you need to evaluate, the access assumptions for the exercise, and the authorization granted to the testing team.

External testing takes an internet-facing perspective. It is useful for understanding what an unauthenticated attacker can discover and exploit from outside the organization. Typical external scope includes:

• Perimeter exposure and internet-facing services
• VPN gateways and remote-access controls
• Firewalls and exposed management interfaces
• Network segmentation and boundary enforcement
• DMZs and systems hosted in semi-trusted zones
• Publicly reachable services and their configurations

Internal testing starts with a different assumption, such as a compromised endpoint, a low-privilege account, or an authorized foothold. The objective is to determine how far that access could go and which controls limit impact. Common internal scope includes:

• Privilege escalation on workstations or servers
• Active Directory and domain security
• Credential attacks and authentication weaknesses
• Lateral movement between systems and segments
• Post-exploitation access to sensitive assets

External and internal tests are complementary, not interchangeable. A perimeter may resist direct intrusion while an overprivileged account enables broad internal access. Scope should define permitted targets, test windows, credentials, prohibited techniques, data-handling rules, and escalation contacts before testing begins. Clear authorization protects the business and gives the testers enough context to produce evidence that security and compliance teams can act on.

Cloud Penetration Testing and Shared Responsibility

Cloud penetration testing examines how an organization's cloud configuration, identities, workloads, and trust boundaries behave under attack. The shared responsibility model makes this distinct from a traditional perimeter test: the provider secures parts of the underlying platform. While the customer remains responsible for its accounts, permissions, data, applications, and configuration. Scope and provider rules must be confirmed before testing. For example, AWS testing requires planning around which user-operated services may be assessed, as outlined by the CISA NICCS guidance on AWS penetration testing.

A well-scoped engagement can cover AWS, Azure, or GCP environments, including:

• Identity and access: IAM policies, role trust relationships, excessive permissions, privilege escalation paths, and cross-account access.
• Network controls: security groups, routing, segmentation, exposed services, and paths between accounts, subscriptions, projects, and workloads.
• Data and storage: storage permissions, public exposure, weak access controls, and secrets or sensitive data reachable from compromised resources.
• Service configuration: cloud-service misconfiguration, insecure defaults, overly broad trust policies, and metadata exposure that could disclose credentials or instance details.
• Containers and orchestration: Kubernetes control-plane exposure, workload isolation, service-account permissions, and escalation from a container into broader cloud resources.

The objective is not simply to find an open bucket or permissive rule. Testers connect individual weaknesses into realistic attack paths, then provide evidence that helps owners prioritize remediation. That evidence can support risk management and compliance discussions, but a penetration test is not a compliance guarantee and does not prove that every cloud control is effective. See Penti's cloud penetration testing service for a cloud-focused scope that accounts for these ownership boundaries.

Mobile Penetration Testing for iOS and Android

Mobile testing examines more than the screens and workflows a user can access. It evaluates how an iOS or Android application stores data, protects secrets, communicates with backend services, and behaves when an attacker controls or alters the runtime environment. That makes it a distinct scope within the broader mobile application testing landscape, rather than a smaller version of web testing.

Assessors review local storage for credentials, tokens, personal information, and other sensitive data that may be exposed through files, databases, logs, backups, or debugging artifacts. They also examine whether encryption is implemented correctly, including key handling and the protection of data in transit and at rest. Weaknesses in these areas can remain invisible during a conventional browser-based assessment.

Testing the app, device, and mobile API

Mobile applications depend heavily on APIs, so the engagement should trace requests between the app and its services. However, the mobile scope also includes controls specific to the device and operating system. Testing may assess certificate pinning, interprocess communication (IPC), exported components, permissions, and interactions with other applications. Runtime manipulation helps determine whether an attacker can bypass client-side controls, alter application behavior, extract secrets, or reach functionality that should remain protected.

The difference from web and API testing is the trust boundary. Web testing emphasizes server-side behavior through browser interactions, while API testing focuses on endpoints, authorization, and data handling. Mobile testing adds the shipped client, its local environment, platform permissions, and the possibility that the client itself has been instrumented or modified. A complete assessment therefore connects mobile findings to the app's APIs without treating either scope as a substitute for the other.

IoT Penetration Testing Requires Device-Specific Scope

Connected devices and embedded systems introduce attack paths that conventional application or network testing may not fully represent. A scoped assessment can examine firmware, exposed debug or administrative interfaces, hard-coded or weak credentials. Device identity, update mechanisms, and the way a device communicates with cloud services, mobile applications, and local networks.

Network placement matters as much as the device itself. Testing may need to evaluate whether a device is isolated, what it can reach after compromise. And whether data flows expose sensitive information or create a path into a broader environment. Firmware analysis can also reveal insecure storage, unsafe defaults, outdated components, or update packages that lack adequate integrity protections. These questions should be tied to the device's actual architecture and operating context rather than assumed from its product category.

Safety and authorization are part of the test plan

IoT testing can affect physical processes, availability, patient care, or other safety-sensitive operations. Before testing begins, the engagement should define the exact device models, ownership, firmware versions. Connected services, approved test methods, authorization boundaries, test windows, rollback procedures, and safe handling requirements. Production devices may require non-disruptive techniques or a representative lab environment instead.

Penti's knowledge base supports specialized healthcare security work that can include medical IT and IoT devices, but it does not establish universal testing of every IoT device. Whether a particular device or environment is appropriate for assessment is engagement-specific and should be confirmed before work starts.

How Do You Choose the Right Penetration Test Type?

The most useful choice among the types of penetration testing starts with the system you need to defend, not with a familiar test label. Use this decision framework to match scope to risk and evidence requirements.

1. Map the assets and trust boundaries. Start with what is exposed and how users, services, and administrators interact with it. An external application, authenticated portal, API, cloud account, mobile app, corporate network, or connected device may require a different testing scope. If the inventory is incomplete, begin with attack surface discovery across cloud and on-prem environments before finalizing the engagement.
2. Identify the attack paths that matter most. Define what a realistic adversary could reach and what compromise would affect the business. A red-team engagement can combine web, API, mobile, network, cloud, and social-engineering scenarios into one adversarial campaign. That broader approach is useful when the risk depends on chained weaknesses across multiple boundaries, rather than one isolated asset.
3. Choose the required level of access and knowledge. Anonymous testing shows what an unauthenticated attacker can discover. Authenticated testing examines user and administrative privileges. A scoped manual test can then explore business logic, privilege escalation, and attack chains that require judgment. Automated AI testing can expand coverage and speed discovery, while human-verified findings add expert validation. Review AI penetration testing and human validation when you need both approaches represented clearly.
4. Define the evidence and remediation outcome. If the goal is continuous visibility, automated testing may be appropriate. If the goal is defensible findings for a release, customer review, or risk decision, require human verification and clear reproduction evidence. Confirm authorization, device models, safety constraints, and environment boundaries for specialized scopes such as IoT. Finally, map the deliverable to the relevant internal risk process or framework. Testing can support readiness and evidence, but it does not by itself guarantee security or compliance.

Frequently Asked Questions

What are the main types of penetration testing?

The main types are organized by the attack surface under review: web applications, APIs, networks, cloud environments, mobile applications, and IoT devices. Teams may also choose an approach based on tester knowledge, such as black-box, gray-box, or white-box testing. A red-team engagement can combine several target types to evaluate a broader attack path.

How many types of penetration testing does an organization need?

There is no universal number. Start with the systems that process sensitive data, enforce trust boundaries, or expose services to users and partners. A SaaS company may prioritize web application, API, cloud, and external network testing, while a device manufacturer may also need firmware, interface, update-path, and safety-focused IoT testing.

What is the difference between network, web application, and API testing?

Network testing evaluates infrastructure such as firewalls, VPNs, segmentation, Active Directory, and exposed services. Web application testing examines user-facing application behavior, authentication, authorization, business logic, and common application flaws. API testing focuses on programmatic endpoints, including object-level authorization, endpoint discovery, data exposure, and GraphQL or SOAP-specific risks.

Is one penetration test enough to secure an organization?

No. A test is a point-in-time assessment of a defined scope, not a guarantee of security or compliance. Coverage should reflect meaningful changes in applications, APIs, cloud permissions, infrastructure, and connected devices. Retesting after remediation and combining automated discovery with human validation can provide more useful evidence than relying on a single narrow engagement.

Is penetration testing illegal without permission?

Testing systems without explicit authorization can create legal and operational risk. The engagement should define approved assets, methods, timing, data handling, safety limits, and contacts before testing begins. For IoT or production environments, device models and update paths should also be confirmed so the work remains controlled and safe.

Ready to Review Your Attack Surface?

Understanding the types of penetration testing helps your team align testing scope with the systems, trust boundaries, and evidence requirements that matter most. Review your attack surface and explore Penti's AI-enabled penetration testing with human validation to identify an approach that fits your environment. Contact us to get started and discuss where focused testing can support your security program.