rules.xml

<!-- TODO this file should be automatically generated with the ZAProxy report -->

<!-- A rule model -->
<!--<rule>
    <key></key>
    <name></name>-->

<!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<!--<description>
<![CDATA[<h3>Solution :</h3>
<p></p>
<h3>References:</h3>
<ul>
<li><a href=""></a></li>
</ul>]]>
</description>
<severity></severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
-->

<!--

For the moment, this file contains only rules of the ZAP core.
If you want to add a rule, you can, following the model above.

-->

<rules>
    <rule>
        <key>0</key>
        <name>Directory Browsing</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
  <p>Disable directory browsing. If this is required, make sure the listed files does not induce risks.</p>
  <h3>References:</h3>
  <ul>
  <li><a href="https://httpd.apache.org/docs/mod/core.html#options">Directive Options</a></li>
  <li><a href="https://alamo.satlug.org/pipermail/satlug/2002-February/000053.html">Apache Dir/Browsing Question</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/548.html">CWE-548</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/0/">https://www.zaproxy.org/docs/alerts/0/</a></li>

  </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-548</tag>
        <tag>wascid-48</tag>
        <tag>wascid-16</tag>
        <tag>owasp-a5</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>

    <!--

    "securityStandards": {
    "CWE": [
      330
    ],
    "OWASP": [
      "A6"
    ]
  }-->

    <rule>
        <key>2</key>
        <name>Private IP Disclosure</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Remove the private IP address from the HTTP response body.  For comments, use JSP/ASP comment instead of HTML/JavaScript comment which can be seen by
    client browsers.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://tools.ietf.org/html/rfc1918">Address Allocation for Private Internets</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/2/">https://www.zaproxy.org/docs/alerts/2/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>3</key>
        <name>Session ID in URL Rewrite</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>For secure content, put session ID in a cookie. To be even more secure consider using a combination of cookie and URL rewrite.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://seclists.org/lists/webappsec/2002/Oct-Dec/0111.html">Hijacking URL Encoded Session IDs using Referer Logs</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/3/">https://www.zaproxy.org/docs/alerts/3/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>6</key>
        <name>Path Traversal</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
    specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on
    looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or
    determining which inputs are so malformed that they should be rejected outright.

    When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or
    extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid
    because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

    For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses,
    and exclude directory separators such as "/". Use a whitelist of allowable file extensions.

    Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters
    such as '.' and ';' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form.
    Suppose the attacker injects a '.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename,
    "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised.

    Inputs should be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not
    decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked.

    Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".."
    sequences and symbolic links.

    Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that
    are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For
    example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

    When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the
    actual filenames or URLs, and reject all other inputs.

    Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict
    which files can be accessed in a particular directory or which commands can be executed by your software.

    OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in
    the Java SecurityManager allows you to specify restrictions on file operations.

    This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Path-Traversal">Path Traversal</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/6/">https://www.zaproxy.org/docs/alerts/6/</a></li>
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>cweid-22</tag>
        <tag>wascid-33</tag>
        <tag>owasp-a5</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>7</key>
        <name>Remote File Inclusion</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Phase: Architecture and Design</p>
    <p>
    When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs)
    to the actual filenames or URLs, and reject all other inputs.
    For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
    </p>
    Phases: Architecture and Design; Operation
    <p>
    Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively
    restrict which files can be accessed in a particular directory or which commands can be executed by your software.
    OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example,
    java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
    This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
    Be careful to avoid CWE-243 and other weaknesses related to jails.
    For PHP, the interpreter offers restrictions such as open basedir or safe mode which can make it more difficult for an attacker to escape out of the
    application. Also consider Suhosin, a hardened PHP extension, which includes various options that disable some of the more dangerous PHP features.
    </p>
    Phase: Implementation
    <p>
    Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
    specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on
    looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or
    determining which inputs are so malformed that they should be rejected outright.
    When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values,
    missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be
    syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
    For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid
    weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to
    avoid CWE-434.
    </p>
    Phases: Architecture and Design; Operation
    <p>
    Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web
    server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling
    program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and
    it can exit immediately.
    This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include
    files. It will also reduce your attack surface.
    </p>
    Phases: Architecture and Design; Implementation
    <p>
    Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network,
    environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide
    data to the application. Remember that such inputs may be obtained indirectly through API calls.
    Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Remote-File-Inclusion">Remote File Inclusion</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/98.html">CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program
    ('PHP Remote File Inclusion')</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/7/">https://www.zaproxy.org/docs/alerts/7/</a></li>
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>cweid-98</tag>
        <tag>wascid-5</tag>
        <tag>owasp-a5</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>41</key>
        <name>Source Code Disclosure - Git</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that Git metadata files are not deployed to the web server or application server.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Predictable-Resource-Location">https://projects.webappsec.org/Predictable-Resource-Location</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/425.html">https://cwe.mitre.org/data/definitions/425.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/41/">https://www.zaproxy.org/docs/alerts/41/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-425</tag>
        <tag>cweid-541</tag>        
        <tag>wascid-34</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>42</key>
        <name>Source Code Disclosure - SVN</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that SVN metadata files are not deployed to the web server or application server.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Predictable-Resource-Location">https://projects.webappsec.org/Predictable-Resource-Location</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/425.html">https://cwe.mitre.org/data/definitions/425.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/42/">https://www.zaproxy.org/docs/alerts/42/</a></li>

    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-425</tag>
        <tag>cweid-541</tag>        
        <tag>wascid-34</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>43</key>
        <name>Source Code Disclosure - File Inclusion</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that Source Code files are not deployed to the web server or application server.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Predictable-Resource-Location">https://projects.webappsec.org/Predictable-Resource-Location</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/425.html">https://cwe.mitre.org/data/definitions/425.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/43/">https://www.zaproxy.org/docs/alerts/43/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-425</tag>
        <tag>cweid-541</tag>        
        <tag>wascid-34</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10003</key>
        <name>Vulnerable JS Library</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Please upgrade to the latest version of ExampleLibrary.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/829.html">https://cwe.mitre.org/data/definitions/829.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/937.html">https://cwe.mitre.org/data/definitions/937.html</a></li>        
    <li><a href="https://www.zaproxy.org/docs/alerts/10003/">https://www.zaproxy.org/docs/alerts/10003/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-829</tag>
        <tag>cweid-937</tag>     
        <tag>owasp-a9</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10009</key>
        <name>In Page Banner Information Leak</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>"Configure the server to prevent such information leaks. For example:
Under Tomcat this is done via the 'server' directive and implementation of custom error pages.
Under Apache this is done via the 'ServerSignature' and 'ServerTokens' directives.".</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/">https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">https://cwe.mitre.org/data/definitions/200.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10009/">https://www.zaproxy.org/docs/alerts/10009/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>     
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10010</key>
        <name>Cookie set without HttpOnly flag</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that the HttpOnly flag is set for all cookies.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/HttpOnly">HttpOnly</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/1004.html">https://cwe.mitre.org/data/definitions/1004.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10010/">https://www.zaproxy.org/docs/alerts/10010/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-15</tag>
        <tag>cweid-1004</tag>
        <tag>owasp-a2</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10011</key>
        <name>Cookie set without secure flag</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel.
    Ensure that the secure flag is set for cookies containing such sensitive information.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)">Testing for cookies attributes (OTG-SESS-002)</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/614.html">https://cwe.mitre.org/data/definitions/614.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10011/">https://www.zaproxy.org/docs/alerts/10011/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-4</tag>
        <tag>cweid-614</tag>
        <tag>owasp-a2</tag>
        <tag>owasp-a3</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10012</key>
        <name>Password Autocomplete in Browser</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Turn off AUTOCOMPLETE attribute in form or individual input elements containing password by using AUTOCOMPLETE='OFF'</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/autocomplete_ovr.asp">Autocomplete</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/525.html">https://cwe.mitre.org/data/definitions/525.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10012/">https://www.zaproxy.org/docs/alerts/10012/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-525</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>owasp-a3</tag>
    </rule>
    <rule>
        <key>10015</key>
        <name>Incomplete or No Cache-control and Pragma HTTP Header Set</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Whenever possible ensure the cache-control HTTP header is set with no-cache, no-store, must-revalidate, private; and that the pragma HTTP header is
    set with no-cache.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Web_Content_Caching">Web Content Caching</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/525.html">https://cwe.mitre.org/data/definitions/525.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10015/">https://www.zaproxy.org/docs/alerts/10015/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-525</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>owasp-a3</tag>
    </rule>
    <rule>
        <key>10016</key>
        <name>Web Browser XSS Protection Not Enabled</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet">XSS (Cross Site Scripting) Prevention Cheat Sheet</a></li>
    <li><a href="https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers">Guidelines for Setting Security Headers</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/933.html">https://cwe.mitre.org/data/definitions/933.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10016/">https://www.zaproxy.org/docs/alerts/10016/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-933</tag>
        <tag>wascid-14</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10017</key>
        <name>Cross-Domain JavaScript Source File Inclusion</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure JavaScript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.zaproxy.org/docs/alerts/10017/">https://www.zaproxy.org/docs/alerts/10017/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10019</key>
        <name>Content-Type Header Missing</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure each page is setting the specific and appropriate content-type value for the content being delivered</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx">Reducing MIME type security risks</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10019/">https://www.zaproxy.org/docs/alerts/10019/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>10020</key>
        <name>X-Frame-Options Header Not Set</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site
    (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise
    if you never expect the page to be framed, you should use DENY.  ALLOW-FROM allows specific websites to frame the web page in supported web browsers).</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx">Combating ClickJacking With X-Frame-Options</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10020/">https://www.zaproxy.org/docs/alerts/10020/</a></li>    
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10021</key>
        <name>X-Content-Type-Options Header Missing</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for
    all web pages.</br>If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that
    can be directed by the web application/web server to not perform MIME-sniffing.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx">Reducing MIME type security risks</a></li>
    <li><a href="https://www.owasp.org/index.php/List_of_useful_HTTP_headers">List of useful HTTP headers</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10021/">https://www.zaproxy.org/docs/alerts/10021/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-15</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10023</key>
        <name>Information Disclosure - Debug Error Messages</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.
    Ensure that the entire software development team shares a common approach to exception handling.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Top_10_2007-Information_Leakage_and_Improper_Error_Handling">List of useful HTTP headers</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10023/">https://www.zaproxy.org/docs/alerts/10023/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10024</key>
        <name>Information Disclosure - Sensitive Informations in URL</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>When sensitive information is sent, use of the POST method is recommended (e.g. registration form).
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url">List of useful HTTP headers</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10024/">https://www.zaproxy.org/docs/alerts/10024/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10025</key>
        <name>Information Disclosure - Sensitive Information in HTTP Referrer Header</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>When sensitive information is sent, use of the POST method is recommended (e.g. registration form).
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url">List of useful HTTP headers</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10025/">https://www.zaproxy.org/docs/alerts/10025/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10026</key>
        <name>HTTP Parameter Override</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>In order to prevent these kinds of vulnerabilities, an extensive and proper input validation should be performed.
    There are safe methods to conform to with each web technology/language. Moreover, awareness about the fact that clients/users can provide more than one parameter should be raised.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004)">Testing for HPP</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10026/">https://www.zaproxy.org/docs/alerts/10026/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10027</key>
        <name>Information Disclosure - Suspicious Comments</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Remove comments that suggest the presence of bugs, incomplete functionality, or weaknesses, before deploying the application.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/546.html">CWE-546</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10027/">https://www.zaproxy.org/docs/alerts/10027/</a></li>    
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-546</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>owasp-a3</tag>
    </rule>
    <rule>
        <key>10028</key>
        <name>Open Redirect</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>To avoid the open redirect vulnerability, parameters of the application script/program must be validated before sending 302 HTTP code (redirect) to the client browser. Implement safe redirect functionality that only redirects to relative URI's, or a list of trusted domains.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/601.html">CWE-601</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10028/">https://www.zaproxy.org/docs/alerts/10028/</a></li>    
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-601</tag>
        <tag>wascid-38</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10029</key>
        <name>Cookie Poisoning</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not allow user input to control cookie names and values. If some query string parameters must be set in cookie values, be sure to filter out semicolon's that can serve as name/value pair delimiters.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://websecuritytool.codeplex.com/wikipage?title=Checks#user-controlled-cookie">https://websecuritytool.codeplex.com/wikipage?title=Checks#user-controlled-cookie</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10029/">https://www.zaproxy.org/docs/alerts/10029/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10030</key>
        <name>User Controllable Charset</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Force UTF-8 in all charset declarations. If user-input is required to decide a charset declaration, ensure that only an allowed list is used.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10030/">https://www.zaproxy.org/docs/alerts/10030/</a></li>    
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10031</key>
        <name>User Controllable HTML Element Attribute (Potential XSS)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Validate all input and sanitize output it before writing to any HTML attributes.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://websecuritytool.codeplex.com/wikipage?title=Checks#user-controlled-html-attribute">https://websecuritytool.codeplex.com/wikipage?title=Checks#user-controlled-html-attribute</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10031/">https://www.zaproxy.org/docs/alerts/10031/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10032</key>
        <name>Viewstate Scanner</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not store the ViewState within the HTML page (implement a handler). Protect the ViewState contents (configuration).
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/images/2/22/20110412-aspnet_viewstate_security-alexandre.pdf">ASP Security ViewState flaw</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10032/">https://www.zaproxy.org/docs/alerts/10032/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10033</key>
        <name>Directory Browsing</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Configure the web server to disable directory browsing.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/548.html">CWE-548</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10033/">https://www.zaproxy.org/docs/alerts/10033/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-548</tag>
        <tag>wascid-16</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10034</key>
        <name>Heartbleed OpenSSL Vulnerability (Indicative)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Update to OpenSSL 1.0.1g or later. Re-issue HTTPS certificates. Change asymmetric private keys and shared secret keys, since these may have been compromised, with no evidence of compromise in the server log files.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cvedetails.com/cve-details.php?t=1&cve_id=CVE-2014-0160">https://cvedetails.com/cve-details.php?t=1&cve_id=CVE-2014-0160</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/119.html">CWE-119</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10034/">https://www.zaproxy.org/docs/alerts/10034/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-119</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10036</key>
        <name>HTTP Server Response Header</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Disable Server Header Version Information</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10036/">https://www.zaproxy.org/docs/alerts/10036/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10037</key>
        <name>Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is configured to suppress 'X-Powered-By' headers.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx">https://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10037/">https://www.zaproxy.org/docs/alerts/10037/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10039</key>
        <name>X-Backend-Server Header Information Leak</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is configured to suppress X-Backend-Server headers.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10039/">https://www.zaproxy.org/docs/alerts/10039/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10040</key>
        <name>Secure Pages Include Mixed Content</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>A page that is available over TLS must be comprised completely of content which is transmitted over TLS.
    The page must not contain any content that is transmitted over unencrypted HTTP.
    This includes content from unrelated third party sites.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">Transport Layer Protection Cheat Sheet</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10040/">https://www.zaproxy.org/docs/alerts/10040/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10041</key>
        <name>HTTP to HTTPS Insecure Transition in Form Post</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Use HTTPS for landing pages that host secure forms.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10041/">https://www.zaproxy.org/docs/alerts/10041/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10042</key>
        <name>HTTPS to HTTP Insecure Transition in Form Post</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure sensitive data is only sent over secured HTTPS channels.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10042/">https://www.zaproxy.org/docs/alerts/10042/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10043</key>
        <name>User Controllable JavaScript Event (XSS)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Validate all input and sanitize output it before writing to any Javascript on* events.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://websecuritytool.codeplex.com/wikipage?title=Checks#user-javascript-event">https://websecuritytool.codeplex.com/wikipage?title=Checks#user-javascript-event</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10043/">https://www.zaproxy.org/docs/alerts/10043/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10044</key>
        <name>Big Redirect Detected (Potential Sensitive Information Leak)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that no sensitive information is leaked via redirect responses. Redirect responses should have almost no content.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/201.html">CWE-201</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10044/">https://www.zaproxy.org/docs/alerts/10044/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-201</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10045</key>
        <name>Source Code Disclosure - /WEB-INF folder</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Predictable-Resource-Location">https://projects.webappsec.org/Predictable-Resource-Location</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/541.html">CWE-541</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10045/">https://www.zaproxy.org/docs/alerts/10045/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-541</tag>
        <tag>wascid-34</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10047</key>
        <name>HTTPS Content Available via HTTP</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is configured to only serve such content via HTTPS. Consider implementing HTTP Strict Transport Security.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html</a></li>
    <li><a href="https://owasp.org/www-community/Security_Headers">https://owasp.org/www-community/Security_Headers</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/311.html">CWE-311</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10047/">https://www.zaproxy.org/docs/alerts/10047/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-311</tag>
        <tag>wascid-4</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10048</key>
        <name>Remote Code Execution - Shell Shock</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Update Bash on the server to the latest version</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271">https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/78.html">CWE-78</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10048/">https://www.zaproxy.org/docs/alerts/10048/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-78</tag>
        <tag>wascid-31</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10050</key>
        <name>Retrieved from Cache</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Validate that the response does not contain sensitive, personal or user-specific information.  If it does, consider the use of the following HTTP response headers, to limit, or prevent the content being stored and retrieved from the cache by another user</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://tools.ietf.org/html/rfc7234">https://tools.ietf.org/html/rfc7234</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10050/">https://www.zaproxy.org/docs/alerts/10050/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10051</key>
        <name>Relative Path Confusion</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Web servers and frameworks should be updated to be configured to not serve responses to ambiguous URLs in such a way that the relative path of such URLs could be mis-interpreted by components on either the client side, or server side.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.thespanner.co.uk/2014/03/21/rpo/">https://www.thespanner.co.uk/2014/03/21/rpo/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10051/">https://www.zaproxy.org/docs/alerts/10051/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10052</key>
        <name>X-ChromeLogger-Data (XCOLD) Header Information Leak</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Disable this functionality in Production when it might leak information that could be leveraged by an attacker. Alternatively ensure that use of the functionality is tied to a strong authorization check and only available to administrators or support personnel for troubleshooting purposes not general users.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://craig.is/writing/chrome-logger">https://craig.is/writing/chrome-logger</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10052/">https://www.zaproxy.org/docs/alerts/10052/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>10053</key>
        <name>Apache Range Header DoS (CVE-2011-3192)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Upgrade your Apache server to a currently stable version. Alternative solutions or workarounds are outlined in the references.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://httpd.apache.org/security/CVE-2011-3192.txt">https://httpd.apache.org/security/CVE-2011-3192.txt</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/400.html">CWE-400</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10053/">https://www.zaproxy.org/docs/alerts/10053/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-400</tag>
        <tag>wascid-10</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10054</key>
        <name>Cookie Without SameSite Attribute</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that the SameSite attribute is set to either &apos;lax&apos; or ideally &apos;strict&apos; for all cookies.</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site">https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">https://cwe.mitre.org/data/definitions/16.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10054/">https://www.zaproxy.org/docs/alerts/10054/</a></li>    

    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-16</tag>
        <tag>wascid-13</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>10055</key>
        <name>CSP Scanner: script-src unsafe-inline</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is properly configured to set the Content-Security-Policy header.</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.w3.org/TR/CSP2/">https://www.w3.org/TR/CSP2/</a></li>
    <li><a href="https://caniuse.com/#search=content+security+policy">https://caniuse.com/#search=content+security+policy</a></li>
    <li><a href="https://content-security-policy.com/">https://content-security-policy.com/</a></li>
    <li><a href="https://github.com/shapesecurity/salvation">https://github.com/shapesecurity/salvation</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">https://cwe.mitre.org/data/definitions/16.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10055/">https://www.zaproxy.org/docs/alerts/10055/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>10056</key>
        <name>X-Debug-Token Information Leak.</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Limit access to Symfony's Profiler, either via authentication/authorization or limiting inclusion of the header to specific clients (by IP, etc.).</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://symfony.com/doc/current/cookbook/profiler/profiling_data.html">https://symfony.com/doc/current/cookbook/profiler/profiling_data.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10056/">https://www.zaproxy.org/docs/alerts/10056/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10057</key>
        <name>Username Hash Found</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Use per user or session indirect object references (create a temporary mapping at time of use). Or, ensure that each use of a direct object reference is tied to an authorization check to ensure the user is authorized for the requested object.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References.html">https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/284.html">CWE-284</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10057/">https://www.zaproxy.org/docs/alerts/10057/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-284</tag>
        <tag>wascid-2</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10058</key>
        <name>GET for POST</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that only POST is accepted where POST is expected.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10058/">https://www.zaproxy.org/docs/alerts/10058/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-16</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10061</key>
        <name>X-AspNet-Version Response Header</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Configure the server so it will not return those headers.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.troyhunt.com/shhh-dont-let-your-response-headers/">https://www.troyhunt.com/shhh-dont-let-your-response-headers/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/933.html">CWE-933</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10061/">https://www.zaproxy.org/docs/alerts/10061/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-933</tag>
        <tag>wascid-14</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10062</key>
        <name>PII Disclosure</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>_Unavailable_</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/359.html">CWE-359</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10062/">https://www.zaproxy.org/docs/alerts/10062/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-359</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10063</key>
        <name>Feature Policy Header Not Set</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is configured to set the Feature-Policy header.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10063/">https://www.zaproxy.org/docs/alerts/10063/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10094</key>
        <name>Base64 Disclosure</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Manually confirm that the Base64 data does not leak sensitive information, and that the data cannot be aggregated/used to exploit other vulnerabilities.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">Top 10 2013-A6-Sensitive Data Exposure</a></li>
    <li><a href="https://projects.webappsec.org/w/page/13246936/Information%20Leakage">WASC - Information Leakage</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">https://cwe.mitre.org/data/definitions/200.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10094/">https://www.zaproxy.org/docs/alerts/10094/</a></li>    
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>cweid-200</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10095</key>
        <name>Backup File Disclosure</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.html">https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/530.html">CWE-530</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10095/">https://www.zaproxy.org/docs/alerts/10095/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-530</tag>
        <tag>wascid-34</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10096</key>
        <name>Timestamp Disclosure - Unix</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Manually confirm that the timestamp data is not sensitive, and that the data cannot be aggregated to disclose exploitable patterns.</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li>&lt;p&gt;https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure&lt;/p&gt;&lt;p&gt;https://projects.webappsec.org/w/page/13246936/Information%20Leakage&lt;/p&gt;</li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">https://cwe.mitre.org/data/definitions/200.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10096/">https://www.zaproxy.org/docs/alerts/10096/</a></li>    
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>owasp-a3</tag>
    </rule>
    <rule>
        <key>10097</key>
        <name>Hash Disclosure - MD4 / MD5</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>A Ensure that hashes that are used to protect credentials or other resources are not leaked by the web server or database. There is typically no requirement for password hashes to be accessible to the web browser.</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">Sensitive Data Exposure</a></li>
    <li><a href="https://projects.webappsec.org/w/page/13246936/Information%20Leakage">Information Leakage</a></li>
    <li><a href="https://openwall.info/wiki/john/sample-hashes">sample hashes</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">https://cwe.mitre.org/data/definitions/200.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10097/">https://www.zaproxy.org/docs/alerts/10097/</a></li>    
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>owasp-a3</tag>
    </rule>
   <rule>
        <key>10098</key>
        <name>Cross-Domain Misconfiguration</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that sensitive data is not available in an unauthenticated manner (using IP address white-listing, for instance).
Configure the 'Access-Control-Allow-Origin' HTTP header to a more restrictive set of domains, or remove all CORS headers entirely, to allow the web browser to enforce the Same Origin Policy (SOP) in a more restrictive manner.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.hpenterprisesecurity.com/vulncat/en/vulncat/vb/html5_overly_permissive_cors_policy.html">https://www.hpenterprisesecurity.com/vulncat/en/vulncat/vb/html5_overly_permissive_cors_policy.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/264.html">CWE-264</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10098/">https://www.zaproxy.org/docs/alerts/10098/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-264</tag>
        <tag>wascid-14</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10099</key>
        <name>Source Code Disclosure</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that application Source Code is not available with alternative extensions, and ensure that source code is not present within other files or data deployed to the web server, or served by the web server.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://blogs.wsj.com/cio/2013/10/08/adobe-source-code-leak-is-bad-news-for-u-s-government/">https://blogs.wsj.com/cio/2013/10/08/adobe-source-code-leak-is-bad-news-for-u-s-government/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/540.html">CWE-540</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10099/">https://www.zaproxy.org/docs/alerts/10099/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-540</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
   <rule>
        <key>10104</key>
        <name>User Agent Fuzzer</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Check for differences in response based on fuzzed User Agent (eg. mobile sites, access as a Search Engine Crawler). Compares the response statuscode and the hashcode of the response body with the original response.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/wstg">https://owasp.org/wstg</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10104/">https://www.zaproxy.org/docs/alerts/10104/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10105</key>
        <name>Weak Authentication Method</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Disable and block all authentication methods so that only forms-based authentication and SSL client certificates are allowed.
    Whitelist or proxy all inlined content in order to block malicious authentication requests.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Weak_Authentication_Methods">Weak Authentication Methods</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10105/">https://www.zaproxy.org/docs/alerts/10105/</a></li>    
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>10106</key>
        <name>HTTP Only Site</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Configure your web or application server to use SSL (https)..</p>
    <h3>References:</h3>
    <ul>
    <li><a href=" https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html"> https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/311.html">CWE-311</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10106/">https://www.zaproxy.org/docs/alerts/10106/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-311</tag>
        <tag>wascid-4</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10107</key>
        <name>Httpoxy - Proxy Header Misuse</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>The best immediate mitigation is to block Proxy request headers as early as possible, and before they hit your application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://httpoxy.org/">https://httpoxy.org/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10107/">https://www.zaproxy.org/docs/alerts/10107/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10108</key>
        <name>Reverse Tabnabbing</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not use a target attribute, or if you have to then also add the attribute: rel='noopener noreferrer'.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-community/attacks/Reverse_Tabnabbing">https://owasp.org/www-community/attacks/Reverse_Tabnabbing/</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/10108/">https://www.zaproxy.org/docs/alerts/10108/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10109</key>
        <name>Modern Web Application</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>The application appears to be a modern web application. If you need to explore it automatically then the Ajax Spider may well be more effective than the standard one.</p>
    <h3>References:</h3>
    <ul>
	<li><a href="https://www.zaproxy.org/docs/alerts/10109/">https://www.zaproxy.org/docs/alerts/10109/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10110</key>
        <name>Dangerous JS Functions</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>See the references for security advice on the use of these functions.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://angular.io/guide/security">https://angular.io/guide/security</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/749.html">CWE-749</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10110/">https://www.zaproxy.org/docs/alerts/10110/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-749</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>10202</key>
        <name>Absence of Anti-CSRF Tokens</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Check standard headers to verify the request is same origin and Check CSRF token.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">CSRF Prevention Cheat Sheet</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/352.html">https://cwe.mitre.org/data/definitions/352.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/10202/">https://www.zaproxy.org/docs/alerts/10202/</a></li>    

    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-9</tag>
        <tag>cweid-352</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>20012</key>
        <name>Anti-CSRF Tokens Check</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your application is free of cross-site scripting issues, because most CSRF defenses can be bypassed using attacker-controlled script.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Cross-Site-Request-Forgery">https://projects.webappsec.org/Cross-Site-Request-Forgery</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/352.html">CWE-352</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/20012/">https://www.zaproxy.org/docs/alerts/20012/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-352</tag>
        <tag>wascid-9</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>20014</key>
        <name>HTTP Parameter Pollution</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Properly sanitize the user input for parameter delimiters</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.google.com/search?q=http+parameter+pollution">https://www.google.com/search?q=http+parameter+pollution</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/20014/">https://www.zaproxy.org/docs/alerts/20014/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>20015</key>
        <name>Heartbleed OpenSSL Vulnerability</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Update to OpenSSL 1.0.1g or later. Re-issue HTTPS certificates. Change asymmetric private keys and shared secret keys, since these may have been compromised, with no evidence of compromise in the server log files.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cvedetails.com/cve-details.php?t=1&cve_id=CVE-2014-0160">https://cvedetails.com/cve-details.php?t=1&cve_id=CVE-2014-0160</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/119.html">CWE-119</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/20015/">https://www.zaproxy.org/docs/alerts/20015/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-119</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>20016</key>
        <name>Cross-Domain Misconfiguration</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Correct/Add cross domain policy</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html">https://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/264.html">CWE-264</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/20016/">https://www.zaproxy.org/docs/alerts/20016/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-264</tag>
        <tag>wascid-14</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>20017</key>
        <name>Source Code Disclosure - CVE-2012-1823</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Improper input handling is one of the most common weaknesses identified across applications today. Poorly handled input is a leading cause behind critical vulnerabilities that exist in systems and applications.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Improper-Input-Handling">https://projects.webappsec.org/Improper-Input-Handling</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/20017/">https://www.zaproxy.org/docs/alerts/20017/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>20018</key>
        <name>Remote Code Execution - CVE-2012-1823</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Improper input handling is one of the most common weaknesses identified across applications today. Poorly handled input is a leading cause behind critical vulnerabilities that exist in systems and applications.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Improper-Input-Handling">https://projects.webappsec.org/Improper-Input-Handling</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/20.html">CWE-20</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/20018/">https://www.zaproxy.org/docs/alerts/20018/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-20</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>20019</key>
        <name>External Redirect</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
    specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on
    looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or
    determining which inputs are so malformed that they should be rejected outright.
    When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values,
    missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be
    syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
    Use a whitelist of approved URLs or domains to be used for redirection.
    Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving your site. Implement a long timeout before the
    redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems when generating the disclaimer page.
    When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs)
    to the actual filenames or URLs, and reject all other inputs.
    For example, ID 1 could map to "/login.asp" and ID 2 could map to "https://www.example.com/". Features such as the ESAPI AccessReferenceMap provide this
    capability.
    Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network,
    environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide
    data to the application. Remember that such inputs may be obtained indirectly through API calls.
    Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/URL-Redirector-Abuse">URL Redirector Abuse</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/601.html">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/20019/">https://www.zaproxy.org/docs/alerts/20019/</a></li>    
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>wascid-38</tag>
        <tag>cweid-601</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>30001</key>
        <name>Buffer Overflow</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Rewrite the background program using proper return length checking.  This will require a recompile of the background executable.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-community/attacks/Buffer_overflow_attack">https://owasp.org/www-community/attacks/Buffer_overflow_attack</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/120.html">CWE-120</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/30001/">https://www.zaproxy.org/docs/alerts/30001/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-120</tag>
        <tag>wascid-7</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>30002</key>
        <name>Check for proper format string handling in back end c code</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Many of the back end interfaces use a secondary programming language, often compiled,
       to interface to a variety of system functions.  C and C++ are two of the more popular
       "traditional" languages that are used.  The Format String exploit occurs when the submitted
       data of an input string is evaluated as a command by the application. In this way,
       the attacker could execute code, read the stack, or cause a segmentation fault in the
       running application, causing new behaviors that could compromise the security or the
       stability of the system.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.zaproxy.org/docs/alerts/30002/">https://www.zaproxy.org/docs/alerts/30002/</a></li>    
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>30003</key>
        <name>Integer Overflow Error</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Rewrite the background program using proper checking of the size of integer being input to prevent overflows and divide by 0 errors.  This will require a recompile of the background executable.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/w/page/13246946/Integer%20Overflows">https://projects.webappsec.org/w/page/13246946/Integer%20Overflows</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/190.html">CWE-190</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/30003/">https://www.zaproxy.org/docs/alerts/30003/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-190</tag>
        <tag>wascid-3</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40003</key>
        <name>CRLF Injection</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Type check the submitted parameter carefully.  Do not allow CRLF to be injected by filtering CRLF.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.securityfocus.com/bid/9804">Multiple Vendor HTTP Response Splitting Vulnerability</a></li>
    <li><a href="https://www.owasp.org/index.php/HTTP_Response_Splitting">HTTP Response Splitting</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/113.html">https://cwe.mitre.org/data/definitions/113.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40003/">https://www.zaproxy.org/docs/alerts/40003/</a></li>    

    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>wascid-25</tag>
        <tag>cweid-113</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40008</key>
        <name>Parameter Tampering</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Identify the cause of the error and fix it.  Do not trust client side input and enforce a tight check in the server side.  Besides, catch the exception
    properly.  Use a generic 500 error page for internal server error.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/472.html">https://cwe.mitre.org/data/definitions/472.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40008/">https://www.zaproxy.org/docs/alerts/40008/</a></li>        
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>wascid-20</tag>
        <tag>cweid-472</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40009</key>
        <name>Server Side Include</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input and enforce a tight check in the server side.  Disable server side includes.</br>
    Refer to manual to disable Sever Side Include.</br>
    Use least privilege to run your web server or application server.</br>
    For Apache, disable the following:
    <ul>
    <li>Options Indexes FollowSymLinks Includes</li>
    <li>AddType application/x-httpd-cgi .cgi</li>
    <li>AddType text/x-server-parsed-html .html</li>
    </ul>
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.carleton.ca/~dmcfet/html/ssi.html">Server Side Includes</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/97.html">https://cwe.mitre.org/data/definitions/97.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40009/">https://www.zaproxy.org/docs/alerts/40009/</a></li>        
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-31</tag>
        <tag>cweid-97</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40012</key>
        <name>Cross Site Scripting (Reflected)</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    Phase: Architecture and Design
    <p>
    Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
    Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
    </p>
    Phases: Implementation; Architecture and Design
    <p>
    Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
    For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
    Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.
    </p>
    Phase: Architecture and Design
    <p>
    For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
    If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
    </p>
    Phase: Implementation
    <p>
    For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
    To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
    Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
    When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
    Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Cross-Site-Scripting">Cross Site Scripting</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40012/">https://www.zaproxy.org/docs/alerts/40012/</a></li>        
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-8</tag>
        <tag>cweid-79</tag>
        <tag>owasp-a7</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40013</key>
        <name>Session Fixation</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Prevent the attacker from gaining a session id by enforcing strict session ids, and by only allocating session ids upon successful authentication to the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-community/attacks/Session_fixation">https://owasp.org/www-community/attacks/Session_fixation</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/384.html">CWE-384</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40013/">https://www.zaproxy.org/docs/alerts/40013/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-384</tag>
        <tag>wascid-37</tag>
        <tag>owasp-a2</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40014</key>
        <name>Cross Site Scripting (Persistent)</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    Phase: Architecture and Design
    <p>
    Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
    Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
    </p>
    Phases: Implementation; Architecture and Design
    <p>
    Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
    For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
    Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.
    </p>
    Phase: Architecture and Design
    <p>
    For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
    If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
    </p>
    Phase: Implementation
    <p>
    For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
    To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
    Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
    When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
    Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Cross-Site-Scripting">Cross Site Scripting</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40014/">https://www.zaproxy.org/docs/alerts/40014/</a></li>        
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-8</tag>
        <tag>cweid-79</tag>
        <tag>owasp-a7</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40016</key>
        <name>Cross Site Scripting (Persistent) - Prime</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>N/A</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/79.html">https://cwe.mitre.org/data/definitions/79.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40016/">https://www.zaproxy.org/docs/alerts/40016/</a></li>            
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>wascid-8</tag>
        <tag>cweid-79</tag>
        <tag>owasp-a7</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40017</key>
        <name>Cross Site Scripting (Persistent) - Spider</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>N/A</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/79.html">https://cwe.mitre.org/data/definitions/79.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40017/">https://www.zaproxy.org/docs/alerts/40017/</a></li>        
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>wascid-8</tag>
        <tag>cweid-79</tag>
        <tag>owasp-a7</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40018</key>
        <name>SQL Injection</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. In general, type check all data on the server side.</br>
    If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'</br>
    If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.</br>
    If database Stored Procedures can be used, use them.</br>
    Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!</br>
    Do not create dynamic SQL queries using simple string concatenation.</br>
    Escape all data received from the client.</br>
    Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.</br>
    Apply the privilege of least privilege by using the least privileged database user possible.</br>
    In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.</br>
    Grant the minimum database access that is necessary for the application.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/Top_10_2010-A1">Top 10 2010-A1-Injection</a></li>
    <li><a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">SQL Injection Prevention Cheat Sheet</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">https://cwe.mitre.org/data/definitions/89.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40018/">https://www.zaproxy.org/docs/alerts/40018/</a></li>        
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-19</tag>
        <tag>cweid-89</tag>
        <tag>owasp-a1</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40019</key>
        <name>SQL Injection - MySQL</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. 
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the privilege of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40019/">https://www.zaproxy.org/docs/alerts/40019/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-89</tag>
        <tag>wascid-19</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40020</key>
        <name>SQL Injection - Hypersonic SQL</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. 
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the privilege of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40020/">https://www.zaproxy.org/docs/alerts/40020/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-89</tag>
        <tag>wascid-19</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40021</key>
        <name>SQL Injection - Oracle</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. 
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the privilege of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40021/">https://www.zaproxy.org/docs/alerts/40021/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-89</tag>
        <tag>wascid-19</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40022</key>
        <name>SQL Injection - PostgreSQL</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. 
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the privilege of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40022/">https://www.zaproxy.org/docs/alerts/40022/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-89</tag>
        <tag>wascid-19</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40023</key>
        <name>Possible Username Enumeration</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not divulge details of whether a username is valid or invalid. In particular, for unsuccessful login attempts, do not differentiate between an invalid user and an invalid password in the error message, page title, page contents, HTTP headers, or redirection logic.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account.html">https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40023/">https://www.zaproxy.org/docs/alerts/40023/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40024</key>
        <name>SQL Injection - SQLite</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. 
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the privilege of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40024/">https://www.zaproxy.org/docs/alerts/40024/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-89</tag>
        <tag>wascid-19</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40025</key>
        <name>Proxy Disclosure</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Disable the 'TRACE' method on the proxy servers, as well as the origin web/application server.
Disable the 'OPTIONS' method on the proxy servers, as well as the origin web/application server, if it is not required for other purposes, such as 'CORS' (Cross Origin Resource Sharing).
Configure the web and application servers with custom error pages, to prevent 'fingerprintable' product-specific error pages being leaked to the user in the event of HTTP errors, such as 'TRACK' requests for non-existent pages.
Configure all proxies, application servers, and web servers to prevent disclosure of the technology and version information in the 'Server' and 'X-Powered-By' HTTP response headers.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://tools.ietf.org/html/rfc7231#section-5.1.2">https://tools.ietf.org/html/rfc7231#section-5.1.2</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40025/">https://www.zaproxy.org/docs/alerts/40025/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-45</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40026</key>
        <name>Cross Site Scripting (DOM Based)</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Phase: Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Cross-Site-Scripting">https://projects.webappsec.org/Cross-Site-Scripting</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/79.html">CWE-79</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40026/">https://www.zaproxy.org/docs/alerts/40026/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-79</tag>
        <tag>wascid-8</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40027</key>
        <name>SQL Injection - MsSQL</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. 
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the privilege of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">CWE-89</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40027/">https://www.zaproxy.org/docs/alerts/40027/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-89</tag>
        <tag>wascid-19</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40028</key>
        <name>ELMAH Information Leak</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Consider whether or not ELMAH is actually required in production, if it isn't then disable it. If it is then ensure access to it requires authentication and authorization. See also: https://elmah.github.io/a/securing-error-log-pages/</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.troyhunt.com/aspnet-session-hijacking-with-google/">https://www.troyhunt.com/aspnet-session-hijacking-with-google/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/215.html">CWE-215</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40028/">https://www.zaproxy.org/docs/alerts/40028/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-215</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40029</key>
        <name>Trace.axd Information Leak</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Consider whether or not Trace Viewer is actually required in production, if it isn't then disable it. If it is then ensure access to it requires authentication and authorization.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://msdn.microsoft.com/en-us/library/bb386420.aspx">ASP.NET Tracing Overview</a></li>
    <li><a href="https://msdn.microsoft.com/en-us/library/wwh16c6c.aspx">How to: View ASP.NET Trace Information with the Trace Viewer</a></li>
    <li><a href="https://www.dotnetperls.com/trace">ASP.NET Trace Examples - Dot Net Perls</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/215.html">https://cwe.mitre.org/data/definitions/215.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/40029/">https://www.zaproxy.org/docs/alerts/40029/</a></li>        
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>cweid-215</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>40032</key>
        <name>.htaccess Information Leak</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure the .htaccess file is not accessible.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/215.html">CWE-215</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40032/">https://www.zaproxy.org/docs/alerts/40032/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-215</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40034</key>
        <name>.env Information Leak</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure the .env file is not accessible.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.google.com/search?q=db_password+filetype%3Aenv">https://www.google.com/search?q=db_password+filetype%3Aenv</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/215.html">CWE-215</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40034/">https://www.zaproxy.org/docs/alerts/40034/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-215</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>40035</key>
        <name>Hidden File Finder</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Consider whether or not the component is actually required in production, if it isn't then disable it. If it is then ensure access to it requires appropriate authentication and authorization, or limit exposure to internal systems or specific source IPs, etc.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://blog.hboeck.de/archives/892-Introducing-Snallygaster-a-Tool-to-Scan-for-Secrets-on-Web-Servers.html">https://blog.hboeck.de/archives/892-Introducing-Snallygaster-a-Tool-to-Scan-for-Secrets-on-Web-Servers.html</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/538.html">CWE-538</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/40035/">https://www.zaproxy.org/docs/alerts/40035/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-538</tag>
        <tag>wascid-13</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>50001</key>
        <name>Script Passive Scan Rules</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>
    N/A
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/89.html">https://cwe.mitre.org/data/definitions/89.html</a></li>
    <li><a href="https://www.zaproxy.org/docs/alerts/50001/">https://www.zaproxy.org/docs/alerts/50001/</a></li>            
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-19</tag>
        <tag>cweid-89</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>90001</key>
        <name>Insecure JSF ViewState</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Protect the ViewState value.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.zaproxy.org/docs/alerts/90001/">https://www.zaproxy.org/docs/alerts/90001/</a></li>            
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>90002</key>
        <name>Java Serialization Object</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Deserialization of untrusted data is inherently dangerous and should be avoided.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.oracle.com/technetwork/java/seccodeguide-139067.html#8">https://www.oracle.com/technetwork/java/seccodeguide-139067.html#8</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/502.html">CWE-502</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90002/">https://www.zaproxy.org/docs/alerts/90002/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-502</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90003</key>
        <name>Sub Resource Integrity Attribute Missing</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Provide a valid integrity attribute to the tag.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://developer.mozilla.org/en/docs/Web/Security/Subresource_Integrity">https://developer.mozilla.org/en/docs/Web/Security/Subresource_Integrity</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90003/">https://www.zaproxy.org/docs/alerts/90003/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90004</key>
        <name>Insufficient Site Isolation Against Spectre Vulnerability</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that the application/web server sets the Cross-Origin-Resource-Policy header appropriately, and that it sets the Cross-Origin-Resource-Policy header to 'same-origin' for all web pages.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)">https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90004/">https://www.zaproxy.org/docs/alerts/90004/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>cweid-16</tag>
        <tag>wascid-14</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90011</key>
        <name>Charset Mismatch</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>The declaration in the HTTP Content-Type header doesn't match what is declared in a META Content-Type tag, or
    the declaration in the HTTP Content-Type header doesn't match what is declared in a META Charset tag. Another possibility is that
    the response doesn't contain a META Content-Type declaration, which may overlook older clients. Correct the declarations.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.w3.org/TR/html401/charset.html#h-5.2.2">Charset</a></li>
    <li><a href="https://www.w3.org/TR/html5/document-metadata.html#charset">Document Metadata Charset</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/90011/">https://www.zaproxy.org/docs/alerts/90011/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>90017</key>
        <name>XSLT Injection</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Sanitize and analyze every user input coming from any client-side.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.contextis.com/blog/xslt-server-side-injection-attacks">https://www.contextis.com/blog/xslt-server-side-injection-attacks</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/91.html">CWE-91</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90017/">https://www.zaproxy.org/docs/alerts/90017/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-91</tag>
        <tag>wascid-23</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90019</key>
        <name>Server Side Code Injection</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust client side input, even if there is client side validation in place. </br>
    In general, type check all data on the server side and escape all data received from the client.</br>
    Avoid the use of eval() functions combined with user input data.
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>
    <li><a href="https://www.owasp.org/index.php/Direct_Dynamic_Code_Evaluation_('Eval_Injection')">Direct Dynamic Code Evaluation ('Eval Injection')</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/90019/">https://www.zaproxy.org/docs/alerts/90019/</a></li>
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>cweid-94</tag>
        <tag>owasp-a9</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>90020</key>
        <name>Remote OS Command Injection</name>

        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>If at all possible, use library calls rather than external processes to recreate the desired functionality.
    Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict
    which files can be accessed in a particular directory or which commands can be executed by your software.

    OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in
    the Java SecurityManager allows you to specify restrictions on file operations.
    This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.

    For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications,
    this may require storing the command locally in the session's state instead of sending it out to the client in a hidden form field.

    Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

    For example, consider using the ESAPI Encoding control or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less
    prone to error.

    If you need to use dynamically-generated query strings or commands in spite of the risk, properly quote arguments and escape any special characters within those
    arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not
    alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be
    careful of argument injection.

    If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead
    of the command line.

    If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant
    quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

    Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single
    string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For
    example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of
    strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then
    it will quote each of the arguments.

    Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
    specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for
    malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are
    so malformed that they should be rejected outright.

    When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or
    extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid
    because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."

    When constructing OS command strings, use stringent whitelists that limit the character set based on the expected value of the parameter in the request. This will
    indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.

    Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide
    some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially
    if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the
    subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the
    character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user
    intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass
    messages to other components.

    Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from
    injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack
    surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.</solution>
    </p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/78.html">CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')</a></li>
    <li><a href="https://www.owasp.org/index.php/Command_Injection">Command Injection</a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/90020/">https://www.zaproxy.org/docs/alerts/90020/</a></li>
    </ul>]]>
        </description>
        <severity>CRITICAL</severity>
        <status>READY</status>
        <tag>wascid-31</tag>
        <tag>cweid-78</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>90021</key>
        <name>XPath Injection</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane.

Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XPath queries is safe in that context.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/XPath-Injection">https://projects.webappsec.org/XPath-Injection</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/643.html">CWE-643</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90021/">https://www.zaproxy.org/docs/alerts/90021/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-643</tag>
        <tag>wascid-39</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90022</key>
        <name>Application Error Disclosure</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Review the source code of this page. Implement custom error pages. Consider implementing a mechanism to provide a unique error reference/identifier to
    the client (browser) while logging the details on the server side and not exposing them to the user.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90022/">https://www.zaproxy.org/docs/alerts/90022/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>wascid-13</tag>
        <tag>cweid-200</tag>
        <tag>owasp-a6</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>    
    <rule>
        <key>90023</key>
        <name>XML External Entity Attack</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Disable processing of External Entities.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/XML-External-Entities">https://projects.webappsec.org/XML-External-Entities</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/611.html">CWE-611</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90023/">https://www.zaproxy.org/docs/alerts/90023/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-611</tag>
        <tag>wascid-43</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90024</key>
        <name>Generic Padding Oracle</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Update the affected server software, or modify the scripts so that they properly validate encrypted data before attempting decryption.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://netifera.com/research/">https://netifera.com/research/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/209.html">CWE-209</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90024/">https://www.zaproxy.org/docs/alerts/90024/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-209</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90025</key>
        <name>Expression Language Injection</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Perform data validation best practice against untrusted input and to ensure that output encoding is applied when data arrives on the EL layer, so that no metacharacter is found by the interpreter within the user content before evaluation. The most obvious patterns to detect include ${ and #{, but it may be possible to encode or fragment this data.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/XPath-Injection">https://projects.webappsec.org/XPath-Injection</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/917.html">CWE-917</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90025/">https://www.zaproxy.org/docs/alerts/90025/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-917</tag>
        <tag>wascid-20</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90027</key>
        <name>Cookie Slack Detector</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>TBA.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Fingerprinting">https://projects.webappsec.org/Fingerprinting</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90027/">https://www.zaproxy.org/docs/alerts/90027/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-45</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90028</key>
        <name>Insecure HTTP Method</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>TBA.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://projects.webappsec.org/Fingerprinting">https://projects.webappsec.org/Fingerprinting</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/200.html">CWE-200</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90028/">https://www.zaproxy.org/docs/alerts/90028/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>cweid-200</tag>
        <tag>wascid-45</tag>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>90030</key>
        <name>WSDL File Passive Scanner</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>
    N/A
    </p>
    <h3>References:</h3>
    <ul>
	<li><a href="https://www.zaproxy.org/docs/alerts/90030/">https://www.zaproxy.org/docs/alerts/90030/</a></li>
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>90033</key>
        <name>Loosely Scoped Cookie</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Always scope cookies to a FQDN (Fully Qualified Domain Name).</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li><a href="https://tools.ietf.org/html/rfc6265#section-4.1/></li>
    <li><a href="https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)/></li>
    <li><a href="https://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies/></li>
    <li><a href="https://cwe.mitre.org/data/definitions/565.html">CWE-565</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/90033/">https://www.zaproxy.org/docs/alerts/90033/</a></li>       
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>wascid-15</tag>
        <tag>cweid-565</tag>
    </rule>
    <rule>
        <key>90034</key>
        <name>Cloud Metadata Potentially Exposed</name>
        <description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
            <![CDATA[<h3>Solution :</h3>
    <p>Do not trust any user data in NGINX configs. In this case it is probably the use of the $host variable which is set from the 'Host' header and can be controlled by an attacker.</p>
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.nginx.com/blog/trust-no-one-perils-of-trusting-user-input/">https://www.nginx.com/blog/trust-no-one-perils-of-trusting-user-input//a></li>
	<li><a href="https://www.zaproxy.org/docs/alerts/90034/">https://www.zaproxy.org/docs/alerts/90034/</a></li>
    </ul>]]>
        </description>
        <severity>MAJOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule> 
    <rule>
        <key>100000</key>
        <name>A Server Error response code was returned by the server</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>A response code of 400 was returned by the server.</p><p>This may indicate that the application is failing to handle unexpected input correctly.</p><p>Fix the handling of unexpected input.</p>
    N/A
    <h3>References:</h3>
    <ul>
	<li><a href="https://www.zaproxy.org/docs/alerts/100000/">https://www.zaproxy.org/docs/alerts/100000/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
    </rule>
    <rule>
        <key>100001</key>
        <name>Unexpected Content-Type was returned</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>A Content-Type that was returned is not one of the types expected to be returned by an API. Fix the Content-Type header.</p>
    N/A
    <h3>References:</h3>
    <ul>
	<li><a href="https://www.zaproxy.org/docs/alerts/100001/">https://www.zaproxy.org/docs/alerts/100001/</a></li>
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>10038</key>
        <name>Content Security Policy (CSP) Header Not Set</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is configured to set the Content-Security-Policy header, to achieve optimal browser support: &quot;Content-Security-Policy&quot; for Chrome 25+, Firefox 23+ and Safari 7+, &quot;X-Content-Security-Policy&quot; for Firefox 4.0+ and Internet Explorer 10+, and &quot;X-WebKit-CSP&quot; for Chrome 14+ and Safari 6+</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li><a href="https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy">https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy</a></li>
    <li><a href="https://content-security-policy.com/">https://content-security-policy.com/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10038/">https://www.zaproxy.org/docs/alerts/10038/</a></li>       
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>10035</key>
        <name>Content Security Policy (CSP) Header Not Set</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Ensure that your web server, application server, load balancer, etc. is configured to enforce Strict-Transport-Security.</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li><a href="https://www.owasp.org/index.php/HTTP_Strict_Transport_Security">https://www.owasp.org/index.php/HTTP_Strict_Transport_Security</a></li>
    <li><a href="https://content-security-policy.com/">https://content-security-policy.com/</a></li>
    <li><a href="https://cwe.mitre.org/data/definitions/16.html">CWE-16</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10035/">https://www.zaproxy.org/docs/alerts/10035/</a></li>       
    </ul>]]>
        </description>
        <severity>MINOR</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-16</tag>
        <tag>wascid-15</tag>
        <tag>owasp-a6</tag>
    </rule>
    <rule>
        <key>10049</key>
        <name>Storable and Cacheable Content</name>
        <description>
            <![CDATA[<h3>Solution :</h3>
    <p>Validate that the response does not contain sensitive, personal or user-specific information.  If it does, consider the use of the following HTTP response headers, to limit, or prevent the content being stored and retrieved from the cache by another user:&lt;/p&gt;&lt;p&gt;Cache-Control: no-cache, no-store, must-revalidate, private&lt;/p&gt;&lt;p&gt;Pragma: no-cache&lt;/p&gt;&lt;p&gt;Expires: 0&lt;/p&gt;&lt;p&gt;This configuration directs both HTTP 1.0 and HTTP 1.1 compliant caching servers to not store the response, and to not retrieve the response (without validation) from the cache, in response to a similar request.</p>
    N/A
    <h3>References:</h3>
    <ul>
    <li>&lt;p&gt;https://tools.ietf.org/html/rfc7234&lt;/p&gt;&lt;p&gt;https://tools.ietf.org/html/rfc7231&lt;/p&gt;&lt;p&gt;https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html (obsoleted by rfc7234)&lt;/p&gt;</li>
    <li><a href="https://cwe.mitre.org/data/definitions/524.html">CWE-524</a></li>    
	<li><a href="https://www.zaproxy.org/docs/alerts/10049/">https://www.zaproxy.org/docs/alerts/10049/</a></li>       
    </ul>]]>
        </description>
        <severity>INFO</severity>
        <status>READY</status>
        <tag>security</tag>
        <tag>zaproxy</tag>
        <tag>cweid-524</tag>
        <tag>wascid-13</tag>
        <tag>owasp-a3</tag>
    </rule>
</rules>