Website Scanner

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

Target type	Examples
URL	`https://example.com`, `https://app.example.com/admin`

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

Mode	Description	Use case
Light	Fast, passive, non-intrusive scan	Quick reconnaissance
Deep	All tests enabled	Full security audit
Custom	User-configured tests and options	Targeted testing

Parameters comparison

Parameter	Light	Deep	Custom
Authentication	✗	✓	✓
Spidering depth	4	10	1-10
Maximum spider time	15 min	1 hour	10s-1h
Maximum IPs	10	1000	-
Spidering approach	Classic	Auto	Configurable
Requests per second	-	100	1-10,000

Tests comparison

Initial tests

Test	Light	Deep
Fingerprint Website	✓	✓
Server Software Vulnerabilities	✓	✓
Robots.txt	✓	✓
JavaScript Libraries	✗	✓
SSL/TLS Certificates	✓	✓
Client Access Policies	✓	✓
HTTP Debug Methods	✓	✓
Security.txt File Missing	✓	✓
CORS Misconfiguration	✗	✓
WAF Detection	✗	✓
Resource Discovery	✗	✓
Find Sensitive Files	✗	✓
Find Admin Consoles	✗	✓
Find Interesting Files	✗	✓
Information Disclosure	✗	✓
Software Identification	✗	✓
Misconfigurations	✗	✓
Find GraphQL Endpoint	✗	✓
Fuzz OpenAPI Locations	✗	✓

Passive checks

Test	Light	Deep
Security Headers	✓	✓
Cookie Security	✓	✓
Directory Listing	✓	✓
Secure Communication	✓	✓
Weak Password Submission	✓	✓
Commented Code/Error Codes	✓	✓
Clear Text Submission of Credentials	✓	✓
Verify Domain Sources	✓	✓
Mixed Encryptions Content	✓	✓
Sensitive Data Crawl	✓	✓
Find Login Interfaces	✓	✓
Find File Upload	✓	✓
Path Disclosure	✓	✓
SQL Statement in Request Parameter	✓	✓
Password Returned in Later Response	✓	✓
Session Token in URL	✓	✓
API Endpoints	✓	✓

Active checks

Test	Light	Deep
SQL Injection	✗	✓
XSS	✗	✓
Local File Inclusion	✗	✓
OS Command Injection	✗	✓
Server Side Request Forgery (SSRF)	✗	✓
Open Redirect	✗	✓
Broken Authentication	✗	✓
PHP Code Injection	✗	✓
Server-Side JavaScript Code Injection	✗	✓
Ruby Code Injection	✗	✓
Python Code Injection	✗	✓
Perl Code Injection	✗	✓
Log4j Remote Code Execution	✗	✓
Server-Side Template Injection (SSTI)	✗	✓
XML External Entity Injection (XXE)	✗	✓
ViewState Remote Code Execution	✗	✓
Client-Side Prototype Pollution	✗	✓
Exposed Backup Files	✗	✓
Request URL Override	✗	✓
HTTP Request Smuggling	✗	✓
Cross-Site Request Forgery (CSRF)	✗	✓
Insecure Deserialization	✗	✓
NoSQL Injection	✗	✓
Session Fixation	✗	✓
Enumerable Parameter (IDOR)	✗	✓
JWT Weaknesses	✗	✓
Response Header Injection	✗	✓

The Deep scan performs active vulnerability testing and generates significant network traffic (~10,000+ HTTP requests). Most correctly configured security monitoring systems will detect this scan. Do not use it if you don’t have proper authorization from the target website owner.

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.

Test	Description
Fingerprint Website	Identifies web server software, frameworks, CMS platforms, and other technologies using Wappalyzer
Server Software Vulnerabilities	Checks if detected software versions have known CVEs in vulnerability databases
Robots.txt	Analyzes robots.txt for sensitive paths, directories, and disallowed content
JavaScript Libraries	Identifies outdated JavaScript libraries with known vulnerabilities (jQuery, Angular, etc.)
SSL/TLS Certificates	Validates certificate configuration, expiration, trust chain, and common SSL issues
Client Access Policies	Checks crossdomain.xml and clientaccesspolicy.xml for overly permissive cross-domain rules
HTTP Debug Methods	Tests if TRACE/TRACK methods are enabled, which can enable cross-site tracing (XST) attacks
Security.txt File Missing	Checks for security.txt file per RFC 9116 that helps security researchers report issues
CORS Misconfiguration	Tests Cross-Origin Resource Sharing headers for overly permissive or insecure configurations
WAF Detection	Detects a Web Application Firewall in front of the website and looks for an origin IP that bypasses it
Resource Discovery	Fuzzes for common directories, files, and endpoints using extensive wordlists
Find Sensitive Files	Searches for backup files (.bak, .old), configuration files, and credential files
Find Admin Consoles	Discovers administrative interfaces like /admin, /wp-admin, /phpmyadmin, etc.
Find Interesting Files	Searches for files that may reveal information: logs, database dumps, git repositories
Information Disclosure	Looks for exposed debug information, stack traces, error details, and internal paths
Software Identification	Identifies specific software components, plugins, and their versions
Misconfigurations	Detects common web server and application misconfigurations that could lead to security issues
Find GraphQL Endpoint	Discovers GraphQL API endpoints and checks for exposed introspection queries
Fuzz OpenAPI Locations	Searches common locations for OpenAPI/Swagger specification files (openapi.json, swagger.yaml, etc.)
Flowmapper	Uses an AI browser agent to navigate the site and discover endpoints that traditional crawling misses

Technology and version detection

The Website Scanner uses Wappalyzer to identify technologies from clues in the site’s responses. A technology can be detected without its version if the site does not expose version details, such as in a response header. In that case, the scan may report the technology but not detect the PHP version, for example. Server Software Vulnerabilities checks need a detected version to match against known CVEs, so no version-based match is available for that technology. Other Website Scanner checks still run.

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.

Test	Description
Security Headers	Checks for CSP, HSTS, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, and other security headers
Cookie Security	Validates Secure, HttpOnly, and SameSite cookie attributes to prevent session hijacking
Directory Listing	Detects directory indexes that expose file listings to attackers
Secure Communication	Checks for HTTPS enforcement, HSTS, and secure transport configuration
Weak Password Submission	Checks if passwords are submitted over unencrypted HTTP connections
Commented Code/Error Codes	Finds debug information, stack traces, HTML comments, and error messages in responses
Clear Text Submission of Credentials	Detects credentials transmitted without TLS encryption
Verify Domain Sources	Checks for resources (scripts, styles) loaded from untrusted third-party domains
Mixed Encryptions Content	Detects HTTP resources loaded on HTTPS pages, which can be intercepted
Sensitive Data Crawl	Identifies sensitive information like emails, phone numbers, and API keys in page content
Find Login Interfaces	Discovers login pages, authentication forms, and password reset functionality
Find File Upload	Identifies file upload functionality that could be exploited for malware upload
Path Disclosure	Detects exposed filesystem paths in error messages and responses
SQL Statement in Request Parameter	Detects SQL queries passed in URL parameters, indicating potential misconfiguration
Password Returned in Later Response	Checks if submitted passwords appear in subsequent server responses
Session Token in URL	Detects session IDs passed in URLs, which can be leaked via referer headers or logs
API Endpoints	Identifies API endpoints discovered during crawling for further testing

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.

Active checks send attack payloads to your application. Only run these against systems you have explicit authorization to test.

For request mutation behavior and recognizable markers, see scanner-generated request patterns.

Test	Description
SQL Injection	Tests for SQL injection flaws in parameters that allow database queries to be manipulated
XSS	Tests for reflected, stored, and DOM-based cross-site scripting vulnerabilities
Local File Inclusion	Tests for path traversal (../) and local file read vulnerabilities (LFI)
OS Command Injection	Tests for command execution on the underlying operating system via shell metacharacters
Server Side Request Forgery (SSRF)	Tests if the server can be tricked into making requests to internal resources or third parties
Open Redirect	Tests for URL redirect vulnerabilities that can be abused for phishing attacks
Broken Authentication	Tests for authentication bypass, weak credentials, and session management flaws
PHP Code Injection	Tests for PHP code execution via parameters (eval, include, etc.)
Server-Side JavaScript Code Injection	Tests for Node.js/JavaScript code execution on the server
Ruby Code Injection	Tests for Ruby code execution via ERB templates or eval
Python Code Injection	Tests for Python code execution via eval, exec, or template injection
Perl Code Injection	Tests for Perl code execution via backticks or system calls
Log4j Remote Code Execution	Tests for Log4Shell (CVE-2021-44228) and related Log4j vulnerabilities
Server-Side Template Injection (SSTI)	Tests for template engine exploitation in Jinja2, Twig, Freemarker, Velocity, etc.
XML External Entity Injection (XXE)	Tests for XXE attacks that can read local files or perform SSRF via XML parsers
ViewState Remote Code Execution	Tests for .NET ViewState deserialization leading to remote code execution
Client-Side Prototype Pollution	Tests for JavaScript prototype pollution that can lead to XSS or RCE
Exposed Backup Files	Actively searches for backup files (.bak, ~, .swp) with sensitive content
Request URL Override	Tests for host header injection and X-Forwarded-Host override attacks
HTTP Request Smuggling	Tests for CL.TE and TE.CL request smuggling between front-end and back-end servers
Cross-Site Request Forgery (CSRF)	Tests for missing or weak CSRF token protections on state-changing requests
Insecure Deserialization	Tests for unsafe deserialization in Java, PHP, Python, and .NET leading to RCE
NoSQL Injection	Tests for injection in MongoDB, CouchDB, and other NoSQL databases
Session Fixation	Tests if the application accepts externally set session identifiers
Enumerable Parameter (IDOR)	Tests for insecure direct object references by manipulating ID parameters
JWT Weaknesses	Tests for JWT algorithm confusion (none, HS256/RS256), weak secrets, and expiration issues
Response Header Injection	Tests for CRLF injection in HTTP headers that can lead to cache poisoning or XSS

Active checks can create persistent records, delay responses, or trigger application behavior. A modified value sent to a state-changing endpoint may remain after the scan finishes. Exclude destructive endpoints before you start a scan.

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.

ptt{random_hex_8}

{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

Mutation	Behavior	Where it may appear
Append	Adds a test value after the original value	Query parameters, form fields, JSON values, cookies
Overwrite	Replaces the original value for one request	Parameters, headers, identifiers
Remove	Sends the request without a selected value	Authentication and CSRF checks
Add	Introduces a temporary field, parameter, or header	API and header checks
Rewrite	Changes the method, URL, body, or protocol framing	Redirect, method, and HTTP checks

If an appended value would exceed the supported parameter size, the scanner may use overwrite mode for that request.

Active-check behavior

Check family	What the scanner changes	Example	Possible impact
XSS and client-side templates	Adds a random canary and a context-specific test value	`New Folder` becomes `New Folderptt1a2b3c4d`	A marker may be reflected or stored
SQL and NoSQL injection	Changes delimiters, operators, conditions, or timing values	`product_id=42` is compared with a controlled test value	A vulnerable endpoint may delay or return different data
File inclusion and XML parsing	Submits controlled path or document references	`page=help` becomes `page={controlled_test_path}`	A vulnerable parser may disclose local content
OS command and code injection	Sends controlled expressions that produce a verifiable result	`host=example.com` becomes `host={validation_expression}`	A vulnerable endpoint may execute a command or expression
SSRF and OOB checks	Uses a scan-specific callback destination	`url=https://example.com` becomes `url={scan_callback_url}`	The target may make an outbound request
Template injection and deserialization	Sends a format-specific validation object or expression	`template=hello` becomes `template={engine_validation_value}`	A vulnerable runtime may evaluate it
Prototype pollution	Adds temporary object properties and performs a reset check	A JSON body receives a temporary property with a scan marker	Process behavior may change until reset or restart
HTTP request smuggling	Sends protocol-level framing variations on dedicated connections	A `POST` request is repeated with deliberately inconsistent framing	Intermediaries may handle request boundaries differently
Headers, redirects, and CORS	Changes selected headers, origins, or redirect values	`Origin` is replaced with `https://scanner-example.invalid`	Responses may contain injected headers or redirects
JWT, CSRF, sessions, and IDOR	Replaces, removes, or adjusts authentication and identifier values	`resource_id=100` is also tested as `99` and `101`	The scanner may reach another object or authorization path
API mass assignment	Adds a candidate field with two controlled values	`{"name":"Test"}` receives `"test_field":"scan-marker"`	A write endpoint may persist the test value
Discovery and method checks	Requests common paths or uses diagnostic HTTP methods	The scanner requests `GET /openapi.json`	The application receives additional read requests

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

Passive checks do not generate attack values. They inspect responses from normal crawling and other scanner components.

OWASP Top 10 coverage

The Website Scanner’s active and passive checks cover some issues in each OWASP Top 10:2025 category. The table lists the related checks. A category marked as covered does not mean the scanner can find every issue in it, and a clean scan does not prove an application is secure.

OWASP Top 10 (2025)	Coverage	Relevant tests
A01: Broken Access Control	Partial	Enumerable Parameter (IDOR), CSRF, Session Fixation, Request URL Override, SSRF
A02: Security Misconfiguration	Broad	Security Headers, CORS Misconfiguration, HTTP Debug Methods, Directory Listing, Information Disclosure, Misconfigurations, Secure Communication
A03: Software Supply Chain Failures	Limited	Server Software Vulnerabilities and JavaScript Libraries identify known vulnerabilities in detected components. The scanner does not assess build systems, dependency provenance, or distribution pipelines
A04: Cryptographic Failures	Partial	SSL/TLS Certificates, Secure Communication, Cookie Security, Clear Text Submission of Credentials, Mixed Encryption Content
A05: Injection	Broad	SQL and NoSQL Injection, OS Command Injection, XSS, PHP/JavaScript/Ruby/Python/Perl Code Injection, XXE, SSTI, Log4j RCE, and other injection checks
A06: Insecure Design	Limited	Scanner checks can identify specific implementation weaknesses, but business logic and design assumptions require manual review
A07: Authentication Failures	Partial	Broken Authentication, JWT Weaknesses, Weak Password Submission, Session Fixation, Session Token in URL
A08: Software or Data Integrity Failures	Partial	Insecure Deserialization, ViewState RCE, Client-Side Prototype Pollution, Verify Domain Sources
A09: Security Logging and Alerting Failures	No	Logging, alerting, and incident response configuration require manual review
A10: Mishandling of Exceptional Conditions	Limited	Path Disclosure and Commented Code/Error Codes can expose some error handling issues; application-specific failure behavior requires manual testing

The scanner cannot determine whether access rules fit your business requirements, whether software supply-chain controls are trustworthy, or whether logging and alerting lead to the right response. Review these areas manually, using authorized test accounts and workflows. The Website Scanner also maps findings to OWASP Top 10 (2021):

OWASP Top 10 (2021)	Coverage	Relevant tests
A01: Broken Access Control	Partial	IDOR, CSRF, Session Fixation, Broken Authentication
A02: Cryptographic Failures	Partial	Secure Communication, Cookie Security, Clear Text Submission of Credentials, Mixed Content, SSL/TLS Certificates
A03: Injection	Broad	SQL Injection, NoSQL Injection, OS Command Injection, XSS, PHP/JS/Ruby/Python/Perl Code Injection, XXE, SSTI, Log4j RCE
A04: Insecure Design	No	Business logic flaws require manual testing
A05: Security Misconfiguration	Broad	Security Headers, CORS Misconfiguration, HTTP Debug Methods, Directory Listing, Information Disclosure, Misconfigurations
A06: Vulnerable and Outdated Components	Yes	Server Software Vulnerabilities, JavaScript Libraries
A07: Identification and Authentication Failures	Partial	Broken Authentication, JWT Weaknesses, Session Token in URL, Weak Password Submission, Session Fixation
A08: Software and Data Integrity Failures	Partial	Insecure Deserialization, ViewState RCE, Client-Side Prototype Pollution
A09: Security Logging and Monitoring Failures	No	Requires manual review of server and application logging configuration
A10: SSRF	Yes	SSRF, Request URL Override

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

Approach	Description	Use case
Auto	Automatically detects and uses the best approach	Most applications (default)
Classic	Traditional HTML parsing and link following	Standard websites
SPA	JavaScript-aware crawling with browser rendering	React, Angular, Vue apps

Limits

Setting	Description	Range	Default
Spidering Depth	Maximum crawl depth measured by the number of slashes in the URL	1-10	10
Maximum spidering time	Maximum spider duration in seconds	10-3600	3600 (1 hour)
Requests per second	Rate limit for requests (actual speed may be lower)	1-10,000	100

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:

https://www.example.com/hidden-page
https://www.example.com/service-endpoint/

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:

https://www.example.com/docs
https://www.example.com/blog/

Always exclude logout URLs, delete actions, and other destructive endpoints to maintain scan stability. Example exclusions: /logout, /signout, /delete, /remove.

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, if http://example.com is the target, the subdomain api.example.com will be in scope by default.

Additional request headers

Send fixed HTTP headers with every request of the scan, without authenticating. Use them when a rate limiter, WAF, CDN, or reverse proxy in front of your application only lets the scanner through with a bypass or routing header. Additional request headers are available in Custom scan mode only. Enter one header per line:

X-Pagely-Skip-Ratelimit: <token>
X-Custom-Routing: customer-a

Unlike Header authentication, additional request headers don’t run the authentication check and don’t mark the scan as authenticated. You can use both at the same time. If a header is set in both places, the value from Authentication wins.

The headers are sent with every request the scan makes, including requests to third-party resources and redirects, the same way Header authentication headers are.

You can set up to 10 headers. Headers that the scanner manages itself are rejected: Host, Content-Length, Transfer-Encoding, Connection, Keep-Alive, Proxy-Connection, TE, Trailer, and Upgrade. Header values aren’t saved with the scan details, so add them again when you rescan. Scheduled scans keep them. In the API, use the additional_request_headers field of tool_params.

Authentication

Configure authentication to test protected areas of your application. Authentication is available in Deep and Custom scan modes only.

Method	Description	Use case
Automatic login form	Scanner fills and submits your login form	Simple login pages
Recorded authentication	Replay Chrome Recorder JSON file	Complex multi-step logins
Cookie authentication	Use existing session cookies	Any cookie-based auth
Header authentication	Send custom headers (JWT, API keys)	API and token-based auth

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

Intro

Core

Tools reference

Capabilities

AI

Account & billing

Overview

Supported targets

Scan types

Parameters comparison

Tests comparison

Custom scan

Initial tests

Technology and version detection

Passive checks

Active checks

Scanner-generated request patterns

Recognizable markers

How requests are modified

Active-check behavior

Persistent-data risk

Coverage

OWASP Top 10 coverage

Engine options

Spidering approach

Limits

Included URLs

Excluded URLs

Subdomains in scope

Additional request headers

Authentication

How it works

Follow-up actions

​Overview

​Supported targets

​Scan types

​Parameters comparison

​Tests comparison

​Custom scan

​Initial tests

​Technology and version detection

​Passive checks

​Active checks

​Scanner-generated request patterns

​Recognizable markers

​How requests are modified

​Active-check behavior

​Persistent-data risk

​Coverage

​OWASP Top 10 coverage

​Engine options

​Spidering approach

​Limits

​Included URLs

​Excluded URLs

​Subdomains in scope

​Additional request headers

​Authentication

​How it works

​Follow-up actions

Overview

Supported targets

Scan types

Parameters comparison

Tests comparison

Custom scan

Initial tests

Technology and version detection

Passive checks

Active checks

Scanner-generated request patterns

Recognizable markers

How requests are modified

Active-check behavior

Persistent-data risk

Coverage

OWASP Top 10 coverage

Engine options

Spidering approach

Limits

Included URLs

Excluded URLs

Subdomains in scope

Additional request headers

Authentication

How it works

Follow-up actions