{PRODUCT} detected that password data is being transmitted over HTTP.

{PRODUCT} detected that insecure transportation security protocol (SSLv3) is supported by your web server.

SSLv3 has several flaws. An attacker can cause connection failures and they can trigger the use of SSL 3.0 to exploit vulnerabilities like POODLE.

{PRODUCT} detected that autocomplete is enabled in one or more of the form fields which might contain sensitive information like "username", "credit card" or "CVV".

{PRODUCT} identified that the target web server is disclosing the Ruby version in its HTTP response. This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Ruby.

{PRODUCT} identified that the target web server is disclosing the WEBrick version in its HTTP response. This information might help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of WEBrick.

{PRODUCT} detected that insecure transportation security protocol (TLS 1.0) is supported by your web server.

TLS 1.0 has several flaws. An attacker can cause connection failures and they can trigger the use of TLS 1.0 to exploit vulnerabilities like BEAST (Browser Exploit Against SSL/TLS).

Websites using TLS 1.0 will be considered non-compliant by PCI after 30 June 2018.

{PRODUCT} detected a Robots.txt file with potentially sensitive content.

{PRODUCT} detected that autocomplete is enabled in one or more of the password fields.

{PRODUCT} identified the target web site is using Ruby and detected that it is out of date.

{PRODUCT} identified the target web site is using jQuery and detected that it is out of date.

{PRODUCT} identified the target web site is using jQuery UI Dialog and detected that it is out of date.

{PRODUCT} identified the target web site is using jQuery UI Autocomplete and detected that it is out of date.

{PRODUCT} identified the target web site is using jQuery UI Tooltip and detected that it is out of date.

{PRODUCT} detected a missing X-XSS-Protection header which means that this website could be at risk of a Cross-site Scripting (XSS) attacks.

Cookies are typically sent to third parties in cross origin requests. This can be abused to do CSRF attacks. Recently a new cookie attribute named SameSite was proposed to disable third-party usage for some cookies, to prevent CSRF attacks.

Same-site cookies allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.

CSP is a added layer of security against that helps to mitigate mainly Cross-site Scripting attacks.

CSP can be enabled instructing the browser with a Content-Security-Policy directive in a response header;

 Content-Security-Policy: script-src 'self';

or in a meta tag;

<meta http-equiv="Content-Security-Policy" content="script-src 'self';"> 

In the above example, you can restrict script loading only to same domain. It will also restrict inline script executions both in element attribute and event handler. There are various directives which you can use declaring CSP:

• script-src: Restricts the script loading resources to the ones you declared. By default, it disables inline script executions unless you permit to the evaluation functions and inline scripts by the unsafe-eval and unsafe-inline keywords.
• base-uri:  Base element is used to resolve relative URL to absolute one. By using this CSP directive, you can define all possible URLs which could be assigned to base-href attribute of the document.
• frame-ancestors:  It is very similar to X-Frame-Options HTTP header. It defines the URLs by which the page can be loaded in an iframe.
• frame-src   / child-src: frame-src is the deprecated version of child-src. Both define the sources that can be loaded by iframe in the page.
• object-src : Defines the resources that can be loaded by embedding such as Flash files, Java Applets.
• img-src: As its name implies, it defines the resources where the images can be loaded from.
• connect-src: Defines the whitelisted targets for XMLHttpRequest and WebSocket objects.
• default-src: It is a fallback for the directives that mostly ends with -src prefix. When the directives below are not defined, the value set to default-src will be used:
• child-src
• connect-src
• font-src
• img-src
• manifest-src
• media-src
• object-src
• script-src
• style-src

When setting the CSP directives, you can also use some CSP keywords:

• none: When used, it denies all resources loadings.
• self : It points to the document's URL (domain + port).
• unsafe-inline: It permits running inline scripts .
• unsafe-eval: It permits execution of evaluations function such as eval().

In addition to CSP keywords, you can also use wildcard or only a schema when defining whitelist URLs for the points. Wildcard can be used for subdomain and port portions of the URLs:

Content-Security-Policy: script-src https://*.example.com;

Content-Security-Policy: script-src https://example.com:*;

Content-Security-Policy: script-src https;

It is also possible to set a CSP in Report-Only mode instead of forcing it immediately in the migration period. Thus you can see the violations of the CSP policy in the current state of your web site while migrating to CSP:

Content-Security-Policy-Report-Only: script-src 'self'; report-uri: https://example.com;