Remove X-XSS-Protection remediation advice header (#342)

* Remove p5 variant

Remove remediation advice for P5 XSS VRT entry

* remove xss protection remediation advice

Removed the 11th remediation advice on XSS P3 VRT entry

* Empty Remediation advice for P5-X-XSS-Protection header

Empty Remediation advice for P5-X-XSS-Protection header

* references can be zero

* Revert "references can be zero"

This reverts commit d6b3f19.

* ignore DS_STORE

* Empty reference for passing tests

* Remove

---------

Co-authored-by: Amal Murali <amalmurali47@gmail.com>

.gitignore

@@ -2,4 +2,5 @@
 *~
 
 # vscode config
-.vscode/
+.vscode/
+.DS_STORE

mappings/remediation_advice/remediation_advice.json

@@ -419,11 +419,7 @@
             },
             {
               "id": "x_xss_protection",
-              "remediation_advice": "As a best practice, consider using the `X-XSS-Protection` header as it will help ensure browsers that support this header will detect and help mitigate against reflected Cross Site Scripting. It is important to note that this will not completely mitigate against all reflected Cross Site Scripting attacks, but will help prevent many generic injection attacks.",
-              "references": [
-                "https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xxxsp_bp",
-                "https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection"
-              ]
+              "remediation_advice": ""
             },
             {
               "id": "strict_transport_security",
@@ -854,7 +850,7 @@
     },
     {
       "id": "cross_site_scripting_xss",
-      "remediation_advice": "1. Always treat all user input as untrusted data.\n2. Never insert untrusted data except in allowed locations.\n3. Always input or output-encode all data coming into or out of the application.\n4. Always whitelist allowed characters and seldom use blacklisting of characters except in certain use cases.\n5. Always use a well-known and security encoding API for input and output encoding such as the `OWASP ESAPI`.\n6. Never try to write input and output encoders unless absolutely necessary. Chances are that someone has already written a good one.\n7. Never use the DOM function `innerHtml` and instead use the functions `innerText` and `textContent` to prevent against DOM-based XSS.\n8. As a best practice, consider using the `HTTPOnly` flag on cookies that are session tokens or sensitive tokens.\n9. As a best practice, consider implementing `Content Security Policy` to protect against XSS and other injection type attacks.\n10. As a best practice, consider using an auto-escaping templating system.\n11. As a best practice, consider using the `X-XSS-Protection` response header.",
+      "remediation_advice": "1. Always treat all user input as untrusted data.\n2. Never insert untrusted data except in allowed locations.\n3. Always input or output-encode all data coming into or out of the application.\n4. Always whitelist allowed characters and seldom use blacklisting of characters except in certain use cases.\n5. Always use a well-known and security encoding API for input and output encoding such as the `OWASP ESAPI`.\n6. Never try to write input and output encoders unless absolutely necessary. Chances are that someone has already written a good one.\n7. Never use the DOM function `innerHtml` and instead use the functions `innerText` and `textContent` to prevent against DOM-based XSS.\n8. As a best practice, consider using the `HTTPOnly` flag on cookies that are session tokens or sensitive tokens.\n9. As a best practice, consider implementing `Content Security Policy` to protect against XSS and other injection type attacks.\n10. As a best practice, consider using an auto-escaping templating system.",
       "references": [
         "https://www.owasp.org/index.php/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
         "https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)",