Manual penetration testing means a person, not just a scanner, probes an application the way an attacker would: understanding how it works, then deliberately trying to break its security rules and proving which weaknesses are real. Automated scanners find known patterns quickly; manual testing finds the logic flaws they miss, such as one user reading another user's orders. This guide explains the process and the checks a QA tester can learn first.
Only test what you're authorised to test. Penetration testing without written permission is illegal in most countries, including under India's IT Act. Get the scope, environment and dates in writing, test in a non-production environment unless agreed otherwise, and never use real customer data.
Manual vs Automated Security Testing
| Automated scanning | Manual penetration testing | |
|---|---|---|
| Finds | Known patterns: missing headers, outdated libraries, common injection points | Business-logic and access-control flaws, chained issues, real impact |
| Speed | Fast, repeatable, good for CI | Slower, needs skill and time |
| False positives | Many; need triage | Few; each finding is confirmed |
| Example tools | OWASP ZAP baseline scan, dependency checkers | Burp Suite or ZAP as an intercepting proxy, browser DevTools |
Good teams use both: scans on every build, manual testing before major releases and for high-risk features like payments and authentication.
The Manual Penetration Testing Process
- Scope and rules of engagement: which URLs, APIs and roles are in scope, what is off-limits (for example, no load testing), test accounts, and who to call if something breaks.
- Reconnaissance and mapping: use the app as each role, record every page, API call and parameter through a proxy, and note where data comes from and who should see it.
- Vulnerability testing: work through the checks below, one area at a time.
- Validation: confirm each finding is real and repeatable with the smallest proof possible. The goal is evidence, not damage.
- Reporting: for each finding, the steps to reproduce, impact, severity and a suggested fix.
- Retest: verify each fix and check it didn't move the problem somewhere else.
Checks a Tester Can Start With
These map to the OWASP Top 10 and need no special exploit knowledge, only careful, curious testing.
Broken access control (the most common serious flaw)
- Log in as user A, open one of your orders, and note the ID in the URL or API call (
/orders/1042). Log in as user B and request the same ID. Getting A's data is an IDOR (insecure direct object reference). - As a normal user, call admin-only URLs or API endpoints directly. Hiding a button is not access control.
- Change a role or price field in a request through the proxy, for example
"role":"admin"in a profile update, and check the server ignores it.
Authentication and sessions
- After logout, replay an old request with the old session cookie or token; it must be rejected.
- Check the session expires after the agreed idle time, and that a password change logs out other sessions.
- Password reset: the link should be single-use, expire, and not reveal whether an email address is registered.
- Repeated wrong passwords should trigger rate limiting or lockout.
Input handling (injection and XSS)
- Enter a single quote
'in search and form fields. A database error or HTTP 500 suggests input reaches a query unsafely; report it, don't push further. - Enter harmless markup such as
<b>test</b>in a name or comment and see whether it renders as bold elsewhere. If it does, output isn't encoded and the field may be open to cross-site scripting. - Check validation happens on the server, by sending values through the proxy that the UI wouldn't allow (negative quantities, very long strings).
Configuration and data exposure
- Error pages shouldn't show stack traces, framework versions or SQL.
- Check security headers (
Content-Security-Policy,Strict-Transport-Security,X-Content-Type-Options) in the browser's Network tab. - Sensitive data (tokens, passwords, personal data) should never appear in URLs, logs, browser storage or API responses that don't need it.
- Everything should be served over HTTPS, including API calls and file downloads.
Tools to Learn First
- Browser DevTools: inspect requests, cookies, storage and headers.
- Burp Suite Community Edition or OWASP ZAP: intercept, modify and replay requests; this is the core manual-testing skill.
- Postman: replay API calls as different users to test access control.
- Practice targets: OWASP Juice Shop and PortSwigger's free Web Security Academy labs are built to be attacked legally.
Writing the Report
A useful finding has a clear title, the affected URL or endpoint, exact steps, the evidence (request, response, screenshot), the impact in business terms ("any customer can read any other customer's invoices"), a severity, and a recommended fix. Many teams rate severity with CVSS; whatever the scale, be consistent and explain your reasoning.
FAQs
What is manual penetration testing?
Security testing where a skilled person explores an application like an attacker, finding and confirming weaknesses such as broken access control or injection, instead of relying only on automated scanners.
Can a QA tester do penetration testing?
Yes, at an entry level. Access-control, session and input-handling checks fit naturally into functional testing. Deep exploitation and formal penetration tests are usually done by security specialists, often with certifications.
Is manual penetration testing legal?
Only with written permission from the system owner and within the agreed scope. Testing systems you don't own or haven't been authorised to test is illegal.
Which tools are used for manual penetration testing?
An intercepting proxy such as Burp Suite or OWASP ZAP, browser DevTools and an API client like Postman cover most manual web testing.
