ZAP Scanning Report

script-src includes unsafe-inline.

Ensure that your web server, application server, load balancer, etc. is properly configured to set the Content-Security-Policy header.

http://www.w3.org/TR/CSP2/

http://www.w3.org/TR/CSP/

http://caniuse.com/#search=content+security+policy

http://content-security-policy.com/

https://github.com/shapesecurity/salvation

https://developers.google.com/web/fundamentals/security/csp#policy_applies_to_a_wide_variety_of_resources

style-src includes unsafe-inline.

Ensure that your web server, application server, load balancer, etc. is properly configured to set the Content-Security-Policy header.

http://www.w3.org/TR/CSP2/

http://www.w3.org/TR/CSP/

http://caniuse.com/#search=content+security+policy

http://content-security-policy.com/

https://github.com/shapesecurity/salvation

https://developers.google.com/web/fundamentals/security/csp#policy_applies_to_a_wide_variety_of_resources

The following directives either allow wildcard sources (or ancestors), are not defined, or are overly broadly defined:

frame-ancestors, form-action

The directive(s): frame-ancestors, form-action are among the directives that do not fallback to default-src, missing/excluding them is the same as allowing anything.

Ensure that your web server, application server, load balancer, etc. is properly configured to set the Content-Security-Policy header.

http://www.w3.org/TR/CSP2/

http://www.w3.org/TR/CSP/

http://caniuse.com/#search=content+security+policy

http://content-security-policy.com/

https://github.com/shapesecurity/salvation

https://developers.google.com/web/fundamentals/security/csp#policy_applies_to_a_wide_variety_of_resources

X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.

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. Alternatively consider implementing Content Security Policy's "frame-ancestors" directive.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

A cookie has been set without the HttpOnly flag, which means that the cookie can be accessed by JavaScript. If a malicious script can be run on this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible.

Ensure that the HttpOnly flag is set for all cookies.

https://owasp.org/www-community/HttpOnly

A cookie has been set with an invalid SameSite attribute value, which means that the cookie can be sent as a result of a 'cross-site' request. The SameSite attribute is an effective counter measure to cross-site request forgery, cross-site script inclusion, and timing attacks.

Ensure that the SameSite attribute is set to either 'lax' or ideally 'strict' for all cookies.

https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site

A cookie has been set without the secure flag, which means that the cookie can be accessed via unencrypted connections.

Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted channel. Ensure that the secure flag is set for cookies containing such sensitive information.

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes.html

The cache-control and pragma HTTP header have not been set properly or are missing allowing the browser and proxies to cache content.

Whenever possible ensure the cache-control HTTP header is set with no-cache, no-store, must-revalidate; and that the pragma HTTP header is set with no-cache.

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#web-content-caching

The web/application server is leaking information via one or more "X-Powered-By" HTTP response headers. Access to such information may facilitate attackers identifying other frameworks/components your web application is reliant upon and the vulnerabilities such components may be subject to.

Ensure that your web server, application server, load balancer, etc. is configured to suppress "X-Powered-By" headers.

http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx

http://www.troyhunt.com/2012/02/shhh-dont-let-your-response-headers.html