The X-XSS Protection feature of the Microsoft Edge browser has been in place to prevent cross-site scripting attacks on the system since its introduction in 2008. Although some in the tech industry, such as the developers of Mozilla Firefox and several analysts, have criticized this feature with Mozilla refusing to incorporate it into its browser, turning away hopes for a more integrated cross browsing experience, Google Chrome and Microsoft’s own Internet Explorer have kept this feature running and no statement has emerged from Microsoft yet indicating otherwise. Since 2015, the Microsoft Edge X-XSS Protection Filter has been configured in such a way that it filters such code crossing attempts on web pages irrespective of whether or not the X-XSS script has been enabled, but it seems that the feature that was once on by default has been discovered by Gareth Heyes of PortSwigger to now be disabled in the Microsoft Edge browser, something he considers to be due to a bug as Microsoft has not come forward claiming responsibility for this change.
In the binary language of off and on scripts, if the browser hosts a header rendering “X-XSS-Protection: 0”, the cross-site scripting defense mechanism will be disabled. If the value is set to 1, it will be enabled. A third statement of “X-XSS-Protection: 1; mode=block” blocks off the web page entirely from coming forward. Heyes discovered that although the value is supposed to be set to 1 by default, it appears to now be set to 0 in Microsoft Edge browsers. This does not appear to be the case in Microsoft’s Internet Explorer browser, however. Attempting to reverse this setting, if a user sets the script to 1, it reverts back to 0 and the feature remains off. As Microsoft has not come forward about this feature and Internet Explorer continues to support it, it can be concluded that this is the result of a bug in the browser that we expect Microsoft to resolve in the next update.
Cross-site scripting attacks occur when a trusted web page carries forward a malicious side script to the user. Since the web page is trusted, the site’s contents are not filtered to ensure that such malicious files do not come forward. The principle way to prevent this is to ensure that HTTP TRACE is disabled on the browser for all web pages. If a hacker has stored a malicious file on a web page, when a user accesses it, the HTTP Trace command is run to steal the user’s cookies which the hacker can in turn use to access the user’s information and potentially hack his or her device. To prevent this within the browser, the X-XSS-Protection feature was introduced but analysts argue that such attacks are able to exploit the filter itself to get the information that they’re looking for. Despite that, however, many web browsers have maintained this script as a first line of defense to prevent the most basic kinds of XSS phishing and have incorporated higher security definitions to patch any vulnerabilities that the filter itself poses.