Website Penetration Testing: Methodology, What Testers Check, and How to Choose a Penetration Testing Company
A detailed guide to website and web application penetration testing: what it is, the testing methodology, the vulnerabilities testers look for, black, grey, and white box approaches, preparation, reports, remediation, and how to choose a penetration testing company.
Key takeaways
- Website penetration testing is an authorised, simulated attack on your website or web application to find exploitable weaknesses before criminals do.
- Skilled manual testing finds business logic and access control flaws that automated scanners miss.
- Grey box testing, with credentials for each user role, is usually the most efficient approach for web applications.
- A good report explains each finding's impact, evidence, and fix in terms both developers and leaders understand.
- Choose a penetration testing company on tester expertise, methodology, report quality, and retest support, not price alone.
Websites and web applications are the front door of most businesses, and attackers know it. Customer portals, ecommerce stores, booking systems, SaaS platforms, and APIs handle personal data, payments, and business logic that criminals want to abuse. Automated scanners catch some problems, but many of the most damaging breaches come from flaws that only a thinking human can find, such as a customer being able to view another customer's records by changing a number in the address bar. Website penetration testing puts skilled security testers in the attacker's position, so you can find and fix those flaws first. This guide explains how website penetration testing works and how to choose the right penetration testing company.
What is website penetration testing?
Website penetration testing, also called web application penetration testing or ethical hacking, is a controlled, authorised assessment in which security professionals attempt to exploit vulnerabilities in a website or web application. Testers use the same techniques as real attackers, but within agreed rules, timeframes, and scope, and they document everything they find so it can be fixed. The goal is not just to list potential issues but to demonstrate real impact, such as gaining unauthorised access to data, taking over accounts, escalating privileges to administrator, or manipulating transactions. That evidence helps organisations prioritise fixes based on genuine risk.
Why automated scanning is not enough
Automated vulnerability scanners are valuable for finding known issues quickly and frequently, such as outdated software, missing security headers, and some injection flaws. However, scanners do not understand your business. They cannot tell that a regular user should not be able to approve their own refund, that a discount code can be applied repeatedly, that an API returns other tenants' data when an identifier changes, or that a multi-step checkout can be manipulated to skip payment. These business logic and authorisation flaws are among the most common and serious issues in modern web applications. Penetration testers combine automated tools with manual investigation, creativity, and an understanding of how the application is meant to work. Our comparison of vulnerability assessment vs penetration testing explains when each is appropriate.
Testing approaches: black, grey, and white box
| Approach | What testers receive | Advantages | Trade-offs |
|---|---|---|---|
| Black box | Only the URL, like an external attacker | Realistic view of external exposure | Time spent on discovery; authenticated areas may be missed |
| Grey box | Test accounts for each role and some documentation | Efficient, covers authenticated features and authorisation thoroughly | Less emphasis on pure external reconnaissance |
| White box | Credentials, documentation, architecture, and source code | Deepest coverage; finds issues hard to detect from outside | More effort and access required |
For most business web applications we test, grey box testing gives the best overall value, because the majority of serious issues sit behind login screens, in the interactions between user roles and data. White box testing adds source code review for critical applications.
The testing methodology
Professional testers follow structured methodologies, commonly based on the OWASP Web Security Testing Guide, adapted to each application.
1. Scoping and rules of engagement. Agree target URLs, environments, user roles, testing windows, excluded actions such as denial-of-service, and emergency contacts. Obtain written authorisation.
2. Reconnaissance and mapping. Testers explore the application, map pages, functions, parameters, APIs, and technologies, and identify where sensitive data and actions live.
3. Automated scanning. Tools identify known vulnerabilities and misconfigurations, giving testers leads to investigate manually.
4. Manual testing. Testers systematically examine authentication, session management, authorisation, input handling, business logic, file handling, client-side security, and APIs, attempting to exploit each weakness and chain issues together.
5. Exploitation and impact analysis. Confirmed vulnerabilities are carefully exploited within the agreed rules to demonstrate realistic impact, without damaging data or disrupting service.
6. Reporting. Findings are documented with severity, evidence, reproduction steps, impact, and remediation guidance. Critical issues are reported immediately rather than waiting for the final report.
7. Remediation support and retesting. Testers clarify findings for developers and retest fixes to confirm they work.
What penetration testers check
| Area | Examples of issues tested |
|---|---|
| Broken access control | Viewing or editing other users' data by changing identifiers, accessing admin functions as a normal user, missing checks on APIs |
| Authentication | Weak password rules, missing rate limiting, credential stuffing exposure, flawed password reset, multi-factor bypass |
| Session management | Predictable tokens, sessions that never expire, missing logout invalidation, insecure cookie flags |
| Injection | SQL injection, command injection, template injection, and NoSQL injection |
| Cross-site scripting (XSS) | Stored, reflected, and DOM-based script injection that can hijack user sessions |
| Business logic | Price manipulation, coupon abuse, skipping workflow steps, race conditions in transactions |
| File handling | Unrestricted uploads, path traversal, access to other users' files |
| Server-side request forgery (SSRF) | Making the server request internal resources or cloud metadata |
| Security misconfiguration | Verbose errors, debug modes, default credentials, exposed admin panels, missing security headers |
| Sensitive data exposure | Data leaked in responses, logs, URLs, or client-side code |
| Vulnerable components | Outdated frameworks, CMS versions, plugins, and libraries with known vulnerabilities |
| APIs | Excessive data exposure, missing authorisation, lack of rate limiting, mass assignment |
These categories align closely with the OWASP Top 10 and the OWASP API Security Top 10. Our API security testing guide covers API-specific testing in more depth.
Testing in production or staging?
Testing a staging environment that mirrors production allows more aggressive testing without risking real customer data or service availability, and is usually preferred for complex applications. However, staging environments sometimes differ from production in configuration, data, or integrations, which can hide real issues. Some checks, such as external exposure, TLS configuration, and production-only infrastructure, are best performed against production with care. Many engagements test the application in staging and perform limited, safe checks against production. Whichever you choose, ensure backups exist, monitoring teams know testing is happening, and test accounts use non-sensitive data.
How to prepare for a website penetration test
- Define the scope clearly, including domains, subdomains, APIs, and user roles, and anything out of scope.
- Create working test accounts for every role, with realistic sample data, including at least two accounts per role so testers can check access between users.
- Provide documentation such as API specifications, user guides, and architecture overviews.
- Whitelist tester IP addresses in web application firewalls if you want the application itself tested rather than the firewall.
- Inform hosting providers and internal teams of the testing window to avoid false alarms.
- Freeze major changes during testing so results reflect a stable version.
- Run your own vulnerability scan and fix obvious issues first, so testers focus on deeper problems.
Understanding the report
A good penetration test report has two audiences. The executive summary explains overall risk, the most important findings, and recommended priorities in business language. The technical section details each finding with a severity rating, often using CVSS adjusted for context, a description, affected URLs and parameters, step-by-step reproduction instructions, evidence such as requests and screenshots, business impact, and specific remediation advice. Good reports also note what was tested and found secure, so you understand coverage. Treat critical and high findings as urgent, fix medium findings in planned work, and address low findings as part of normal hardening. Be cautious with reports that look like raw scanner exports with little analysis.
Remediation and retesting
After receiving the report, assign each finding to an owner with a deadline based on severity. Look for patterns: several access control findings usually indicate a missing central authorisation mechanism, which should be fixed at the framework level rather than endpoint by endpoint. Add automated tests for fixed vulnerabilities so they do not return. Once fixes are deployed, request a retest to confirm each issue is resolved, and keep the updated report for customers, auditors, and insurers. Feed lessons back into development training and code review. Our guide to application security and the secure SDLC explains how to prevent recurring issues.
Common findings by platform
Different website platforms tend to produce different patterns of findings. WordPress and other popular CMS platforms most often suffer from outdated or abandoned plugins and themes, exposed login pages without rate limiting or multi-factor authentication, excessive administrator accounts, and file upload weaknesses in form or media plugins. Ecommerce platforms frequently show business logic issues around pricing, discounts, stock, and checkout flows, as well as weaknesses in customer account areas and order history. Custom web applications built with modern frameworks often have strong protection against classic injection flaws, thanks to framework defaults, but are prone to broken access control, especially in APIs that power single-page applications, where the front end hides buttons but the back end does not enforce permissions. Multi-tenant SaaS platforms are particularly exposed to tenant isolation failures, where data from one customer organisation leaks to another. Knowing these patterns helps testers focus effort, and helps development teams apply preventive controls before the test, such as centralised authorisation checks, plugin hygiene, and automated tests for pricing rules. A good penetration testing company adapts its approach to your platform rather than running the same checklist on every website, and explains clearly which platform-specific risks it examined and why they matter for your business.
How often to test your website
Test at least annually and after significant changes, such as major new features, redesigns, changes to authentication or payments, new integrations, or platform migrations. Applications that release frequently benefit from security testing integrated into the development pipeline, combined with targeted manual tests of high-risk features and periodic full assessments. Compliance requirements, such as PCI DSS for card data, and customer contracts may require specific testing frequencies. Between full tests, continuous vulnerability scanning, dependency monitoring, and a responsible disclosure or bug bounty programme help catch new issues as they appear.
How to choose a penetration testing company
- Tester expertise: ask who will perform the test, their experience with similar applications and technologies, and certifications such as OSCP, OSWE, BSCP, CREST, or equivalent.
- Manual testing focus: confirm how much time is manual testing versus automated scanning.
- Methodology: ask which standards they follow and how they test business logic and authorisation.
- Sample report: review a redacted report for clarity, evidence, and actionable remediation guidance.
- Communication: confirm how critical findings are escalated during testing and whether testers will discuss findings with developers.
- Retesting: check whether retests are included and within what period.
- Professional safeguards: confirm written authorisation processes, confidentiality, secure handling of data, and professional liability insurance.
Our penetration testing cost guide explains how scope and complexity affect pricing so you can compare quotes fairly.
Example: A B2B SaaS company commissioned a grey box penetration test of its customer portal and API ahead of an enterprise sales push. The testers received two separate accounts for each of three roles in two separate tenant organisations. They found that a report export endpoint accepted a tenant identifier from the request, allowing a user from one company to download another company's reports, and that the password reset token did not expire. Neither issue had been detected by the company's automated scanner. The development team introduced tenant checks in a shared authorisation layer, fixed token expiry, added automated tests, and passed the retest, giving the sales team a clean report to share with prospects.
Test your website with Vertex Cyber Tech
We are a penetration testing company providing expert-led website, web application, API, mobile, and cloud penetration testing, with clear reports, developer-friendly remediation guidance, and retesting. Explore our cybersecurity services, read our website security audit guide, or book a consultation to scope your test.
Sources and further reading
Article FAQs
What is website penetration testing?
It is an authorised, simulated attack on a website or web application by security professionals who try to exploit vulnerabilities, demonstrate their impact, and recommend fixes before real attackers find them.
What vulnerabilities does a web penetration test find?
Common findings include broken access control, authentication and session flaws, injection, cross-site scripting, business logic abuse, insecure file uploads, SSRF, misconfigurations, sensitive data exposure, vulnerable components, and API weaknesses.
What is the difference between black box and grey box testing?
Black box testers start with only the URL, like an outside attacker. Grey box testers receive accounts for each role and some documentation, which is usually more efficient and thorough for web applications.
How long does a website penetration test take?
Simple websites may take a few days, while complex web applications with many roles, features, and APIs typically take one to several weeks, plus reporting and retesting.
How do I choose a penetration testing company?
Evaluate tester expertise and certifications, the share of manual testing, methodology, a sample report, communication during testing, included retests, and professional safeguards such as authorisation and insurance.
About Vertex Cyber Tech Engineering Team
Software engineers, AI/ML developers, cloud architects, and security specialists at Vertex Cyber Tech Solutions who design, build, and secure production systems for clients in India, the US, the UK, and worldwide.
More articles