Advanced Configuration

Default: False

Memory Consumption Limit

If AppScan memory usage reaches this threshold, ADAC will try to reduce resource usage by limiting the number of threads.

Default = 1000 MB

Multi-step playback no-interaction timeout

The no-interaction timeout (in seconds) for stopping playback of a multi-step operation.

Default: 10

Number of browser instances allowed during Test Stage

Sets how many browser instances can be used during the Test stage of the scan.

Default = 5

If your site uses a client JavaScript code intensively, and as a result ADAC freezes during the scan, reduce this number.

Save screenshots in automatic Explore

ADAC can save a screenshot of every page it visits during automatic Explore, but this can impact performance and greatly increase the size of the temp folder where the data is saved.

C:\ProgramData\HCL\AppScan Standard\temp\[run number]
\AutoCrawler\dom-states\[page identifier]

The data is deleted when ADAC closes.

Default: False

Change to True if you want to review these screenshots to verify the automatic Explore stage. Note that when you close ADAC the screenshots are not saved.

Timeout for single login attempt

The time (in seconds) that ADAC waits for the browser to replay a single action-based login attempt before forcing the browser to close.

Default: 120

Use AppScan Chromium

AppScan uses Chromium by default. If necessary, you can change this setting to "True" to use AppScan's own implementation of Chromium instead.

Default: True

Cognito Refresh Interval

The interval in seconds between requests for Cognito key updates.

Default: 270

Accept-Language request-header value

The string sent for the Accept-Language header in all HTTP requests.

If not defined by the user, AppScan® will use the value that was sent by the browser the first time in this scan that the user opened it to record the login procedure, a multi-step operation, or to view a page.

Default: en-US

During the Explore stage AppScan® might receive an unexpected response, due to the Internet Explorer header value. In such cases you should check which value should be used in the Accept-Language header when interacting with the site, and define it in this setting (or in Internet Explorer).

Force an HTTP request without parameters to every form action

In some cases, server-side logic may behave differently when a form submission without parameters is received.

When set to True, AppScan will send an additional request, without parameters, to every form. This may result in the return of custom error pages with links to additional web pages and functionality.

Default: True

If you notice, when viewing traffic during the scan, that form submissions without parameters cause timeouts or crash the application, you may decide to set this option to False.

HTTP preference

Default: 1

Important: AppScan can scan HTTP/2 websites only if they also use TLS 1.2. Non-HTTPS websites, and websites that use earlier versions of TLS, will be scanned with HTTP/1.1.

Include a Content-Length header in all requests

Some servers require a Content-Length header even in requests for which message body semantics are not defined (such as the GET method). If missing, the server will reject the request. To solve this, AppScan will add a Content-Length header to requests that do not have one.

When True, AppScan will add a Content-Length header to any request that does not already include one.

Default: True

If the default behavior causes 400 Bad Request responses from the server, because it does not expect a Content-Length header for a GET request (since GET requests do not typically include a request body), change this setting to False.

Include AppScan debug headers in all requests

When set to True, an HTTP header is added to all requests sent by AppScan® to the site. The header name is "X-AppScan-Debug", and its value includes information about AppScan's reason for sending this particular request (Explore, Test, Login Playback, Server Down Check, and so on).

Default: False

Configuring the scan to send "X-AppScan-Debug" headers can be useful in tracking AppScan® traffic in external tools such as web debuggers, proxies, analyzers and sniffers.

` include special headers such as this.

Maximum response length

AppScan® truncates long responses to avoid memory consumption issues. This setting defines the maximum allowed response length in Megabytes. Longer responses are treated as errors.

Default: 8

If AppScan® seems to miss links or get out of session, and the application is known to send long responses, increasing the maximum response length may solve the problem.

Remove 'Accept-Encoding' header

AppScan® does not support all encodings, and removes the encodings it does not support. If this setting is enabled AppScan® will remove the entire header and not just the encodings it does not support.

Default: True

If the server rejects AppScan's requests, returns unexpected responses, or AppScan® is unable to maintain session, you should check the traffic log and compare the requests AppScan® sends with those of your usual browser. If the Accept-Encoding header is different or missing in your browser, you should enable this setting.

Reuse server connections

By default, AppScan closes TCP connections after use, since open connections, and saved data, may affect scan results.

When set to True, AppScan leaves connections open after use, and attempts to reuse open connections whenever possible.

Default: False

If there are network resource exhaustion errors on the web server, changing this setting to True may solve the problem.

Security package order

AppScan® supports Basic, Digest, NTML, Negotiate, and Kerberos HTTP authentication. If you want to force AppScan to use or not use a specific method, or apply an order of preference for method selection when the site/proxy allows more than one, you can edit this value.

For example, if you want to allow only NTLM and Basic, and prefer to use NTLM if available, edit this string to: ntlm, basic

Default: basic, digest, ntlm, negotiate, kerberos

If your site uses a specific authentication method and AppScan® is denied access, defining the required method as the only method can solve the problem.

If you want to test your site with specific methods - say Basic and NTLM - you could configure one scan with Basic only, and another with NTLM only.

Slash Normaliz-ation

Normalize URLs by replacing two or more consecutive slashes with a single slash.

Default: True

If your site URLs utilize consecutive slashes, deactivate this setting.

TLS support

List which TLS protocols are allowed. AppScan will choose the most secure protocol allowed by the user’s configuration and by the server. The value of this field should be a comma-separated list.

If necessary, SSL 3.0 can be added to the list of allowed protocols.

Treat error response as valid

AppScan® treats error pages differently to regular pages (for example, by not parsing for links). This setting lets you tell AppScan® to treat error pages as regular pages for the starting URL only, or always.

When set to 0, AppScan® treats all error responses as invalid.

When set to 1, AppScan® treats all error responses to the starting URL (4xx and 5xx) as valid

When set to 2, AppScan® treats all error responses as valid for both regular pages and the starting URL.

Default: 0

If your starting URL response is an error page, change the setting to 1.

If you want the scan to extract data from error pages, and test them, change this setting to 2.

Note that changing the default setting is likely to affect performance.

General:

Enable “Pattern for JS requests to be excluded from proxy filter”

Default: False

Encrypt sensitive data

When False, only password and TOTP secret key are encrypted in these files.

Default: True

Merge redundant tests

When set to True, AppScan sends only a single set of tests on two (or more) requests that are identical except for additional cookies. If set to False, all such requests will be tested separately.

Default: True

Changing this setting to False can impair performance; do so only if advised to by Support.

Pattern for JS requests to be excluded from proxy filter

A regular expression, applied to response headers, defining which JavaScript requests should not be filtered by the proxy content-type filter.

Default: Cache-Control:[ ]*([^\n\r]*)(no-store|no-cache|max-age=0)

Proxy file extension filter

A regular expression that defines file extensions which will be removed from the list of URLs that is saved when you record a login, Manual Explore or Multi-Step operation. If you remove an extension from the regexp., URLs ending with that extension will not be filtered out of recordings.

Default: "\.(zip|Z|tar|t?gz|sit|cab|pdf|

ps|doc|ppt|xls|rtf|dot|mp(p|t|d|e|a|3|

4|ga)|m4p|mdb|csv|pp(s|a)|xl(w|a)|

dbf|slk|prn|dif|avi|mpe?g|mov(ie)?|

qt|moov|rmi?|as(f|x)|m1v|wm(v|f|

a)|wav|ra|au|aiff|midi?|m3u|gif|

jpe?g|bmp|png|tif?f|ico|pcx|css|

xml)$"

In rare cases where you need a particular kind of file, such as a CAPTCHA image file, included in your Login recording for reference, you could remove its file extension (in this case jp?g) from the regular expression.

Sanitize logs

Removes sensitive information from logs.

Default: False

If you need to remove sensitive information from logs, activate this option and define the pattern to be removed in the "Sensitive information pattern" option.

Note that changing this setting does not affect logs already generated.

Sanitize reports

Removes sensitive information from reports.

Default: False

If you need to remove sensitive information from reports, activate this option and define the pattern to be removed in the "Sensitive information pattern" option.

Note that changing this setting does not affect reports already generated.

Sensitive Information pattern

A regular expression that defines one or more groups that will be filtered out of logs and reports, if the Sanitize Logs or Sanitize Reports options are activated.

Default: empty

If you need to remove sensitive information from reports or logs, activate the relevant option ("Sanitize logs" or "Sanitize reports"), and define one or more groups in a regular expression here.

The sensitive text is replaced with: **CONFIDENTIAL 1**, **CONFIDENTIAL 2**, and so on.

Sensitive parameter names

A regular expression that defines one or more parameter names that will not be displayed.

Default: refresh_token|secret|KeySecret|client_secret

Default: False

JavaScript™:

JavaScript™ link pattern

AppScan® uses a variety of patterns to identify links in JavaScript™ code. If your site uses unusual patterns they should be defined in this regular expression.

Default: empty

If AppScan® seems to miss links from your JavaScript™ code, and your site uses unusual JavaScript™ link patterns, define one or more patterns here to tell AppScan® what to search for.

Localization:

HTML encoding

Overrides the encoding defined in your site's HTML responses.

Default: empty

If the content of responses in the scan results looks distorted, this may mean that:

1) The encoding method was not correctly identified by AppScan®, or

2) The encoding method is incorrectly defined in your site's HTML

To solve 1: Select the correct method in the Explore Options drop-down list.

To solve 2: Enter the correct encoding method here.

Parameters & Cookies:

Exclude redundant JSON parameters from testing

JSON content type body can contain multiple values of a single parameter that need not be tested individually. When set to True, AppScan® attempts to identify redundant values and limit testing to a subset, reducing scan time.

Default: True

If you find that a particular, significant parameter was not tested, change the setting to False.

Exclude redundant XML parameters from testing

XML content type body can contain multiple values of a single parameter that need not be tested individually. When set to True, AppScan® attempts to identify redundant values and limit testing to a subset, reducing scan time.

Default: True

If you find that a particular, significant parameter was not tested, change the setting to False.

Track custom parameters in headers

This setting applies only to scans saved with ADAC v. 8.7.0.1 or earlier. In later versions the default behavior changed to True, and the setting is controlled for individual parameters and cookies in: Configuration > Parameters and Cookies > Parameter Definition > Tracking Options > Match: Header and Body (default) or Body only (see Parameter definition).

By default AppScan® (8.7.0.1 and earlier) searches for custom parameters only in the body of responses, not in their headers. If you change this setting to True, AppScan® will search in headers too.

Default: False

If AppScan® gets out of session due to changes to a parameter in the response header, changing this setting may solve the problem. Note that this may increase scan time.

Track dynamic parameters in Test stage only when inline content exists

Tracking dynamic parameters during the Test stage may result in performance problems. Therefore, by default, dynamic parameters are tracked during the Test stage only in responses with inline content.

Default: True

Change this setting to False only if this kind of tracking is essential.

Postman:

Login analysis sample size

When a Postman Collection is uploaded, AppScan analyzes it to try to identify an in-session pattern. AppScan uses this pattern to detect when it gets logged out during the scan. This setting defines how many requests from the collection are analyzed to try to identify a valid pattern.

Default: 7

If AppScan fails to identify a valid in-session pattern automatically, try increasing this value.

Server Down Detection:

Check for "server down" in Explore

Enables the sending of heartbeat requests to check for "Server Down" during Explore stage.

Default: True

If AppScan® gets server-down errors during the Explore stage, and the server is not down, this may be due to the server blocking the frequent heartbeat requests.

If AppScan® frequently gets out-of-session during scanning, this may be due to the Starting URL being sent to the server as a heartbeat, without cookies.

Deactivating this setting may solve the problem, but note that AppScan® will not be able to verify server status.

Check for "server down" in Test

Enables the sending of heartbeat requests to check for "Server Down" during Test stage.

Default: True

If AppScan® gets server-down errors during the Test stage, and the server is not down, this may be due to the server blocking the frequent heartbeat requests.

If AppScan® frequently gets out-of-session during scanning, this may be due to the Starting URL being sent to the server as a heartbeat, without cookies.

Deactivating this setting may solve the problem, but note that AppScan® will not be able to verify server status.

Explore stage reconnect attempts

When AppScan® is about to finish the Explore stage but several tests failed due to "server down", and the server is still down, AppScan® will try to connect to the server several times.

Default: 5

If you know that your server is sensitive, or you see that the scan stopped due to a communication error while several tests failed due to communication errors, you should increase this number.

Request retry interval

Interval in seconds before resending failed requests (including failed heartbeat requests).

Default: 1

If you know that you have a poor connection or an unstable server (which would result in false negative results, or reduced coverage), you can increase this interval to reduce the impact.

Request retry limit

Number of times to retry sending failed requests.

Default: 2

Increasing this setting may result in a more efficient scan if your server is unstable or communication is poor.

Server down timeout

When AppScan® is unable to connect to the server or gets out-of-session, this setting defines (in seconds) for how long AppScan® will try to reconnect or get back into session before stopping the scan.

Default: 185

If you have a slow connection, or your server takes a long time to reload after down time, you might want to increase this setting.

Server-down heartbeat interval

Interval in seconds between "server down" heartbeats.

Default: 3 s

Max: 60 s

If AppScan® gets server-down errors during the scan, it may be due to a poor connection or unstable server. Increasing this interval may solve the problem.

Test stage reconnect attempts

When AppScan® is about to finish the Test stage but several tests failed due to "server down", and the server is still down, AppScan® will try to connect to the server several times.

Default: 5

If you know that your server is sensitive, or you see that the scan stopped due to a communication error while several tests failed due to communication errors, you should increase this number.

Session Management:

Ad domains

Regular expression describing common web advert domains. Requests sent to these domains when the login sequence is recorded, will be discarded.

Default: ad\d.googlesyndication| doubleclick\.net|coremetrics\.|webtrends\ .|112\.2o7\.net|view.atdmt.com| ad.yieldmanager.com|ads.adbrite.com| oasn04.247realmedia.com| segment-pixel.invitemedia.com"

Since the login sequence is replayed continually during the scan, you can improve scan efficiency by filtering out these unnecessary requests.

Note that if you delete the regexp altogether, no domains will be filtered out.

Analyze login recording

When you record a login sequence (Scan Configuration > Login Management), ADAC will analyze it and update in-session detection settings (in-session pattern, in-session request, and session IDs received during login).

Default: True

If the analysis takes too long, you can change this setting to False. However, if you do this you will need to configure the in-session detection settings manually.

Clear cookies before playing login

Determines whether cookies are deleted before replaying the login sequence.

Default: True

Common static parameter values

Common static parameter values. Used for the detection of non-random parameter values, which should not be tracked during login.

Default: |true|false|\bon\b|\boff\b|\ bout\b|checked|enabled|log\s?in|log\ s?out|exit|submit|sign|ever|disabled| agree

Disable Explore stage in-session buffering

During the Explore stage: If the response to a request indicates that the user was out-of-session when it was sent, AppScan queues the request to send again. This insures that as much of the site as possible is scanned.

Default: False

If your site throws the user out of session frequently, in-session buffering may result in the Explore stage continuing indefinitely. Setting this option to True will make the Explore stage faster, but may reduce site coverage.

In-session before multi-step operations

By default AppScan® verifies in-session status before replaying multi-step operations.

Default: True

If you want to test multi-step operations with a non-authenticated user, or if your multi-step sequence includes login steps, change this setting to False.

In-session heartbeat interval

Interval in seconds between in-session heartbeats.

Default: 5

If AppScan® gets out-of-session during the scan, it may be due to a poor connection or an unstable server. Increasing this interval may solve the problem.

Login retry interval

Interval in seconds before re-sending failed login requests.

Default: 3

If AppScan® gets out of session, and repeated login retry attempts fail, this may be because the server is sensitive to frequent login attempts. Increasing this interval may solve the problem.

Multipart Content Type Filter

To reduce unnecessary memory consumption, certain content types are automatically filtered out of multipart requests (requests that contain more than one content type). Only content types defined in this regular expression are included in multipart requests; all others are filtered out.

content_without_content_type_header

Default: text/|text/plain|application/javascript|

application/json|application/rtf|application/xml|

text/xml|content_without_content_type_header

If an important content type is filtered out of requests, add it to this regular expression. You may also be able to reduce memory consumption by removing unnecessary content types so they will not be sent.

Navigational parameter hosts

Regular expression describing hosts. Used for the detection of navigational parameters (by value), which should not be tracked during the login sequence.

Default: https?://

If your site uses unusual hosts in navigational parameters, that are not filtered out by the default regexp, you can add them to improve scan efficiency.

If you delete the item navigational parameters might not be identified properly.

Navigational parameter scripts

Regular expression describing server-side scripts used in the detection of navigational parameters (by parameter value) which should not be tracked during the login sequence.

Default: /[^/\.]+\.(htm|jsp|jsf|ws|dll|asp|php|do)

If your site uses unusual server-side scripts in navigational parameters, that are not filtered out by the default regexp, you can add them to improve scan efficiency.

If you delete the item navigational parameters might not be identified properly.

Navigational parameters

Regular expression describing navigational parameters, which should not be tracked during the login sequence.

Default: \bnav|url|page|step|redirect|request|

location|target|argument|item|article|

goto|node|action|ctrl|control|source|

menu|frame|command

If your site uses unusual navigational parameters that are not filtered out by the default regexp, you can add them to improve scan efficiency.

Modifying this regular expression might result in insufficient scan coverage or improper session tracking.

Parse In-session page

If set to False AppScan will not parse the in-session page, and will not update tracked parameters or cookies whose values were changed in the in-session page.

Default: True

If your in-session page does not contain tracked cookies or parameters, you can improve performance by changing this setting to False. Note, that if set to False, AppScan will not update cookie/parameter values on the in-session page, which could result in getting out-of-session.

Password parameter name

Used by Recorded Login Analysis to identify the password parameter. Its full name is needed.

Default: password|pass|pswd|pwd

Sometimes, when you import a login (rather than record it using Action-Based Login) AppScan may fail to identify the password parameter name. If this happens the Password field in Scan Configuration > Automatic Form Fill will be empty. If this happens, add the full password parameter name here.

Requests between heartbeats

Following an in-session detection request, AppScan® will send at least the number of requests defined here before sending another in-session detection request.

Default: 1

In cases where a slow response from the server results in the scan consisting mostly of in-session detection requests (see Traffic Log), increasing this value can reduce scan time.

A regular expression defining content types that will be filtered out of the login, multi-step sequences and manual explore.

Default: text/javascript|application/javascript|application/x-javascript|image|text/css|application/x-msdownload|application/zip|application/octet-stream|application/java-archive|application/font-|application/x-font

Special Patterns:

Exclude from Automatic Form Fill

Parameter names listed here are excluded from the Automatic Form Filler.

Default: ^CFID __EVENTVALIDATION __VIEWSTATE ^CFTOKEN __EVENTARGUMENT __EVENTTARGET ^BV_ 

Parameters with very long values may slow down the scan and increase file size. If your application uses parameters with long values, and they are not needed for filling forms, add them to this list.

Tests:

CSRF: Pattern of meaningful request

By default AppScan® tests POST requests, and requests whose response was "Transaction Successful", for Cross-Site Request Forgery.

This setting lets you define additional requests as "meaningful" for Cross-Site Request Forgery vulnerability, in addition to POST requests.

This definition is used in conjunction with "CSRF: Pattern of meaningful response".

Default: ^POST

If you want to test for Cross-Site Request Forgery on GET requests too, change this regular expression.

CSRF: Pattern of meaningful response

By default AppScan® tests POST requests, and requests whose response was "Transaction Successful", for Cross-Site Request Forgery.

This setting lets you define additional responses as "meaningful" for Cross-Site Request Forgery vulnerability, in addition to "Transaction Successful".

This definition is used in conjunction with "CSRF: Pattern of meaningful request".

Default: Transaction Successful

If you want to test for Cross-Site Request Forgery on requests that receive other kinds of responses, define them in this regular expression.

Difference threshold

ADAC often needs to compare two responses, and decide whether that are "similar" or "different", in order to know whether a test was successful or not. In these cases, ADAC uses a variety of algorithms to assign a Similarity Percentage (where 100% means the two responses are identical). In some cases it decides the test outcome based on whether the Similarity Percentage is above the "Similarity Threshold", and in others based on whether it is below the "Difference Threshold". Both thresholds can be configured.

If you enter a value between 1 and 100 (percent) for this setting, it will override the default Difference Threshold for all tests. You may also want to adjust the Similarity Threshold.

Default: 0 (Use ADAC thresholds)

If your site has no "dynamic" text that causes the similar responses to be slightly different, setting a value lower than 75 may reduce false positive results.

Disable cookie testing

This setting is used to turn off cookie testing altogether.

Default: False

If cookie testing for your application results in a very long scan, you might want to disable it. However, doing so might result in security issues being missed ("false negatives").

Disable cookie testing for static content

Don't test cookies in requests for pages with this extension.

Default: ;htm;html;ahtm;ahtml;

chtm;chtml;fhtm;fhtml;mht;

mhtm;mhtml;css;css1;js;

In order to reduce scan time and memory consumption, you may want to exclude additional types of page extension. If so, add them to the list of extensions to exclude, separated by a semicolon.

Don't test directory or page

This option lets you define a regular expression to exclude specific directories or pages from attacks during the Test stage. Note that this will only exclude the directories or pages defined, and not any subdirectories or files.

Default: /wps/[^/]*/!ut/

If you know that certain directories or pages are not vulnerable, or are concerned that testing them might harm site stability, you can exclude them from the scan by defining them in this regular expression.

For excluding a folder and all its sub-folders, see Exclude Paths and Files

Extract links from all responses

By default during the test stage AppScan® will only search for new links in vulnerable responses.

Default: False

If you think AppScan® might miss links, or that its coverage isn't sufficient, you can enable this setting, though doing so will increase scan time and file size.

Follow all automatic links

By default AppScan® only follows automatic links* that are likely to contain vulnerabilities. These are: iFrame, Frame and Redirect. You can configure it to follow all types of automatic link.

Note that requests that match the regular expression defined in "Automatic links to ignore" will never be sent, regardless of this setting.

Default: False

* Automatic link: A link on the web page that the browser sends automatically, without any user interaction.

If you think your site may contain a vulnerability in other types of automatic link, such as scripts, enable this setting. This will increase scan time and file size.

List of entities to test

Login after test

Send tests in a single thread, and verify in-session, or send login sequence, after every test.

0 = False

1 = Send tests in a single thread, and verify in-session after every test. If out-of-session, send login sequence.

2 = Send tests in a single thread, and sent login sequence after every test.

Default: 0

Settings 1 or 2 may be needed for applications with a sensitive session, or that require frequent logouts to avoid session or memory issues. They significantly increase scan time.

Multi-step Operation: Validation limit

The maximum number of consecutive requests from a Multi-Step Operation sequence that will be validated in Cross-Site Scripting tests.

Default: 0

Omit response body if not needed

For certain types of test it is not the response body that confirms the vulnerability. Saving this content as part of the scan data increases scan size with no benefit, so by default AppScan does not save it in these cases. Note that setting this value to False may significantly increase scan size.

Default: True

n/a

Pattern to ignore in response

This regular expression defines sections of the response that AppScan® will ignore when analyzing test responses.

When comparing responses to decide if a test succeeded, AppScan® measures the percentage of change in the entire response. If the response is very long, and the change very small, AppScan® might ignore the difference and miss the vulnerability.

Default: <input[^>]+(__VIEWSTATE|__

EVENTTARGET|

__EVENTARGUMENT|

__EVENTVALIDATION)

[^>]+>

If your site sends responses that include long sections that are not important, defining them here can improve scan accuracy and performance.

Refresh original response interval

Interval in seconds before refreshing the original response (by sending the request again) during the Test stage.

One of the ways AppScan decides whether a Test response reveals a vulnerability is by comparing it with the Explore response. When an Explore response is older than the value set here, the Explore request will be sent again, before sending tests, so that an updated Explore response can be used for the comparison. This is important for cases where the Explore response is likely to vary with time, and comparing the Test response to the outdated Explore response might result in a false positive.

Default: 30 (seconds)

If you are sure that your application's responses will never become outdated in this way, you can change this setting to zero to reduce scan time. Explore stage requests will then never be resent.

Send port listener tests

By default AppScan® doesn't send port listener tests because of the likelihood of failure and the time it takes to validate.

Default: False

If the external site is part of your network, so that it is aware of local IP addresses, you might want to activate this type of blind SQL injection test.

Similarity threshold

Certain tests compare the response they receive with the original response, to decide whether the response is similar, and therefore whether they succeeded. For most tests the similarity threshold is 95%. In some test policies it is higher.

If you enter a value between 1 and 100 (percent), it will override the thresholds for individual tests.

Default: 0 (Use AppScan thresholds)

If your site has no "dynamic" text that causes the similar responses to be slightly different, increasing this percentage may reduce false positive results.

XSS: Revalidate using browser

For some cross-site scripting issues, checking the site’s response using an actual browser can identify alert popups better, and reduce false positive results.

Default: True

XSS: Test all reflected probes

Usually multiple occurrences of the payload text in a response from the site have the same level of vulnerability, therefore AppScan® tests only one of them.

Default: False

Set this to True if you want to test all occurrences of the payload text in a single response.