If you are exploring this career path, also read a cybersecurity and OSINT roadmap for beginners. For product teams, see why startups need early product security and API audits.
People search for “types of penetration testing” in two common situations. Either they want to enter cybersecurity and understand what ethical hackers actually do. Or a company has grown past “we think we are fine” and now needs to pick a real assessment format.
The market often sells pentesting as magic: “we run a scanner and you are protected.” In reality, types of penetration testing differ a lot in depth, cost, timeline, and business value. Below is a clear map: what the types are, how they differ, and which format a product actually needs.
1. What penetration testing is — and is not
Penetration testing is an authorized security assessment where a team tries to find and exploit vulnerabilities the way an attacker would. The goal is not “click every scanner button.” The goal is to answer practical questions:
- Can someone access another user’s data?
- Can authorization be bypassed?
- Can privileges be escalated?
- How bad is the damage if the issue is exploited?
- What should be fixed first?
A pentest is not:
- an automated vulnerability scan with no manual validation;
- a certificate that “you are safe forever”;
- a replacement for secure development and code review;
- a one-time ritual just for a compliance checkbox.
A good pentest produces reproducible findings, clear business risk, and a fix plan. A weak one produces an 80-page PDF full of false positives and no context.
One more nuance: a pentest is always limited by time and rules of engagement. The team is not required to find “every vulnerability in the universe.” It must efficiently test the agreed scope and demonstrate real attack paths. That is why choosing a pentest type is really choosing focus: what do you need to learn within a given budget and timeline?
2. Types by knowledge level: black, gray, white box
This is the most common classification. It answers one question: how much information does the team get before the work starts.
Black box — like an external attacker
The team knows almost nothing about the system: no source code, no network diagrams, often no internal accounts. They only see what is exposed: the website, API, forms, and public endpoints.
Pros: closest to a real external attack. Useful for checking “what does the internet see?”
Cons: some deep issues may be missed within a short engagement. Without architecture context, it takes longer to reach critical areas.
Best for: external perimeter checks, public products, validating exposure to opportunistic attackers.
Gray box — usually the best practical format
The team gets partial access: test accounts with different roles, API docs, sometimes architecture notes. Not fully blind, but not full code access either.
Gray box often gives the best balance of cost and value. Why? Real attackers are not always pure black-box either. They may have a customer account, partner access, leaked docs, or an old token.
Best for: SaaS products, user cabinets, multi-role systems, APIs with access control.
White box — maximum depth
The team gets source code, diagrams, credentials, and sometimes direct access to developers. This is closer to security code review plus pentesting.
Pros: higher chance of finding complex logic bugs, unsafe patterns, hidden endpoints, and server-side flaws.
Cons: more expensive and requires maturity: the company must share access and artifacts safely.
Best for: fintech, healthcare, critical platform cores, serious investor/customer due diligence.
3. External vs internal penetration testing
External pentest
Testing from outside: what is exposed to the internet, how public services are protected, and whether those services can lead to sensitive data.
Typical targets: corporate websites, customer portals, public APIs, VPN gateways, mail and admin panels.
Internal pentest
Testing from inside the perimeter: what happens if an attacker is already in — via phishing, a contractor, a stolen laptop, or a compromised employee.
Common findings include weak passwords, excessive privileges, poor segmentation, lateral movement, and access to critical systems.
For a startup with one web product, external web/API testing usually comes first. For a company with office infrastructure and Active Directory, internal testing matters too.
In practice, companies often make this mistake: they buy only an external “perimeter scan,” while the main risk already sits inside the product — in roles, APIs, and business logic. If your core asset is user data in a SaaS, start with authorization, not open ports.
4. Types by attack target
This is the second major axis. Even an excellent black-box engagement is useless if you test the wrong surface — the one that does not hold your money or your data.
1) Web application penetration testing
The classic track: websites, dashboards, admin panels, forms, sessions, cookies, XSS, CSRF, file upload, IDOR, and broken access control.
Most common checks:
- access to other users’ objects by ID;
- XSS in forms, search, profiles, and comments;
- weak sessions and missing cookie flags;
- dangerous file uploads;
- role bypass (user → admin).
If your product is a web SaaS, this type almost always sits at the top of the priority list. For business risk around XSS and BOLA, see OWASP Top 10:2025.
2) API penetration testing (REST / GraphQL)
One of the most underestimated and most valuable formats. Modern products live on APIs. The UI can look polished while a direct endpoint request exposes another user’s order, profile, or payment object.
API pentest focus areas:
- BOLA / IDOR;
- broken authentication;
- mass assignment;
- excessive data exposure;
- missing rate limiting;
- business-logic flaws in bulk operations.
This is the area I recommend most often to startups and product teams. UI bugs are annoying. API bugs are money, data, and reputation.
Another benefit of API pentesting: it connects well to team training. After the assessment, you can immediately show developers and QA what typical BOLA/IDOR looks like, where ownership logic breaks, and which negative checks should enter pre-release regression.
3) Network penetration testing
Infrastructure testing: hosts, services, open ports, outdated software, weak configs, and segmentation.
Useful for companies with their own infrastructure, VPN, and internal servers. Less urgent for a pure SaaS on managed cloud with a small network footprint.
4) Mobile penetration testing
iOS/Android apps: token storage, insecure local storage, SSL pinning bypasses, API calls from the app, local data, and deep links.
Important nuance: the real vulnerability is often not “the app button,” but the same backend API the mobile client uses. Mobile testing without API review is usually incomplete.
5) Cloud penetration testing
AWS/GCP/Azure and similar: IAM, public buckets, bad policies, secrets, metadata services, and over-privileged service roles.
If the product “runs in the cloud” but access is handed out chaotically, cloud misconfiguration can be more dangerous than the application itself.
6) Wireless / Wi-Fi testing
Attacks against office wireless networks: weak protocols, guest access issues, rogue APs. Relevant for companies with physical offices and corporate Wi-Fi.
7) Social engineering
Phishing, vishing, pretexting — testing people and processes, not only code. Humans are often the real entry point.
This format is sensitive: it needs clear rules, approvals, ethical boundaries, and a communication plan with employees after the test.
8) Red teaming
Not “find the maximum number of CVEs,” but test whether the company can detect and stop an end-to-end attack. Red teaming is closer to an APT-style campaign than a short classic pentest.
This is a mature-stage activity. For a company without basic AppSec and logging, red teaming is usually too early and too expensive.
5. How businesses should choose a pentest type
Do not start with “which pentest sounds the coolest.” Start with “where would a breach hurt us most.”
A practical matrix:
- SaaS / user cabinet / payments → gray box web + API.
- Public marketing site without complex logic → black/gray box web.
- Mobile app → mobile + backend API.
- Corporate infrastructure → external + internal network.
- Strong compliance / fintech → white box / deeper AppSec + API.
- People and process risk → social engineering (separately and carefully).
One more criterion matters: readiness to remediate. A pentest without time reserved for fixes becomes a pretty report in a drawer. Before kickoff, agree on:
- who owns triage;
- SLA for critical findings;
- whether there will be a retest after fixes;
- which environments can be touched (staging / restricted production).
6. What a good pentest report must include
Do not buy a “magic PDF.” Demand a working artifact. A solid report usually includes:
- a short executive summary for business stakeholders;
- findings with severity;
- reproduction steps;
- evidence (screenshots, requests, responses);
- business impact in plain language;
- fix recommendations;
- priorities: fix today, fix this sprint, put in backlog.
If there is no reproduction path, the report is almost useless. If everything is marked critical, that is also a smell. A good pentester separates noise from real threat.
7. Pentest vs vulnerability scan vs bug bounty
Vulnerability scan
Automated checks against known signatures. Fast and cheap. Useful as regular hygiene. It does not replace a pentest because it is weak against business logic and multi-step chains.
Penetration test
Manual plus tooling work aimed at exploitation and real-risk assessment. Deeper, more expensive, and more useful before major releases and due diligence.
Bug bounty
A continuous flow of external researchers paid for valid findings. A great maturity layer, but a poor starting point. Without triage and fix processes, bounty programs turn into chaos.
A healthy product sequence: basic AppSec → focused web/API pentest → recurring checks → bug bounty when the team is ready.
What beginners and businesses should remember
If you are learning to become a pentester: do not try to “know every type” at once. Pick one strong track first — usually web + API. Learn to find XSS, IDOR/BOLA, auth bypasses, write reports, and explain risk. That gets you hired faster than shallow familiarity with ten domains.
If you run a business: do not order “everything at once.” Order the assessment that matches your real attack surface. For most digital companies, that is web/API with roles. Network, cloud, mobile, and red team come next based on results and maturity.
And one blunt truth: the most expensive pentest is the one nobody remediates afterward. Value is not in the service name. Value is in closed risk.
8. FAQ
How long does a pentest take?
Usually from a few days to a few weeks. A focused web/API engagement for a small product is often 5–10 business days. Large white-box or red-team work takes longer.
Can you pentest production?
Sometimes yes, but only with hard limits, a maintenance window, and stop rules. It is safer to start with staging that closely mirrors production.
How often do you need a pentest?
At minimum after major architecture or authorization changes and before serious external reviews. For an active product, every 6–12 months plus targeted checks around critical releases is a sensible rhythm.
How is a pentest different from an AppSec audit?
A pentest focuses more on exploitation here and now. An AppSec audit is broader: processes, code, CI/CD, threat modeling, team practices. They are often combined.
Conclusion
Types of penetration testing are not buzzwords for a sales deck. They are different tools for different risks. Black box shows the outside view. White box goes deeper. Web and API cover the most common pain for digital products. Network, cloud, mobile, and social engineering matter when those surfaces actually exist.
If you need one practical starting point for most companies: a gray-box web application and REST API pentest focused on authorization, BOLA/IDOR, XSS, and business logic. Then expand based on findings and maturity.
In short: do not buy “a pentest in general.” Buy an answer to a concrete question. For example: “Can a regular user pull another user’s data through the API?” or “Can a guest role reach admin actions?” When the question is clear, the right pentest type almost chooses itself.
Also read: why BOLA and XSS remain top business risks, why startups need early API audits, and a cybersecurity roadmap for beginners.
Need help choosing the right pentest or API audit format for your product? Message me on WhatsApp.
For a review of your case, message me on WhatsApp.
