Web Cookies Scanner

X-XSS-Protection: 0

Controls an Cross-Site Scripting (XSS) filters built into the majority of web browsers. The filter is usually turned on by default anyway, but requirement to set the header to 1 became part of canonical set of "secure" HTTP headers. Over time, vulnerabilities in the "sanitizing" mode filter were found, so 1; mode=block became the recommended value. Some companies decided that they don't really need a browser-side XSS filter to mess with their web services which are XSS-free anyway and they became consciously disabling the XSS filter by setting the header to 0.

X-Content-Type-Options: nosniff

A non-standard but widely accepted header introduced originally by Microsoft to disable "content sniffing" or heuristic content type discovery in absence or mismatch of a proper HTTP Content-Type declaration, which led to a number of web attacks. In general, presence of the header with its only defined value of nosniff is considered as part of a properly secured HTTP response.

Access-Control-Allow-Origin: *

Controls origins (websites) that are allowed to load data from this web service over JavaScript-based APIs as part of Cross-Origin Resource Sharing (CORS) standard. By default, a web browser will refuse to load data over XmlHttpRequest from a website that is not in the same origin, which is a precaution against various types of data stealing attacks. The target server has to explicitly allow the origin domain using the Access-Control-Allow-Origin (ACAO) header, or it may allow all origins to access it using a wildcard *. The latter however creates a potential security issue if the website in question is transactional and processing sensitive data, so the wildcard should be only used on websites consciously offering public APIs.

Content-Security-Policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self';

Content Security Policy is used by a web server to declare a list of trusted content types (images, scripts, media etc) and origins from which they can be safely loaded as intended by the website authors. The Content-Security-Policy-Report-Only header instruct the browser to enable CSP in enforcement mode.

default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self';

• Policy delivery method: Content-Security-Policy
• Enforcement: True

• No base-uri allows attackers to inject base tags which override the base URI to an attacker-controlled origin. Set to 'none' unless you need to handle tricky relative URLs scheme

• Consider adding block-all-mixed-content directive if your website is only accessible over TLS and you are certain it doesn not have any legacy plaintext resources. Otherwise you may add adding upgrade-insecure-requests directive if your website may still have some legacy plaintext HTTP resources and you want them to be still available rather than blocked

• Policy that has script-src but not object-src allows script execution by injecting plugin resources. Please read our CSP guidance for more details for more details

• The default-src data: origin allows bypassing CSP and execution of inlined untrusted scripts

• The script-src data: origin allows bypassing CSP and execution of inlined untrusted scripts

• You should definitely try using 'strict-dynamic' to eliminate those long lists of trusted third-party scripts

• Consider using script-src 'report-sample' as it significantly helps debugging CSP reports. See specification

• Origin script-src 'unsafe-inline' allows bypassing of CSP and execution of inlined untrusted scripts. Use 'nonce-' or 'sha256-' instead

• Origin script-src 'unsafe-eval' allows bypassing of CSP and execution of inlined untrusted scripts. Use 'nonce-' or 'sha256-' instead

• The style-src data: origin allows bypassing CSP and execution of inlined untrusted scripts

• Origin style-src 'unsafe-inline' allows bypassing of CSP and execution of inlined untrusted scripts. Use 'nonce-' or 'sha256-' instead