This web application penetration testing checklist has two jobs. It tells you what to prepare so a test is worth the money, and it shows what a competent tester should cover, so you can tell whether a report is thorough. It follows the OWASP Top 10, the most widely used list of web application risks, and adds the scoping and reporting steps that decide whether a test is useful.
Only test systems you own or have written permission to test. Everything below assumes an authorised test.
What should you prepare before the test?
Most of the value in a penetration test is decided before the tester starts.
- Scope. List the applications, domains, APIs, and environments to test. Say what is out of scope.
- Environment. Decide whether to test production or a staging copy. Staging is safer if it matches production closely.
- Test accounts. Create accounts for each user role (visitor, customer, staff, administrator) so the tester can check access between roles.
- Approach. Choose how much the tester knows in advance: nothing (black box), some access (grey box), or full documentation and code (white box).
- Dates and contacts. Agree test windows and name a person the tester can reach if something looks wrong.
- Backups. Confirm a recent backup exists before testing starts.
- Monitoring. Tell your hosting provider or security team, so a test is not mistaken for an attack.
- Goals. Note what worries you most, such as customer data, payments, or admin access.
- Compliance. Say if the test supports a standard such as PCI DSS or ISO 27001, since that changes the report format.
What does a tester check, category by category?
The OWASP Top 10 for 2021 has ten categories. A good test covers each one that applies to your application.
1. Broken access control
Can one user reach another user's data, or a normal user reach admin functions? The tester changes IDs in addresses and requests, tries to view pages meant for other roles, and checks that the server enforces permissions, since a hidden button on a page protects nothing. OWASP found some form of this problem in a large share of the applications it tested, which is why it sits first.
2. Cryptographic failures
Is sensitive data protected in transit and at rest? The tester checks that HTTPS is used everywhere, that old protocols are off, that passwords are stored with a proper hashing method, and that secrets are not exposed.
3. Injection
Can input from a user be turned into a command? This covers SQL injection and cross-site scripting. The tester tries crafted input in forms, search boxes, address parameters, and headers.
4. Insecure design
Is the application's logic itself weak? Examples include no limit on login attempts, a password reset that can be guessed, or a discount code that can be reused without end. These flaws come from how the feature was planned, and automated scanners rarely find them.
5. Security misconfiguration
Are default accounts, debug pages, open storage, verbose error messages, or missing security headers left in place? The tester reviews servers, frameworks, and cloud settings.
6. Vulnerable and outdated components
Does the application use libraries, plugins, or a platform with known flaws? The tester lists versions and checks them against published vulnerabilities.
7. Identification and authentication failures
How strong is login? The tester checks password rules, lockout, multi-factor authentication, session handling, password reset, and whether sessions end properly at logout.
8. Software and data integrity failures
Can code or data be altered without detection? That includes unsigned updates, untrusted content delivery, and insecure build pipelines.
9. Security logging and monitoring failures
If someone attacked the application, would you notice? The tester checks whether logins, failures, and unusual actions are recorded and whether anyone looks at them.
10. Server-side request forgery
Can the application be tricked into making requests to internal systems? The tester tries to point features that fetch addresses, such as image or webhook importers, at internal targets.
What else should be covered?
- APIs. Test them with the same care as the website, including authorisation on every endpoint and limits on how much data one request can return.
- File uploads. Check what types are accepted, how files are stored, and whether they can be executed.
- Business logic. Walk through the flows that matter to you: checkout, refunds, account changes, approvals.
- Mobile or single-page front ends. Check that the client does not hide controls that the server should be enforcing.
- Third-party scripts. Review what loads on your pages and what data it can see. Automated scanning between tests can cover some of this, as we explain in DAST vs penetration testing.
What should the report contain?
- An executive summary in plain language
- The scope, dates, and method used
- Each finding with a severity rating, evidence, and the steps to reproduce it
- A clear recommendation for fixing each finding
- Notes on what was tested and found secure, so you can see the coverage
- An offer to retest after you fix the issues
If a report is mostly scanner output with no evidence and no explanation, ask for more. Our post on penetration testing vs vulnerability scanning explains the difference.
Who should be involved on your side?
A test goes better with a small, named group. You need someone with authority to approve the scope and the dates, a developer or technical contact who can answer questions and fix findings, and someone who owns the hosting or infrastructure and can tell the tester about restrictions. In a small business these may be one or two people. What matters is that the tester has a name to contact, and that someone will read the report and act on it.
What should you do while the test runs?
Mostly, leave the application alone. Avoid deploying changes that alter what is being tested, because a moving target makes results harder to interpret. Keep your contact available in case the tester finds something urgent or needs an account reset. If you monitor traffic, expect unusual activity from the tester's addresses, and agree beforehand whether your team should block it or let it run. If the tester reports a serious issue during the test, ask for details straight away so you can fix it without waiting for the final report.
How do you read the severity ratings?
Reports usually rate findings as critical, high, medium, low, or informational. Many use the Common Vulnerability Scoring System, which gives each issue a number from 0 to 10 and groups the numbers into bands: low for the bottom of the scale, then medium, high, and critical for scores of 9.0 and above. A rating is a starting point, not the full story. A medium finding on the page that handles payments may matter more to you than a high finding on a page nobody uses, so ask your tester to explain the business impact of each item.
Fix in order of risk and effort. Critical and high findings come first, along with any quick fixes that remove a medium or low issue in a few minutes.
What are the common mistakes before and after a test?
- Giving no test accounts, so the tester sees only the public pages.
- Testing a staging copy that differs from production, then assuming the results apply to the live site.
- Leaving the scope vague, which leads to arguments about what was covered.
- Not telling your hosting provider, who then blocks the tester or raises an alarm.
- Filing the report and doing nothing, which leaves you with a record of problems and no fixes.
- Skipping the retest, so nobody knows whether the fixes worked.
- Treating the checklist as complete. It is a starting list, and your application may need checks specific to what it does.
Quick answers
What is the OWASP Top 10?
It is a widely used list of the ten most serious categories of web application security risk, published by the Open Web Application Security Project and updated every few years. Penetration testers use it as a baseline for what to check, and developers use it to learn what to avoid.
Can I test my own website?
You can test systems you own, and you should have written permission for anything hosted by others, since hosting providers and cloud services have rules about testing. Beginners can use free scanners and learning environments. For a report you can show to customers or auditors, hire an independent specialist.
Does the checklist cover APIs and mobile apps?
The web application categories apply to APIs too, with extra attention to authorisation on every endpoint and limits on data returned. Mobile apps add checks for how data is stored on the device and how the app talks to its server. Ask any tester to scope these explicitly.
What happens after the test?
- Review the findings with your developers and rank them by risk and effort.
- Fix the serious items first.
- Ask for a retest to confirm the fixes worked.
- Add what you learned to your development process, so the same mistakes do not return.
- Plan the next test. Our guide to how often to run a penetration test covers timing.
If you want a test scoped against this checklist, see our web application penetration testing services or contact us.