Pentest Methodology in 2026 - Web Apps A modern 2026 web application penetration testing methodology covering enumeration, authentication, server-side injection, access controls, API security, cloud-native infrastructure, and AI system vulnerabilities. It serves as a structured framework to efficiently identify vulnerabilities, but should be adapted and expanded based on the specific technology stack and unique logic of each application.

This methodology follows a breadth‑first approach to identify common and high‑impact issues early. It’s not exhaustive, but it’s a living document based on personal experience and peer insights gathered within the security community.

Hacking Mindset

  • Click every button; don’t leave a stone unturned.
  • Run vulnerability scanners like Burp Suite Pro scanner, Acunetix, Nuclei, or the new AI ones. (Keep in mind that especially on legacy or poorly designed applications they may create massive test data, modify state, or break functionality.)
  • Continuously inspect web requests and responses.
  • When you can’t find anything, run even more enumeration. I personally believe there is always something, it’s just a matter of time till you find it.
  • Automate and build your own tools and wordlists.

Logging Setup

To keep things simple, use this script from @sechurity. It preserves colors and formatting.

logt.sh

#!/bin/bash
# Helper script by @sechurity
# Create a log directory, a log file and start logging

if [ -z "${UNDER_SCRIPT}" ]; then
    logdir="${HOME}/logs"
    logfile="${logdir}/$(date +%F.%H-%M-%S).$$.log"

    mkdir -p "${logdir}"
    export UNDER_SCRIPT="${logfile}"

    echo "The terminal output is saving to ${logfile}"
    script -f -q "${logfile}"
    exit
fi

Make logt.sh accessible system-wide as logt:

chmod +x logt.sh
sudo cp logt.sh /usr/local/bin/logt

Enumeration

Enumeration is the foundation.

  • Identify the application tech stack, and framework.
  • Enumerate directories and files using wordlists adapted to the technology.
  • Identify all input points, parameters, cookies…
  • Enumerate HTTP methods (GET, POST, PUT).
  • Enumerate user roles and feature differences between accounts.
  • Repeat enumeration after authentication and with higher privileges.

Client-Side Vulnerabilities

Cross-Site Scripting (XSS):

  • Test GET parameters (?q=…), path segments (/search/<something>), and POST bodies, especially when values are reflected.
  • Try polyglot payloads (e.g. '"><img src=x>${{7*2}}), if there is an error or unusual rendering, investigate.
  • Test for HTML injection (e.g. <u>test</u>). If it renders with an underline, HTML injection is confirmed.
  • Try common XSS payloads such as <img src=1 onerror=alert(7)>. Note that a WAF may block some payloads; check the browser console for errors.
  • Check if the session cookie is httpOnly, if it’s not, you can exfiltrate it using JavaScript => easy high impact.
  • Rich text editors often use insecure functions like dangerouslySetInnerHTML and are frequently unsanitized. Finding one is a must-test for XSS.

Look for these insecure functions/tags (if left unsanitized):

innerHTML
dangerouslySetInnerHTML
v-html
document.write() / document.writeln()
outerHTML
srcdoc in <iframe>
eval() / new Function() / setTimeout("...") / setInterval("...")
echo

Cross-Site Request Forgery (CSRF)

  • SameSite=Lax on cookies is generally enough to protect POST requests from cross-site attacks in modern browsers.
  • Discovering XSS enables CSRF and can bypass traditional CSRF protections (including tokens) for that domain. Note that subdomains are considered same-site, so SameSite=Lax may not block requests from subdomains. Thus, XSS on a subdomain can often lead to CSRF on the main domain if protections are bypassed.
  • Look for sensitive GET requests that perform state changes (for example, GET /deleteItem?id=1) as they are often missing CSRF protection.
  • Attempt to bypass SameSite=Lax by overriding the method, for example by sending a GET request with _method=POST.
  • Look into Client Side Path Traversal (CSPT) and start checking for it.

Server-Side Injection

SQL Injection (SQLi)

Especially if the website looks legacy, custom, or not built with a well-known framework like Laravel, or Next.js…), you should look for SQLi.

  • Try injecting a ' , 1' or 1=1-- -, or a polyglot like &1/*'/*"/**/||1#\, if there is an error or weird behavior, you need to investigate.
  • To confirm blind SQLi, send payloads such as word' and 1=1-- - and word' and 1=2-- - and compare responses. Ensure word is an existing item so the baseline response returns data.
  • Plug your payload into sqlmap and keep changing --risk and --level values, an easy way is to create a file, let’s call it req, intercept a normal request in burp then copy it to the file, then put a * in the targeted parameter. synax: sqlmap -r req.
  • If you gain DB access, try dumping the users table (If you’re allowed to), check if you can crack hashes and get administrator access.
  • You can also leverage SQLi to read/write files or even get RCE under certain conditions, with sqlmap use --file-read=, --file-write=, --os-cmd=, and --os-shell.

NoSQL Injection

When you see Node.js or other NoSQL stacks, test for NoSQLi. Useful wordlist: https://github.com/cr0hn/nosqlinjection_wordlists

SSTI

  • Throw in a polyglot like ${{<%[%'"/#{@}}%\. and check for errors
  • Narrow down the templating engine using available cheat sheets, e.g. template-injection tables.

Authentication & Session Management

  • Username/Email Enumeration
    • Observe messages for valid vs invalid usernames (On login, password change, etc.)
    • Response time analysis can also reveal valid usernames. (Order by Response received in BurpSuite )
  • Password Policy
    • Test password policy enforcement during registration and password changes.
  • Multi-Factor Authentication (MFA) Bypass
    • OTP Brute Force (Especially if it’s just digits )
    • Search for leaked MFA metadata or keys
  • Session & JWT management
    • Test session cookie reuse across subdomains.
    • Secure & HttpOnly Flags
    • Session expiry (Shouldn’t be too long)
    • Try to crack JWT secrets
    • Algorithm Confusion for JWTs

Modern Authentication (OAuth / OIDC)

Look into https://portswigger.net/web-security/oauth for more details.

  • If a site offers a “log in with” option that uses an account from another website, it’s a clear sign that OAuth is in use.
  • Identify the OAuth flow (grant type) that’s in use (authorization code, implicit, PKCE).
  • Test for vulnerable CSRF protection (state parameter)
  • Check redirect_uri validation and open redirect chaining.
  • Test token reuse, token leakage (URL fragments, logs, referer headers).
  • Verify proper scope enforcement and claim validation.
  • Test account linking and SSO login flows for account takeover scenarios.

Access Control & Business Logic

BAC (Broken Access Controls):

  • Use Burp extensions like Auth Analyzer if you can access multiple roles. If not, compare authenticated vs unauthenticated behavior.
  • Check for IDORs. Example: if you find /receipt?id=1, try id=2.
  • Test change-password functionality: can you change another user’s password?
  • Test for mass assignment vulnerabilities (e.g. add "role":admin on registration)

Business Logic

Be creative: price manipulation, negative quantities, fractional/rounding errors, race conditions, and abuse of workflow logic are all fruitful areas.

File Handling & Infrastructure

File upload

  • Upload an accepted file (for example, test.png) and send the request to Repeater.
  • Change the file extension to something random, like test.ciozjf, and upload it. This helps avoid issues where the server expects the file content to match a specific format. If the upload succeeds, the application is likely relying on an extension blacklist or none at all. If the upload is rejected, it’s probably using an extension whitelist.
  • Blacklists are usually easier to bypass than whitelists, there are plenty of articles on the internet explaining how to do it. For a whitelist, here is what could be vulnerable:
    • .php, .phtml, .phar => possible RCE on php apps
    • .asp, .aspx => possible RCE on .NET apps
    • .svg, .html, .htm => XSS
    • .jsp => potential RCE on Java applications, depending on server behavior
    • .shtml => Server Side Injection (SSI), depends on the setup
  • Try injecting XSS into filenames, like test.png<img src=1 onerror=alert(7)>

LFI

  • Look for file-related parameters such as file=, page=, template=, include=, view=, language…
  • Test basic traversal (../) and encoded or double traversal variants.
  • Try common sensitive files (/etc/passwd, application configs, environment files).
  • If LFI is confirmed, test for log poisoning, session file inclusion, or uploaded file inclusion to escalate to RCE.
  • FUZZ, use Linux wordlist or  Windows wordlist (Not in seclists) and also the LFI-Jhaddix.txt wordlist. 
    ffuf -w wordlist -u 'http://target.com/index.php?file=../../../../FUZZ'

SSRF

  • Look for parameters that accept URLs, IPs, or hostnames (url=, redirect=, callback=, webhook=).
  • Attempt to access internal endpoints
  • Look for chaining opportunities (open redirect, file upload, deserialization, auth bypass).

Information Disclosure

  • Check responses often to see if they return more information than they should.
  • look for Backup, config, and code files (.bak, .old, .sql, .env, .swp, .git..), It’s better to prepare your custom wordlist/automation for this.
  • Analyze error messages for leaked data.
  • Check for directory listings especially on php and legacy apps, if there is one, there is probably more.
  • Check whether sensitive user-uploaded files are stored directly on the webserver and publicly accessible.

API Security

  • Enumeration is key here, enumerate endpoints, parameters, and methods.
  • Mass Assignment
  • Test Rate Limiting
  • SMS Flooding
  • GraphQL-specific Introspection queries (if enabled), Batching attacks (to bypass rate limits)

I may publish an article on API Security soon, keep an eye on the website :)

Web Cache Vulnerabilities (Deception / Poisoning)

Cache deception → sensitive content cached when it should not be.
Cache poisoning → attacker-controlled input stored and served to others.

  • Identify caching layers (CDN, reverse proxy, application cache).
  • Test cache key handling (headers, cookies, query parameters).
  • Check for cache poisoning via unkeyed inputs.
  • Test for sensitive content cached and served cross-user.
  • Look for discrepancies between cached and origin responses.
  • Combine with XSS, redirect, or auth issues for higher impact.

AI / ML System Vulnerabilities

Mostly reliant on prompt injection.

  • Identify where AI is used (chatbots, recommendation engines, moderation, search, scoring).
  • Test for prompt injection both direct (like a user prompt) and indirect via stored content or external/training data).
  • Try to understand what the LLM has access to (data, privileges…)
  • Check for secrets or training data leakage through prompts.
  • Test output handling: does AI output flow into HTML, SQL, logs, or system commands?
  • Check authorization boundaries: can low-privilege users influence high-privilege AI actions?

Cloud-Native & Infrastructure Context

  • Identify cloud provider and services in use (AWS, Azure, GCP; storage, compute, IAM, serverless).
  • Enumerate exposed cloud assets (object storage, metadata services, admin panels, APIs).
  • Check for public or improperly scoped storage buckets and blobs (especially S3 buckets).
  • Test IAM misconfigurations (over‑permissive roles, privilege escalation paths).
  • Review secrets handling (hardcoded keys, env vars, CI/CD leaks).

Framework Specific Hints

WordPress

Check my WordPress Pentesting Guide

Next.js / React / Angular

  • Inspect browser sources for /api, /server, /backend… endpoints and test for broken access control. Example: (I own this website, please don’t hack me)

  • You can also use LinkFinder
  • Test for Prototype pollution

Java / Spring Boot

  • Test Actuator endpoints (/actuator, /beans, /mappings).
  • Directory wordlist for Spring Boot: spring-boot.txt

Laravel (PHP)

  • Check for exposed .env files and leaked APP_KEY.
  • Test for debug mode (APP_DEBUG=true) and stack traces.

Flask (Python)

  • Check for debug mode and Werkzeug console exposure.
  • Test for SSTI in Jinja2 templates.

New Note-worthy CVEs

  • React2Shell (CVE-2025-55182): affects React 19
  • MongoBleed (CVE-2025-14847): affects all MongoDB versions from 2017 to late 2025
  • Next.js Middleware Auth Bypass (CVE-2025-29927): Starting in Next.js version 1.11.4 and prior to versions 12.3.5, 13.5.9, 14.2.25, and 15.2.3
  • Privilege escalation to root via sudo (CVE-2025-32463): Affects unpatched sudo 1.9.14, 1.9.15, 1.9.16, 1.9.17.

Conclusion

This methodology outlines a breadth-first approach to web application penetration testing. It serves as a structured framework to efficiently identify vulnerabilities, but should be adapted and expanded based on the specific technology stack and unique logic of each application.