Penetration Testing Hub › Penetration Testing Explained
Web Application Penetration Testing Methodology
Only test web applications you own or have explicit written permission to test. Unauthorised access to a computer system is a criminal offence in Ireland under the Criminal Justice (Offences Relating to Information Systems) Act 2017. Everything below assumes you are testing your own application or one you are formally authorised to assess.
Your web application is where the internet meets your data. A booking system, a customer portal, an internal admin panel — if it takes input and touches a database, it's a target. Web app testing is the most mature discipline in the field, with a well-defined methodology anyone can follow. This page walks that methodology, what you can check on your own app, and where to bring in help.
1. How it's done
Mapping the application
The tester first understands the app: every page, parameter, input, API call, user role and workflow. A proxy like Burp Suite sits between browser and server, recording everything and letting the tester replay and modify requests. The goal is a complete map of the attack surface — including the endpoints the developers forgot were still there.
Testing against OWASP
Testing is structured around the OWASP Top 10 and the OWASP Testing Guide. The categories that matter most in practice: broken access control (can a normal user reach an admin function, or another user's data?), injection (SQL, command, and their relatives), authentication and session flaws, security misconfiguration, server-side request forgery (SSRF), and insecure direct object references. Our Hack Log has hands-on write-ups of SQL injection and SSRF; this page is the map, those are the terrain.
Business logic
The findings a scanner never catches live here: can you skip a payment step, apply a discount twice, change a price in transit, promote your own account, or order a negative quantity to get a refund? Business-logic flaws are unique to your app and are exactly why automated tools aren't enough.
What it usually finds
Recurring web findings: an access-control gap where changing an ID in the URL shows someone else's record, an injection point in a search or filter field, a session that doesn't expire, verbose error messages leaking internals, and an admin function reachable without admin rights.
2. What to look for — the self-check
- Every sensitive action re-checks the user's permissions server-side, not just by hiding a button.
- Changing an ID in a URL or request doesn't expose another user's data (test as a low-privilege user).
- User input is parameterised at the database layer — no string-built SQL.
- Sessions expire, log out properly, and rotate on privilege change.
- Error messages don't leak stack traces, versions or queries to the user.
- Security headers are set (CSP, HSTS, X-Content-Type-Options).
- File uploads are validated by content, not just extension, and stored outside the web root.
- Rate limiting protects login and any expensive or abusable endpoint.
- Dependencies are current — no known-vulnerable libraries (check with a scanner).
3. What to expect if you hire out
Scoping: which application(s), which environments (test vs production), and whether it's black, grey or white box. Grey box with test accounts at each permission level is the sweet spot — it's realistic and efficient.
Access: test accounts at every role level, ideally a staging environment that mirrors production, and any documentation on the app's intended logic.
Duration: a focused web app test is often one to two weeks depending on size and number of roles.
Production risk: testing on staging is safest. If production must be tested, destructive tests are avoided or carefully controlled, and timing is agreed.
The report: findings by severity with reproduction steps, proof-of-concept requests, and remediation — plus a re-test after you fix.
4. When you need a pro
You can and should run the self-check, use a dependency scanner, and fix the obvious. Stop before crafting live injection or SSRF payloads against production, before anything that could corrupt data or expose real customer records, and before testing authentication flows you can't safely reset. Business-logic testing and chained exploitation reward experience — a professional finds the flaw a checklist can't describe in advance.
Download: Web Application Security Checklist
A printable one-page version of the self-check above. No email required. Open the Web Application Security Checklist
Common questions
What methodology is used for web application penetration testing?
Most testers work to the OWASP Testing Guide and the OWASP Top 10, mapping the application, then testing access control, injection, authentication, misconfiguration, SSRF and business logic. The structure is well-defined, but the business-logic flaws unique to your app are where skilled manual testing earns its value over automated scanning.
Can I run a web application security scan myself?
Yes — dependency scanners and automated web scanners are worth running and will catch known issues and outdated libraries. They won't catch access-control gaps or business-logic flaws, which need manual testing. Use a scan as your baseline, then a penetration test to find what it can't see.
What's the most common web application vulnerability?
Broken access control is consistently near the top — a normal user reaching data or functions they shouldn't, often just by changing an ID in a URL. It tops the OWASP Top 10 for good reason, and it's something you can start checking on your own app today as a low-privilege user.
If you'd rather we tested your application — including the business-logic flaws scanners miss — here's how a CyberLabs engagement works, from scoping to re-test.
No prices on this page and no hard sell.
This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test. · ↑ Back to top