Overview
The Website Scanner performs security testing of web applications. It crawls your application, identifies technologies, and tests for vulnerabilities through active payload injection and passive response analysis. The Website Scanner is a vulnerability scanner: it actively tests web applications for security weaknesses. Discovered technologies are added to your Attack Surface. Identified vulnerabilities are reported as findings. The Website Scanner is a DAST (Dynamic Application Security Testing) tool: it tests your running application from the outside, without access to source code. If you need source code analysis, that requires a separate SAST tool.Supported targets
By default, the scanner follows redirects within the same domain (e.g.,
example.com to www.example.com). Configure this with Follow redirects. To scan a specific directory, include the path in the URL (e.g., https://example.com/app/).Scan types
Parameters comparison
Tests comparison
Initial tests
Passive checks
Active checks
Custom scan
Full control over scan parameters:- Select specific tests to run
- Configure spider settings
- Set request rate limits
- Configure authentication
- Define URL exclusions and inclusions
Initial tests
Initial tests identify technologies, configuration files, and potential entry points before active vulnerability testing begins. See the tests comparison table for Light vs Deep availability.Some initial tests like “Find interesting files” and “Information disclosure” may take several hours to complete as they test many potential paths.
Passive checks
Passive checks analyze server responses without sending attack payloads. These are safe and non-intrusive. See the tests comparison table for Light vs Deep availability.Active checks
Active checks send payloads to identify exploitable vulnerabilities. These tests are only available in Deep scan mode. See the tests comparison table for Light vs Deep availability.For request mutation behavior and recognizable markers, see scanner-generated request patterns.
Scanner-generated request patterns
This section explains how active checks modify requests and how to recognize common scan artifacts. It omits source-code locations, internal infrastructure details, and directly reusable exploit chains.Recognizable markers
Some checks add a short random marker to an existing value so the scanner can determine whether the application reflects or stores it.{random_hex_8} represents eight random lowercase hexadecimal characters. For example, a value beginning with New Folder may appear later with ptt and eight hexadecimal characters appended.
Other checks use similar temporary markers. Their exact value changes for each scan or request.
How requests are modified
If an appended value would exceed the supported parameter size, the scanner may use overwrite mode for that request.
Active-check behavior
Persistent-data risk
The scanner tests every eligible injection point it discovers. If an endpoint creates or updates data, a harmless-looking canary can be saved as part of that action. Before scanning:- Use a test environment when possible.
- Exclude state-changing routes that do not need testing, such as delete, logout, purchase, invitation, and messaging actions.
- Use test accounts and test data.
- Review created or modified records after the scan.
Coverage
This reference covers first-party request generation for:- Injection checks across browser, database, command, template, language, and XML contexts
- File inclusion, SSRF, deserialization, and prototype-pollution checks
- Authentication, session, object-access, and API field checks
- Header, redirect, CORS, HTTP method, discovery, and request-framing checks
OWASP Top 10 coverage
The Website Scanner’s active and passive checks cover most OWASP Top 10 (2021) categories. The table below maps each category to the relevant tests.Automated scanning cannot fully cover A01 or A04. Broken access control issues based on business context (such as one user accessing another user’s data) need manual testing. Insecure design flaws are not detectable by scanners. A09 requires inspecting server and application logging configuration directly.
Engine options
Engine options configure how the spider crawls your application to discover pages, forms, and functionality.Spidering approach
Limits
Included URLs
Add URLs to be included in the spidering process. This allows the scanner to reach endpoints that are hard to find automatically or are not linked with other endpoints. Enter one URL per line:Excluded URLs
Add URLs to be excluded from the spidering process. This stops the scanner from processing endpoints and limits the scope, making it useful when certain areas do not require scanning for vulnerabilities. Enter one URL per line:Subdomains in scope
Add subdomains of the target to be scanned if requests to them are found during the spidering process. This allows the scanner to expand its scanning scope to specific subdomains of the target. If left empty, only the subdomain api will be considered in scope. For example, ifhttp://example.com is the target, the subdomain api.example.com will be in scope by default.
Authentication
Configure authentication to test protected areas of your application. Authentication is available in Deep and Custom scan modes only.For detailed authentication configuration, see Authenticated scanning.
How it works
The Website Scanner works in these steps:- Fingerprinting: Identifies web server, technologies, and frameworks
- Crawling: Discovers pages, forms, and functionality using the selected spider approach. Uses the ML Classifier to filter out soft 404 false positives.
- Initial testing: Searches for sensitive files, admin panels, and configuration issues
- Passive analysis: Analyzes all responses for security issues without sending payloads
- Active testing: Injects payloads into parameters to test for vulnerabilities
- Reporting: Generates findings with evidence and remediation guidance
Follow-up actions
After identifying vulnerabilities:- Prioritize by severity: Address Critical and High findings first
- Validate findings: Use SQLi Exploiter to confirm SQL injection
- Test APIs: Run API Scanner for REST and GraphQL endpoints
- Check CMS: Use WordPress Scanner for WordPress sites
- Find hidden content: Run URL Fuzzer for additional discovery
- Schedule regular scans: Set up Scheduled scans for continuous monitoring