This chapter covers web application vulnerability scanning, a critical skill for the CS0-003 exam under domain 2 (Vulnerability Management). You will learn how automated scanners discover and assess security flaws in web applications, including the types of vulnerabilities they detect, how they operate, and how to interpret their results. Expect roughly 10–15% of exam questions to touch on scanning concepts, tool selection, and analysis of scan outputs.
Jump to a section
Imagine a physical security audit of a bank. The auditor starts by walking around the building, noting all entry points (doors, windows, vents) — this is like crawling the web application to discover all URLs and parameters. Next, they try each door handle to see if any are unlocked — this is like testing for default credentials or open access controls. Then they systematically try to force open each window with a specific tool, recording which ones give way — this is like sending payloads to each input field to test for SQL injection or XSS. The auditor also checks the alarm system by triggering it and seeing if the response team arrives — this is like testing for proper error handling and logging. Finally, they compile a report ranking vulnerabilities by severity and recommending fixes — exactly what a web vulnerability scanner does. Just as a physical audit cannot guarantee every possible breach is found, a scanner cannot find all vulnerabilities, but it systematically checks known patterns.
What is Web Application Vulnerability Scanning?
Web application vulnerability scanning is the automated process of probing a web application for security weaknesses. Unlike network vulnerability scanners that focus on open ports and service versions, web application scanners understand HTTP/HTTPS protocols, parse HTML, JavaScript, and other web technologies, and simulate attacks against application logic. They are essential for identifying vulnerabilities like SQL injection, cross-site scripting (XSS), insecure direct object references (IDOR), and misconfigurations before attackers exploit them.
How Web Application Scanners Work
A web application scanner operates in several phases:
Crawling/Spidering: The scanner navigates the application by following links, submitting forms, and parsing sitemaps (e.g., robots.txt, XML sitemaps). It builds a map of all discovered URLs, parameters, and forms. Advanced scanners also execute JavaScript to crawl single-page applications (SPAs).
Discovery: The scanner identifies technologies in use (e.g., web server, CMS, frameworks, libraries) by analyzing HTTP headers, HTML comments, and file extensions. It may fingerprint versions to match known vulnerabilities.
3. Attack Simulation: The scanner sends a series of malicious payloads to each input point (URL parameters, form fields, cookies, headers) to test for vulnerabilities. Common tests include:
- SQL Injection: Payloads like ' OR '1'='1 are submitted to see if they alter the database response.
- Cross-Site Scripting (XSS): Script payloads like <script>alert(1)</script> are injected to see if they are reflected or stored.
- Path Traversal: Sequences like ../../../etc/passwd are tested to access restricted files.
- Command Injection: System commands like ; ls are appended to parameters.
- CSRF: The scanner checks if forms have anti-CSRF tokens.
- File Inclusion: Tests for Local File Inclusion (LFI) and Remote File Inclusion (RFI).
Analysis: The scanner evaluates responses for signs of successful exploitation, such as database error messages, reflected scripts, or changes in application behavior. It correlates findings with known vulnerability signatures.
Reporting: Results are compiled into a report with severity levels (Critical, High, Medium, Low, Info) and remediation recommendations.
Key Components and Defaults
User-Agent: Most scanners set a default User-Agent string that can be used to detect scanning activity (e.g., "Mozilla/5.0 (compatible; Acunetix WVS").
Request Rate: Default request rates vary; typical values are 1–10 requests per second to avoid overwhelming the target. Burst rates may be higher for short periods.
Timeout: Default HTTP timeout is usually 30 seconds.
Concurrent Connections: Typically 5–10 simultaneous connections to speed up scanning without causing denial of service.
Crawl Depth: Default depth is often 3–5 levels from the starting URL.
Excluded Paths: Common exclusions include logout, logout, and admin sections to avoid disrupting the application.
Configuration and Verification Commands
Using Nikto (open-source web scanner):
nikto -h https://example.com -ssl -port 443 -output scan.html -Format html-h: target host
-ssl: force SSL
-port: specify port
-output: save report
Using OWASP ZAP (Zed Attack Proxy):
zap.sh -cmd -quickurl https://example.com -newsession session -quickout report.html-cmd: command-line mode
-quickurl: target URL
-newsession: create new session
-quickout: output report
Verification of scan results often involves manually confirming vulnerabilities using tools like curl or sqlmap.
Interaction with Related Technologies
WAFs (Web Application Firewalls): Scanners may trigger WAF rules, causing false positives or blocks. Some scanners can detect WAF presence and adjust payloads to bypass basic rules.
IDS/IPS: Scanners can trigger intrusion detection/prevention systems. It's common to whitelist scanner IPs during authorized tests.
Authentication: Scanners often support form-based, Basic, NTLM, and OAuth authentication to scan authenticated portions of the application.
Session Management: Scanners maintain session cookies to stay authenticated throughout the scan.
Types of Vulnerabilities Scanned
OWASP Top 10: The scanner focuses on the most critical web application security risks, including injection, broken authentication, sensitive data exposure, XXE, broken access control, security misconfiguration, XSS, insecure deserialization, components with known vulnerabilities, and insufficient logging/monitoring.
Business Logic Flaws: Some advanced scanners can detect logic flaws (e.g., privilege escalation by manipulating parameters), but most rely on manual testing.
Configuration Issues: Weak SSL/TLS ciphers, missing security headers (e.g., HSTS, CSP), directory listing enabled.
Limitations
False Positives: Scanners may report vulnerabilities that don't actually exist (e.g., reflected XSS that only appears in error messages).
False Negatives: Scanners cannot find all vulnerabilities, especially business logic flaws, chained exploits, or zero-day attacks.
JavaScript-heavy Applications: SPAs require scanners to execute JavaScript, which can be slow and incomplete.
Rate Limiting: Aggressive scanning can be blocked or throttled by the application.
Best Practices
Scope Definition: Clearly define allowed targets and test types before scanning.
Authentication: If the application requires login, configure the scanner with valid credentials and ensure session handling works.
Scheduling: Run scans during maintenance windows to avoid impacting production.
Verification: Manually verify all findings to eliminate false positives.
Remediation Tracking: Use a ticketing system to track vulnerability fixes.
Tools
Commercial: Acunetix, Burp Suite Professional, Netsparker, Qualys Web App Scanning.
Open Source: OWASP ZAP, Nikto, Arachni, Wapiti.
Cloud-based: Detectify, HackerOne Assets, Snyk.
Compliance and Standards
PCI DSS: Requirement 6.6 requires web application vulnerability scanning at least annually and after any changes.
OWASP Testing Guide: Provides a methodology for manual and automated testing.
NIST SP 800-115: Technical Guide to Information Security Testing and Assessment.
Integration with CI/CD
Modern DevSecOps pipelines integrate web scanners (e.g., OWASP ZAP in Jenkins) to perform automated scans on every build. Scanners can be configured to fail builds if critical vulnerabilities are found.
Crawl the Application
The scanner starts by fetching the target URL and parsing the response HTML. It extracts all links (`<a href>`), forms (`<form action>`), and resources (scripts, images). It also checks for `robots.txt` and sitemap XML files. The scanner then recursively follows discovered links up to a configured depth (default 3-5). For JavaScript-heavy pages, it may use a headless browser to execute JS and discover dynamically generated links. The result is a comprehensive site map of all accessible endpoints.
Identify Technologies
Using HTTP response headers (e.g., `Server`, `X-Powered-By`), HTML meta tags, and file extensions, the scanner identifies the web server (Apache, Nginx), application framework (Ruby on Rails, Django), CMS (WordPress, Drupal), and libraries (jQuery, Bootstrap). Version information is extracted to match against known vulnerabilities in databases like CVE. This helps tailor subsequent attack payloads and prioritize tests.
Test Input Points
For each discovered parameter (GET, POST, cookies, headers), the scanner sends a series of payloads designed to trigger common vulnerabilities. For SQL injection, it sends payloads that cause database errors or time delays. For XSS, it sends script payloads and checks if they appear in the response unescaped. The scanner also tests for path traversal by sending `../` sequences and checking for file contents in responses. Each test is logged with request and response details.
Analyze Responses
The scanner examines each response for indicators of successful exploitation. For SQL injection, it looks for database error messages (e.g., "You have an error in your SQL syntax"), or uses boolean-based and time-based blind techniques. For XSS, it checks if the payload is reflected in the response body without proper encoding. For path traversal, it checks for file contents like "root:x:0:0:root". The scanner also monitors response time for time-based attacks. Findings are correlated with a knowledge base of vulnerability signatures.
Report Findings
All confirmed vulnerabilities are compiled into a report with severity ratings (Critical, High, Medium, Low, Info). Each finding includes: vulnerability type, affected URL, parameter, request/response evidence, CVSS score if available, and remediation steps. Reports can be exported in HTML, PDF, XML, or JSON formats. The scanner may also provide a risk score for the overall application based on number and severity of findings. False positives should be manually verified before action.
Scenario 1: E-commerce PCI DSS Compliance
A large e-commerce company must comply with PCI DSS Requirement 6.6, which mandates regular web application scanning. They use a commercial scanner (e.g., Acunetix) to scan their production website quarterly and after any major code changes. The scanner is configured with authenticated access to test shopping cart and checkout flows. During one scan, it discovers a critical SQL injection in the product search parameter. The development team fixes it within the required 30-day remediation window. The scanner is also used to verify that security headers (HSTS, CSP) are present. A common issue is that the scanner's aggressive crawling causes high load on the database, so they schedule scans during off-peak hours and limit concurrent requests to 5.
Scenario 2: DevSecOps CI/CD Pipeline
A SaaS startup integrates OWASP ZAP into their Jenkins pipeline. Every code commit triggers a build, and after deployment to a staging environment, ZAP runs an automated scan against the new build. If critical vulnerabilities are found, the build is failed and the developer is notified. The scan configuration includes a context that defines login credentials and excludes logout pages. They use the ZAP API to generate reports in JSON format, which are parsed by a custom dashboard. A challenge is that false positives from scanner noise (e.g., XSS in error messages) require manual triage, so they maintain a list of known false positives to suppress. Over time, they reduce the number of true vulnerabilities from dozens per sprint to near zero.
Scenario 3: Penetration Testing Support
A penetration testing firm uses Burp Suite Professional to manually test web applications. They first use the automated scanner to quickly identify low-hanging fruit, then manually verify and exploit complex vulnerabilities. For a client's banking application, the scanner found reflected XSS in the login page, but manual testing revealed a stored XSS in the transaction comments that the scanner missed. The scanner's report serves as a baseline, but the final penetration test report includes both automated and manual findings. Misconfiguration of the scanner's scope once caused it to crawl the client's production environment instead of the test environment, resulting in a temporary outage. They now always verify the target URL before starting.
What CS0-003 Tests
This topic falls under Domain 2: Vulnerability Management, Objective 2.1: Given a scenario, analyze the output from a vulnerability scanning tool. The exam expects you to:
Interpret scan results from tools like Nikto, OWASP ZAP, or Burp Suite.
Identify false positives and false negatives.
Prioritize vulnerabilities based on CVSS scores and business impact.
Recommend appropriate remediation actions.
Understand when to use authenticated vs. unauthenticated scanning.
Common Wrong Answers
Choosing 'Network Vulnerability Scanner' over 'Web Application Scanner': Candidates often confuse network scanners (e.g., Nessus) with web app scanners. Network scanners check open ports and service versions, not web-specific flaws like SQLi or XSS. The exam may present a scenario about a web app and ask which tool to use.
Assuming All Scanners Find All Vulnerabilities: A common trap is thinking a scanner will find every vulnerability, especially business logic flaws. The exam tests that scanners have limitations and that manual testing is still required.
Ignoring the Need for Authentication: Many candidates forget that scanners need to be authenticated to test protected areas. An exam question might show a scan that found no issues, but the answer is that the scanner was not logged in.
Misinterpreting CVSS Scores: The exam may ask which vulnerability to fix first. Candidates might pick the one with the highest CVSS score without considering the context (e.g., a critical vulnerability in a low-risk area vs. a high vulnerability in a critical asset).
Specific Numbers and Terms
CVSS v3.1: Understand the scoring ranges (0.0-3.9 Low, 4.0-6.9 Medium, 7.0-8.9 High, 9.0-10.0 Critical).
OWASP Top 10: Know the latest version (2021) categories: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, etc.
PCI DSS 6.6: Requires web application scanning at least quarterly and after changes.
False Positive Rate: Some scanners have a 10-20% false positive rate; manual verification is essential.
Edge Cases
API Scanning: Modern web apps use APIs. The exam may test if a scanner can parse JSON/XML and test API endpoints.
Single-Page Applications: Scanners that cannot execute JavaScript will miss many vulnerabilities in SPAs.
Rate Limiting: If a scanner is too aggressive, the application may block it, resulting in incomplete scans.
How to Eliminate Wrong Answers
If the question mentions a web-specific vulnerability (e.g., XSS), eliminate network scanner options.
If the scan report shows no findings but the application has known issues, consider that authentication was missing or the scanner didn't crawl all pages.
For prioritization, look at CVSS score AND asset criticality; the highest score on a critical asset is top priority.
Web application scanners crawl and attack HTTP/HTTPS endpoints to find flaws like SQLi, XSS, and path traversal.
Scanners must be authenticated to test protected areas; unauthenticated scans miss many vulnerabilities.
False positives are common; always manually verify critical findings before acting.
CVSS v3.1 scores (0-10) help prioritize vulnerabilities; consider asset criticality alongside score.
OWASP Top 10 2021 is the standard reference for web app vulnerabilities.
PCI DSS 6.6 requires web application scanning at least quarterly and after changes.
Network scanners (e.g., Nessus) are not substitutes for web application scanners.
JavaScript-heavy SPAs require scanners with headless browser support to crawl fully.
These come up on the exam all the time. Here's how to tell them apart.
Authenticated Scanning
Provides access to protected pages and functionality
Finds vulnerabilities in user-specific areas (e.g., profile, settings)
Requires valid credentials and session management
May disrupt application state (e.g., creating records)
More thorough and realistic, simulating an insider threat
Unauthenticated Scanning
Only tests publicly accessible pages
Misses vulnerabilities behind login
Easier to set up (no credentials needed)
Lower risk of disrupting production data
Simulates an external attacker with no access
Mistake
A web vulnerability scanner will find all security flaws in an application.
Correct
Scanners only find known vulnerability patterns and cannot detect business logic flaws, chained attacks, or zero-day vulnerabilities. Manual testing is always required for comprehensive coverage.
Mistake
Unauthenticated scanning is sufficient for most web applications.
Correct
Many vulnerabilities exist only in authenticated portions of the application (e.g., user profile, admin panel). Without valid credentials, the scanner will miss these entirely, leading to a false sense of security.
Mistake
A scanner reporting no vulnerabilities means the application is secure.
Correct
A clean scan can result from incomplete crawling, lack of authentication, or the scanner not being configured to test all input types (e.g., JSON APIs). Always verify coverage.
Mistake
Web application scanners and network vulnerability scanners are interchangeable.
Correct
Network scanners (like Nessus) focus on open ports and service versions, while web scanners (like Burp Suite) test HTTP-specific vulnerabilities like SQLi and XSS. They serve different purposes and are complementary.
Mistake
All web application scanners produce the same results.
Correct
Different scanners have different crawling engines, payload sets, and detection algorithms. One scanner may find a vulnerability that another misses. Using multiple tools can improve coverage.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A web vulnerability scanner focuses on HTTP/HTTPS applications, testing for flaws like SQL injection, XSS, and insecure authentication. A network vulnerability scanner (e.g., Nessus) checks for open ports, outdated service versions, and misconfigurations at the network level. For the CS0-003 exam, remember that web scanners are for application-layer issues, while network scanners are for infrastructure issues.
Most scanners support form-based authentication, HTTP Basic, NTLM, and OAuth. You provide the login URL, credentials, and any required parameters. The scanner will then maintain a session cookie throughout the scan. In OWASP ZAP, you can record a login macro using the browser and replay it. Always verify that the scanner is properly authenticated by checking that it can access authenticated pages.
False positives are alerts that incorrectly indicate a vulnerability. For example, a scanner might report XSS when the payload is reflected in an error message but not executed due to proper encoding. To handle them, manually verify each finding by replicating the attack using tools like curl or a browser. Some scanners allow you to mark findings as false positives to suppress them in future scans.
For compliance (e.g., PCI DSS), scans are required at least quarterly and after any significant changes. In a DevSecOps environment, scans can be run on every build. For production, it's best to run scans during maintenance windows to avoid performance impact. The frequency depends on the application's risk profile and change rate.
The OWASP Top 10 is a list of the most critical web application security risks, updated every few years (latest: 2021). Scanners use it as a checklist for vulnerability types to test for. The exam may ask you to identify which OWASP category a given vulnerability falls under (e.g., SQL injection is A03 Injection).
Yes, aggressive scanning can cause denial of service, database corruption, or data loss. For example, SQL injection payloads might delete data, and high request rates can overwhelm the server. Always run scans on staging or test environments first, and use rate limiting. For production, schedule scans during low-usage periods and ensure the scanner is configured safely.
The Common Vulnerability Scoring System (CVSS) provides a numerical score (0-10) for vulnerabilities based on exploitability, impact, and other metrics. Scanners often include CVSS scores in reports. The exam expects you to use CVSS scores to prioritize remediation—higher scores should be fixed first, but also consider the asset's criticality.
You've just covered Web Application Vulnerability Scanning — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?