Web Application Security Testing: A Complete Guide for Developers (2026)
Web application security testing is no longer optional. With breaches making weekly headlines and average remediation costs north of $4M, every team shipping code to the internet needs a structured testing approach — not a once-a-year pentest, not a vague "we use Cloudflare," but a repeatable process that runs continuously.
The problem? Most security guides are written for security teams, not developers. They assume you have a SOC, a budget, and weeks of free time. This guide is different. It's organized around the five categories of web app security a developer can actually own, the best tools for each, and how to wire them into your CI/CD pipeline without slowing down releases.
Check your site right now: Free ZeriFlow scan in 60 seconds →
The 5 Categories of Web Application Security Testing
Most "OWASP Top 10" lists overwhelm developers because they mix vulnerability classes (XSS, SQLi) with architectural issues (broken access control). For testing purposes, it's cleaner to think in five layers, each with its own tools and ownership.
| Category | What it covers | Who owns it |
|---|---|---|
| 1. Configuration & Headers | TLS, security headers, CSP, CORS, server fingerprint | DevOps + Backend |
| 2. Authentication & Sessions | Login flows, password policy, MFA, session management | Backend |
| 3. Input Validation | XSS, SQLi, SSRF, command injection, deserialization | Backend + Frontend |
| 4. Dependencies | npm/pip/maven CVEs, supply chain, transitive deps | All devs |
| 5. Network & Infrastructure | DNS, exposed ports, S3 buckets, subdomains | DevOps |
Let's break down each layer with the right tools and a concrete checklist.
Category 1: Configuration & Headers
This is the layer most teams ignore — and the layer attackers reconnaissance bots scan first. Misconfigured headers, weak TLS, or a verbose Server: Apache/2.2.15 banner gives attackers a head start.
What to test
- TLS version (1.2 minimum, 1.3 preferred), cipher suites
- Certificate validity, chain, SANs
- HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- CORS configuration (no
Access-Control-Allow-Origin: *with credentials) - Cookie flags: HttpOnly, Secure, SameSite
- Server version disclosure
- Exposed admin panels,
.env,.git,phpinfo.php
Best tools
- ZeriFlow — passive scan, 80+ checks, 60 seconds. Ideal for production audits and continuous monitoring.
- Mozilla Observatory — header grading.
- testssl.sh — deep TLS/cipher analysis.
- Nikto — classic web server scanner.
# Deep TLS scan
testssl.sh https://example.com
# Web server scan
nikto -h https://example.comThis category is exactly what ZeriFlow specializes in — run a free scan to get a configuration baseline in under a minute.
Category 2: Authentication & Session Management
Broken auth is consistently OWASP #1 or #2. The tests here aren't about fancy fuzzing — they're about flow logic.
What to test
- Password policy (length, complexity, breach-list check via HIBP API)
- Account lockout after N failed attempts (and rate limiting)
- MFA enforcement and recovery flows
- Session token entropy and rotation on login
- Session timeout (idle and absolute)
- Logout invalidates server-side session
- Password reset tokens: single-use, time-limited, unguessable
- JWT: signature verification,
nonealgorithm rejected, short expiry
Best tools
- Burp Suite — manual testing of login/auth flows
- OWASP ZAP — automated session handling tests
- JWT.io + jwt_tool — JWT-specific attacks (algorithm confusion, weak secrets)
A surprising number of auth bugs are found by simply turning off JavaScript and trying to bypass client-side validation, or by replaying old session tokens after logout. Make this part of your QA checklist.
Category 3: Input Validation
This is where SQLi, XSS, SSRF, command injection, XXE, and deserialization live. Coverage requires both static (SAST) and dynamic (DAST) testing.
What to test
- Every user input — query params, POST body, headers, cookies, file uploads
- API endpoints with structured payloads (JSON, XML, GraphQL)
- File upload handlers (path traversal, MIME confusion, ZIP slip)
- URL parameters that get fetched server-side (SSRF risk)
Best tools
- SQLMap — see our SQL injection scanner guide
- XSStrike / OWASP ZAP — see our XSS vulnerability scanner guide
- Semgrep — SAST with security rulesets
- CodeQL — GitHub-native SAST
- Nuclei — template-based DAST, CI-friendly
A typical CI step:
- name: Semgrep SAST
run: semgrep --config=p/owasp-top-ten --error
- name: Nuclei DAST
run: nuclei -u $STAGING_URL -severity high,criticalCategory 4: Dependencies & Supply Chain
The Log4Shell, event-stream, and ua-parser-js incidents proved that your security posture is only as strong as your weakest npm package. Modern web apps pull in hundreds of transitive dependencies — you must scan them.
What to test
- Direct and transitive dependency CVEs
- License compliance (legal risk, not security per se)
- Malicious package detection (typosquatting, recently-updated packages)
- Lockfile integrity
Best tools
- npm audit / pip-audit / cargo audit — built-in, free, run in CI
- Snyk — best-in-class CVE database, free tier for OSS
- Dependabot / Renovate — automated PRs for upgrades
- OSV-Scanner (Google) — open-source, multi-ecosystem
# CI step
npm audit --audit-level=high
osv-scanner -r .Category 5: Network & Infrastructure
Your code can be perfect and you'll still get owned via an exposed S3 bucket, an abandoned subdomain, or a forgotten staging environment.
What to test
- DNS records: dangling CNAMEs (subdomain takeover risk), SPF/DMARC/DKIM
- Open ports beyond 80/443
- Cloud storage buckets (S3, GCS, Azure Blob) — public listing, public read
- Subdomain enumeration — discover forgotten environments
- Container image vulnerabilities
Best tools
- nmap — port scanning
- subfinder + httpx (ProjectDiscovery) — subdomain discovery
- trufflehog / gitleaks — secret scanning in git history
- trivy — container image and IaC scanning
# Subdomain enumeration
subfinder -d example.com | httpx -title -status-code
# Container scan
trivy image myapp:latestBuilding Your Continuous Testing Pipeline
Here's a battle-tested flow for a small-to-midsize team:
On every commit (PR): - Semgrep SAST (fails build on high severity) - npm audit / dependency check (fails on high CVEs) - Secret scanner (gitleaks)
On every deploy to staging: - Nuclei DAST - ZAP baseline scan - ZeriFlow configuration scan
Weekly (scheduled): - Full ZAP active scan - Subdomain enumeration diff - Trivy on all production container images
Monthly: - Manual review of auth flows - Pentest a single feature in depth
Quarterly: - External pentest (or red team exercise)
This stack is mostly free, runs in any CI provider, and catches 90%+ of what a human pentester would find — at a fraction of the cost.
FAQ
### Q: What's the difference between SAST and DAST? A: SAST (Static Application Security Testing) analyzes source code without running it — tools like Semgrep, CodeQL. DAST (Dynamic Application Security Testing) tests the running application via HTTP requests — tools like ZAP, Burp, ZeriFlow. You need both: SAST catches code-level bugs early, DAST catches runtime and configuration issues.
### Q: How long does a complete web application security test take? A: Automated scanning takes minutes to hours (Nuclei + ZAP + dependency scan typically <1h). A manual pentest of a medium-sized SaaS app takes 2-5 days for a focused engagement. Continuous automated testing in CI catches most regressions immediately.
### Q: Do I need a pentest if I run automated scans? A: Yes, but less often. Automated scanners catch known patterns; a skilled pentester finds business logic flaws, chained vulnerabilities, and creative bypasses that no scanner catches. Aim for automated daily, manual quarterly.
### Q: What's the most common vulnerability found in web apps in 2026? A: Broken access control and security misconfiguration consistently top the OWASP charts. Both are largely preventable with structured testing — broken access control via integration tests asserting authorization, misconfiguration via tools like ZeriFlow run on every deploy.
### Q: Is ZeriFlow a complete web application security testing solution? A: ZeriFlow covers Category 1 (Configuration & Headers) deeply with 80+ automated checks. For full coverage you'll combine it with SAST (Semgrep), DAST (ZAP/Nuclei), dependency scanners (Snyk), and periodic manual testing. Think of ZeriFlow as your continuous configuration baseline.
Conclusion
Web application security testing isn't a single tool — it's a layered process. Configuration, auth, input validation, dependencies, and infrastructure each need their own tooling and cadence. The teams that get breached aren't always the ones that "didn't care about security"; they're the ones that tested only one or two layers and assumed the rest.
Start where the ROI is highest: configuration. It's the layer attackers probe first, it's testable in 60 seconds, and the fixes are usually free. Then layer in SAST, DAST, and dependency scanning as you mature.
Start your free security scan on ZeriFlow → — 60 seconds, 80+ configuration and infrastructure checks, free plan available.