This is a basic web pentesting guide written for junior pentesters. This article assumes that you:

Things to Remember!

1. Understand what you are trying to accomplish

Are you doing recon? Looking for a version number? Trying to exploit something? Try mapping what you are doing to the OWASP Top 10 and identify relavant CWEs. If you can’t find what you are trying to test, then it’s probably not worth pursuing.

2. Understand what your tools are doing

Once you know what you are trying to accomplish, you will inevitably accomplish this by using tools. Do not blindly copy and paste commands and run tools you are unfamiliar with. Do your research into the tool (Google search “ToolName github” or “ToolName kali”), or check the manpage (man ToolName). Similarly, understand what the arguments you are providing are doing.

3. Take Notes

Everything that you find (good or bad) will end up in a report, or may be relevant to a client’s question in the future. Use your preferred notetaking app (ex. Obsidian, Cherrytree, OneNote) and take lots of screenshots.

In your preferred order, you should review the following sources (some of which will be referenced in this article):

Source Description
OWASP Testing Guide Focus on section 4 (Web Application Security Testing).
OWASP Top 10 Review each of the Top 10 items and read the attack scenarios and prevention sections.
HackTricks Follow the methodology and run any tests that are relevant to your target.
PayloadsAllTheThings Provides different injection and bypass payloads.

Reconnaissance

Before you try to assess a web application, you need to actually know what you are targeting. Answer the following:

  1. What is the domain name?
    • If you can’t answer this… turn back now…
  2. What does it resolve to?
    • Windows: nslookup DOMAIN
    • Unix: dig DOMAIN

      NOTE: This might provide important context about where the application is likely hosted. Lookup the IP addresses using something like ipinfo.io:
      • are these Microsoft IPs? (Azure)
      • are they Amazon IPs? (AWS)
      • are they Cloudflare IPs? (Likely protected by a Cloudflare WAF)
      • otherwise, are they IPs owned by the target or an ISP? (could still be cloud, but could also indicate on-prem) this information could later influence your payloads.

  3. What is the web server?
  4. What is the web application framework?

Automated Scanning

Automated scans should be run in parallel with manual testing. Treat all results from automated tools as leads, and not confirmations. You should always try to demonstrate a relevant proof of concept for the client instead of just providing the output of an automated tool. If you cannot demonstrate exploitability, consider reducing your reported severity or marking the findings as “informational”.

Example tools:

There are hundreds of tools out there and everyone has their biases and preferences. OWASP Testing Guide and HackTricks are useful sources for finding tools - you can also just look through the tools installed by Kali.

  • Burp Suite (with license): run a rate-limited scan on select endpoints.
  • Caido: alternative to Burp for active scanning.
  • nmap: service discovery and basic version fingerprinting (nmap -sV -T4).
  • dirbuster/ffuf/gobuster: used to find (sometimes hidden) directory paths. Use common and target-specific wordlists based on what you determined during recon.
  • nuclei/Nessus (with license): quick vulnerability detection using templates (tune severity and scan scope).
  • wpscan/cmseek: CMS-specific scanners (WordPress, Drupal, etc.).
    • NOTE: You should know which CMS from your recon phase.
  • nikto: fast checks for common misconfigurations and headers.
  • sqlmap: automated SQLi discovery & exploitation (use only to confirm, and with caution. DO NOT USE --risk=3 without explicit permission from the client).

See below for a rough guideline and how and when to use tools:

  1. Passive first: capture traffic via proxy while exploring the app normally (login flows, account creation, file uploads). Record interesting endpoints, cookies, headers and then use your tools against them.
  2. Content discovery: run ffuf/gobuster with tuned wordlists (ex. common, backup, custom from sitemap/JS) to enumerate hidden endpoints.
  3. Credential checks: run CMS or auth-specific scanners (ex. wpscan) for weak/default creds and known plugin issues.
  4. Vulnerability templates: run nuclei and Nikto to surface known issues and misconfigs.
  5. Targeted automated checks: run SQLMap only against candidate injectable parameters identified earlier; run active Burp scans against specific endpoints.
  6. Rate-limited & scoped runs: throttle and exclude known protected endpoints (logout, payment providers). Monitor logs and proxy for any unintended impact to the application.

NOTE: Do not blindly trust severity ratings returned by automated scanners. Many high/critical findings are context-dependent and require verification!

Manual Testing

Advice on this topic boils down to: think like an attacker! Abuse workflows, chain actions together, and validate trust boundaries. Understand what the application is designed to do (and not do) and then challenge that design. Below are some examples of things to focus on:

  1. Authentication & session handling
    • Test account creation, password reset flows, and multi-factor bypasses.
    • Check session cookie flags: Secure, HttpOnly, SameSite. Attempt session token brute-force or reuse across subdomains.
  2. Authorization
    • Change IDs in URLs, tamper object references, force direct object access (READ: Insecure direct object references (IDOR)).
    • Test business logic: create actions as low-privilege users and attempt admin-only operations.
  3. Input validation & injections
    • Manually fuzz parameters with payloads from PayloadsAllTheThings. Verify SQLi, XSS (reflected, stored, or DOM), OS commands, LDAP, and template injections. Use Burp intruder/repeater for iterative tests.
    • Check all input sources: headers, cookies, JSON bodies, file uploads, multipart forms.
  4. CSRF
    • Identify state-changing endpoints without anti-CSRF tokens. Attempt token reuse, missing SameSite protections, and blind CSRF via HTML forms.
  5. File upload & deserialization
    • Test content-type mismatches, double extensions, magic-byte checks, and path traversal (READ: Upload Insecure Files).
  6. Business logic & workflow abuse
    • Walk user journeys end-to-end. Look for order manipulation, price tampering, race conditions, coupon abuse, multi-step workflow skipping, or refunds/credits logic flaws.
  7. Access control on APIs
    • Test API endpoints directly (bypass UI) and replay mobile app or SPA requests. Check for excessive data exposure in API responses.
  8. Client-side security
    • Inspect JS and HTML for secrets, tokens in source, insecure usage of eval(), dangerous third-party libs, and insecure CORS policies.
  9. Security headers & TLS
    • Verify HSTS, CSP, X-Frame-Options, Referrer-Policy, and strict TLS configs. Check for mixed content and weak cipher suites.
  10. Chaining & exploit proof
    • Combine verified issues (ex. auth bypass + upload) to demonstrate realistic impact. Keep PoC minimal and non-destructive.

Good luck!

This guide is not exhaustive. There are many different ways to do things, and you need to apply some creativity to your testing strategies once you get a hang of your tools. It takes time to get good at web testing, but you can do it!

- lootem