File: passive-scan-rules.md | Updated: 11/18/2025
You can specify a comma separated list of URL regex patterns using the rules.domains.trusted parameter via the Options âRule configurationâ panel. Any link URL that matches one of these patterns will be considered to be in a trusted domain and will therefore not be reported. Following rules supports Trusted Domains :
The following release status passive scan rules are included in this add-on:
This scan rule checks for the existence and validity of the X-Frame-Options header, or Content-Security-Policy âframe-ancestorsâ directive.
At MEDIUM and HIGH thresholds this only looks at non-error or non-redirect HTML responses.
At LOW threshold it looks at all text responses including errors and redirects.
The following conditions may result in an alert:
By default no alerts will be raised in the response includes a Content-Security-Policy âframe-ancestorsâ element as this take precedence over the X-Frame-Options header. However at LOW threshold the above issues will still be reported but at a LOW risk.
Latest code: AntiClickjackingScanRule.java
Alert ID: 10020
Check server responses for HTTP 500 - Internal Server Error type responses or those that contain a known error string.
Note: Matches made within script blocks or files are against the entire content not only comments.
Skips responses that contain ISO control characters (those which are likely binary files).
At HIGH Threshold donât alert on HTTP 500 (but do for other error patterns). Also, such known error strings are much less likely to be relevant in static pages like JS / CSS so these files are only scanned at LOW threshold.
For Internal Server Error (HTTP 500) the Alert is set to Low risk and in other case it is set to Medium risk.
Note: If the Custom Payloads add-on is installed you can add your own Application Error strings (payloads) in the Custom Payloads options panel. They will also be searched for in responses as theyâre passively scanned. Keep in mind that the greater the number of payloads the greater the amount of time needed to passively scan.
The Custom Payloads category for this rule is: Application-Errors.
It is also possible to add patterns to the xml/application_errors.xml file in ZAPâs user directory.
Latest code: ApplicationErrorScanRule.java
Alert ID: 90022 .
Big Redirect Detected (Potential Sensitive Information Leak)
This check predicts the size of various redirect type responses and generates an alert if the response is greater than the predicted size. A large redirect response may indicate that although a redirect has taken place the page actually contained content (which may reveal sensitive information, PII, etc.). It will also raise an alert if the body of the redirect response contains multiple HREFs.
Latest code: BigRedirectsScanRule.java
Alert ID: 10044 .
Checks âCache-Controlâ response headers against general industry best practice settings for protection of sensitive content.
At MEDIUM and HIGH thresholds only non-error or non-redirect text responses (excluding JavaScript and CSS) are considered.
At LOW threshold all responses are considered including errors and redirects.
Latest code: CacheControlScanRule.java
Alert ID: 10015 .
This check identifies responses where the HTTP Content-Type header declares a charset different from the charset defined by the body of the HTML or XML. When thereâs a charset mismatch between the HTTP header and content body Web browsers can be forced into an undesirable content-sniffing mode to determine the contentâs correct character set.
The scan rule handles various conditions depending on the Threshold set for the rule, as follows:
Further reference:
http://www.w3.org/TR/html401/charset.html#h-5.2.2
http://www.w3.org/TR/html5/document-metadata.html#charset
Latest code: CharsetMismatchScanRule.java
Alert ID: 90011 .
Content Security Policy (CSP) Header Not Set
This checks HTML response headers for the presence of a Content Security Policy header, or the response body for CSP specified via META tag.
By default this rule checks for the presence of the âContent-Security-Policyâ, âX-Content-Security-Policyâ, and âX-WebKit-CSPâ headers. Redirects and non-HTML responses are ignored except at the Low threshold.
If a âContent-Security-Policyâ header is not found, an alert is raised.
If an âX-Content-Security-Policyâ or âX-WebKit-CSPâ header is found, an INFO alert is raised. This may represent an outdated enforcement implementation.
If a âContent-Security-Policy-Report-Onlyâ header is found on a response an INFO alert is raised. This may represent an enforcement effort that is actively being refined or developed, or one which is only partially implemented.
Note: This rule does not perform any actual analysis of the specified policy, for that please ensure the CSP scan rule is enabled.
Latest code: ContentSecurityPolicyMissingScanRule.java
Alert ID: 10038 .
Raises an alert if the response is lacking a Content-Type header or if the header exists but the value is empty.
Latest code: ContentTypeMissingScanRule.java
Alert ID: 10019 .
Ensures that as cookies are set they are flagged HttpOnly. The HttpOnly flag indicates to browsers that the cookie being set should not be acted upon by client side script (such as JavaScript).
Latest code: CookieHttpOnlyScanRule.java
Alert ID: 10010 .
Cookies can be scoped by domain or path. This check is only concerned with domain scope.The domain scope applied to a cookie determines which domains can access it. For example, a cookie can be scoped strictly to a subdomain e.g. www.nottrusted.com, or loosely scoped to a parent domain e.g. nottrusted.com. In the latter case, any subdomain of nottrusted.com can access the cookie. Loosely scoped cookies are common in mega-applications like google.com and live.com.
Latest code: CookieLooselyScopedScanRule.java
Alert ID: 90033 .
This check looks at user-supplied input in query string parameters and POST data to identify where cookie parameters might be controlled. This is called a cookie poisoning attack, and becomes exploitable when an attacker can manipulate the cookie in various ways. In some cases this will not be exploitable, however, allowing URL parameters to set cookie values is generally considered a bug.
Latest code: UserControlledCookieScanRule.java
Alert ID: 10029 .
Looks for cookies set during HTTPS sessions, raises an alert for those that are set but do not include the secure flag. A cookie set with the secure flag will not be sent during a plain HTTP session.
Latest code: CookieSecureFlagScanRule.java
Alert ID: 10011 .
Cookie Without SameSite Attribute
This reports any cookies that:
Latest code: CookieSameSiteScanRule.java
Alert ID: 10054 .
Validates whether or not scripts are included from domains other than the domain hosting the content. By looking at the âsrcâ attributes of âscriptâ tags in HTML responses.
Allowed Cross-Domain scripts:
Latest code: CrossDomainScriptInclusionScanRule.java
Alert ID: 10017 .
Passively scan responses for Cross Domain MisConfigurations, which relax the Same Origin Policy in the web browser, for instance.
The current implementation looks at excessively permissive CORS headers.
Latest code: CrossDomainMisconfigurationScanRule.java
Alert ID: 10098 .
The Content Security Policy (CSP) passive scan rule parses and analyzes CSP headers and META definitions for potential misconfiguration or weakness. This rule leverages HtmlUnitâs htmlunit-csp library to perform itâs parsing and assessment of CSPs.
If a response has multiple CSPs they are analyzed individually, as there is no sure way to intersect/merge the policies and further different browsers have varying levels of CSP support and enforcement.
Latest code: ContentSecurityPolicyScanRule.java
Alert ID: 10055 .
This rule identifies âpotentialâ vulnerabilities with the lack of known CSRF countermeasures in HTML pages with forms.
The rule does not scan messages that are not HTML pages.
At HIGH alert threshold only scans messages which are in scope.
Post 2.5.0 you can specify a comma separated list of identifiers in the rules.csrf.ignorelist parameter via the Options âRule configurationâ panel. Any FORMs with a name or ID that matches one of these identifiers will be ignored when scanning for missing Anti-CSRF tokens. Only use this feature to ignore FORMs that you know are safe, for example search forms. Form element names are sorted and de-duplicated when they are printed in the ZAP Report.
Note:
]
Latest code: CsrfCountermeasuresScanRule.java
Alert ID: 100202 .
Passively scans responses for signatures that are indicative that Directory Browsing is possible.
Latest code: DirectoryBrowsingScanRule.java
Alert ID: 10033 .
Passively scans for password hashes disclosed by the web server.
Various formats are included, including some formats such as MD4, MD5, and SHA*, which are sometimes used for purposes other than to contain password hashes.
Note:
This scan rule will only analyze text responses, and only analyze JavaScript responses on LOW Threshold.
The selection of Hash patterns which are evaluated is tied to the Confidence we have in the pattern and the Threshold set for the scan rule. In other words: Low confidence patterns will only be included for evaluation at Low Threshold, etc.
Latest code: HashDisclosureScanRule.java
Alert ID: 10097 .
Heartbleed OpenSSL Vulnerability (Indicative)
Passively scans for HTTP header responses that may indicate that the server is vulnerable to the critical HeartBleed OpenSSL vulnerability.
Latest code: HeartBleedScanRule.java
Alert ID: 10034 .
This checks response headers for the presence of a server header that contains version details. At LOW Threshold will raise an alert based on presence of the header field whether or not a version string is detected.
Latest code: ServerHeaderInfoLeakScanRule.java
Alert ID: 10036 .
HTTP to HTTPS Insecure Transition in Form Post
This check looks for insecure HTTP pages that host HTTPS forms. The issue is that an insecure HTTP page can easily be hijacked through MITM and the secure HTTPS form can be replaced or spoofed.
Latest code: InsecureFormLoadScanRule.java
Alert ID: 10041 .
HTTPS to HTTP Insecure Transition in Form Post
This check identifies secure HTTPS pages that host insecure HTTP forms. The issue is that a secure page is transitioning to an insecure page when data is uploaded through a form. The user may think theyâre submitting data to a secure page when in fact they are not.
Latest code: InsecureFormPostScanRule.java
Alert ID: 10042 .
Information Disclosure: Debug Errors
This passive scan rule checks the content of web responses for known Debug Error message fragments. Access to such details may provide a malicious individual with means by which to further abuse the web site. They may also leak data not specifically meant for end user consumption.
Note: Javascript responses are only assessed at LOW threshold.
Latest code: InformationDisclosureDebugErrorsScanRule.java
Alert ID: 10023 .
Information Disclosure: In URL
Attempts to identify the existence of sensitive details within the visited URIs themselves (this may include parameters, document names, directory names, etc.).
Latest code: InformationDisclosureInUrlScanRule.java
Alert ID: 10024 .
Information Disclosure: Referrer
Identifies the existence of sensitive details within the Referrer header field of HTTP requests (this may include parameters, document names, directory names, etc.).
Note: In the case of suspected credit card identifiers in the Referrer value, the potential credit card numbers are looked up against a Bank Identification Number List (BINList). If a match is found the alert is raised at High confidence and additional details are added to the âOther Informationâ field in the alert, otherwise the alerts will have Medium confidence. See: binlist-data for more information.
Latest code: InformationDisclosureReferrerScanRule.java
Alert ID: 10025 .
Information Disclosure: Suspicious Comments
Analyzes web content to identify comments which contain potentially sensitive details. Which may lead to further attack or exposure of unintended data.
Note: The strings to look for can be extended by using the Custom Payloads add-on.
The Custom Payloads category for this rule is: Suspicious-Comments.
Latest code: InformationDisclosureSuspiciousCommentsScanRule.java
Alert ID: 10027 .
HTTP basic or digest authentication has been used over an unsecured connection. The credentials can be read and then reused by someone with access to the network.
Latest code: InsecureAuthenticationScanRule.java
Alert ID: 10105 .
The response contains a Java Server Faces (JSF) ViewState value that has no cryptographic protections.
Latest code: InsecureJsfViewStatePassiveScanRule.java
Alert ID: 90001 .
For content served via HTTPS analyse all the src attributes in the response looking for those sourced via plain HTTP.
Latest code: MixedContentScanRule.java
Alert ID: 10040 .
This raises an informational alert if a site appears to be a modern web application.
It does not indicate any potential vulnerabilities but it could indicate that the ajax spider might be more effective at exploring this site compared to the traditional spider.
Latest code: ModernAppDetectionScanRule.java
Alert ID: 10109 .
This check looks at user-supplied input in query string parameters and POST data to identify where open redirects might be possible. Open redirects occur when an application allows user-supplied input (e.g. http://nottrusted.com ) to control an off-site destination. This is generally a pretty accurate way to find where 301 or 302 redirects could be exploited by spammers or phishing attacks.
NOTE: For the purposes of the passive check the authority portion of the origin and destination were compared. Manual testing may be required to validate the impact of this finding.
Latest code: UserControlledOpenRedirectScanRule.java
Alert ID: 10028 .
PII is information like credit card number, SSN etc. This check currently reports only numbers which match credit card numbers and pass Luhn checksum, which gives high confidence, that this is a credit card number.
At MEDIUM and HIGH threshold it attempts to use three characters of context on each side of potential matches to exclude matches within decimal like content or content which includes underscores. At LOW threshold, alerts will be raised for such matches.
At MEDIUM and HIGH threshold, the following content types are evaluated:
Image and CSS files are always ignored. Every other content type is evaluated at LOW threshold. Additionally at LOW threshold the entire HTML response is evaluated.
Note: In the case of suspected credit card values, the potential credit card numbers are looked up against a Bank Identification Number List (BINList). If a match is found the alert is raised at High confidence and additional details are added to the âOther Informationâ field in the alert, otherwise the alerts will have Medium confidence. See: binlist-data for more information.
Latest code: PiiScanRule.java
Alert ID: 10062 .
Checks the response content for inclusion of RFC 1918 IPv4 addresses as well as Amazon EC2 private hostnames (for example, ip-10-0-56-78). This information can give an attacker useful information about the IP address scheme of the internal network, and might be helpful for further attacks targeting internal systems.
This passive scan rule may generate false positives in the case of larger dotted numeric strings, such as vp09.02.51.10.01.09.16, where the latter 4 octets appear to be a RFC 1918 IPv4 address. After review an analyst can mark such alerts as False Positives in ZAP. For handling during repeated scans the âContext Alert Filtersâ add-on could be leveraged.
This scan rule will only analyze text responses.
Latest code: InfoPrivateAddressDisclosureScanRule.java
Alert ID: 2 .
This scan rule detects content that has been served from a shared cache.
Latest code: RetrievedFromCacheScanRule.java
Alert ID: 10050 .
This checks to see if any links use a target attribute using âopenerâ keyword in the ârelâ attribute, as this may allow target pages to take over the page that opens them.
By default this rule will ignore all links that are in the same context as the page. At the LOW threshold it will only ignore links that are on the same host.
At HIGH threshold it will only report links that use the â_blankâ target.
This rule supports Trusted Domains , check âGeneral Configurationâ for more information.
Latest code: LinkTargetScanRule.java
Alert ID: 10108 .
Script Served From Malicious Domain (polyfill)
This checks for scripts being served from one of the âpolyfillâ domains, which are known to have been compromised.
It will raise an alert with a High confidence if a script is loaded from one of the malicious domains, and a Low confidence if it just finds an apparent reference to one of the malicious domains in the script contents.
The known malicious âpolyfillâ domains are:
Latest code: PolyfillCdnScriptScanRule.java
Alert ID: 10115 .
Server Leaks Information via âX-Powered-Byâ HTTP Response Header Field(s)
This checks response headers for the presence of X-Powered-By details.
Latest code: XPoweredByHeaderInfoLeakScanRule.java
Alert ID: 10037 .
This scan rule checks for the existence of session token type parameters being rewritten to the URL. To help reduce false positives the rule checks the length of the token value, if the value of the parameter is not greater than 8 characters in length then the parameter is ignored (i.e.: survey?sId=5 would not be flagged as vulnerable).
Latest code: InfoSessionIdUrlScanRule.java
Alert ID: 3 .
Strict Transport Security Header
This rule checks HTTPS responses for the presence of a HTTP Strict Transport Security (HSTS) header and tests for various implementation concerns, alerting if theyâre found. Alerts generated:
Redirects to HTTPS URLs on the same domain will only be reported at Low threshold.
Latest code: StrictTransportSecurityScanRule.java
Alert ID: 10035 .
A timestamp was disclosed by the application/web server.
At HIGH threshold this rule does not alert on potential timestamps that are not within a range of plus or minus one year.
At HIGH threshold this rule ignores timestamps in JavaScript files.
At MEDIUM threshold this rule does not alert on potential timestamps beyond 10 years.
At all thresholds, this rule will not alert on timestamps beyond the Y2038 epoch edge.
Latest code: TimestampDisclosureScanRule.java
Alert ID: 10096 .
This check looks at user-supplied input in query string parameters and POST data to identify where Content-Type or meta tag charset declarations might be user-controlled. Such charset declarations should always be declared by the application. If an attacker can control the response charset, they could manipulate the HTML to perform XSS or other attacks.
Latest code: UserControlledCharsetScanRule.java
Alert ID: 10030 .
User Controllable HTML Element Attribute (Potential XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where certain HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Latest code: UserControlledHTMLAttributesScanRule.java
Alert ID: 10031 .
User Controllable Javascript Event (XSS)
This check looks at user-supplied input in query string parameters and POST data to identify where certain HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting) that will require further review by a security analyst to determine exploitability.
Latest code: UserControlledJavascriptEventScanRule.java
Alert ID: 10043 .
If any context contains defined users this scan rule checks all responses for the presence of hashed values representing those usernames.
Note: If the Custom Payloads add-on is installed you can add your own Username strings (payloads) in the Custom Payloads options panel. They will also be hashed and searched for in responses as theyâre passively scanned. Keep in mind that the greater the number of payloads the greater the amount of time needed to passively scan. (The default payloads are âAdminâ and âadminâ.)
The Custom Payloads category for this rule is: Username-Idor.
Discovery of any such value may represent an Insecure Direct Object Reference (IDOR) vulnerability. Alerts are only raised as informational items as further manual testing is required in order to confirm and assess impact.
This scan rule will only analyze text responses.
Latest code: UsernameIdorScanRule.java
Alert ID: 10057 .
Attempts to identify VIEWSTATE parameters and analyze said parameters for various best practices or protective measures such as:
The âViewstate without MAC Signature (Unsure)â alert will only be raised at LOW threshold.
Latest code: ViewstateScanRule.java
Alert ID: 10032 .
X-AspNet-Version Response Header
This checks response headers for the presence of X-AspNet-Version/X-AspNetMvc-Version details.
Latest code: XAspNetVersionScanRule.java
Alert ID: 10061 .
X-Backend-Server Header Information Leak
This checks response headers for the presence of X-Backend-Server details.
Latest code: XBackendServerInformationLeak.java
Alert ID: 10039 .
X-ChromeLogger-Data Header Information Leak
This checks response headers for the presence of X-ChromeLogger-Data or X-ChromePhp-Data details.
Latest code: XChromeLoggerDataInfoLeakScanRule.java
Alert ID: 10052 .
This scan rule check for the Anti-MIME-Sniffing header X-Content-Type-Options and ensures it is set to ânosniffâ.
At MEDIUM and HIGH thresholds this rule does not alert on client or server error responses or redirects.
At LOW threshold it will alert on all responses including errors and redirects.
Latest code: XContentTypeOptionsScanRule.java
Alert ID: 10021 .
X-Debug-Token Information Leak
This checks response headers for the presence of X-Debug-Token and X-Debug-Token-Link details. Which indicates the use/exposure of Symfonyâs Profiler. Symfonyâs Profiler provides access to a significant amount of information of interest to malicious individuals and Security Testers.
Latest code: XDebugTokenScanRule.java
Alert ID: 10056 .
This checks to make sure you are using the latest version of ZAP.
If your ZAP install is out of date then it will raise one alert on each domain with a severity based on how many versions out of date it is.
Latest code: ZapVersionScanRule.java
Alert ID: 10116 .