X-XSS- Protection

[Adlago]

This is a security directive that is included in a htaccess file for  apache server or in a nginx server configuration.
We recommend a value of: 1; mode= block
In the IPS suite you use a value of 0 in the Output php file in the System/Output and this creates a duplication of the X-XSS-Protection directive in a response headers.
Please remove this from the Output php file for the next release.

/**
	 * @brief	Additional HTTP Headers
	 */
	public $httpHeaders = array(
		'X-XSS-Protection' => '0',	// This is so when we post contents with scripts (which is possible in the editor, like when embedding a Twitter tweet) the broswer doesn't block it
	);
	

 

[SeNioR-]

Agree

[Mark]

As the comment explaining why it's there says, it is needed for some features (the comment mentions embeds, but trying to edit templates or pages could also have issues with this set).

[Adlago]

2 hours ago, Mark said:

As the comment explaining why it's there says, it is needed for some features (the comment mentions embeds, but trying to edit templates or pages could also have issues with this set).

X-XSS-Protection when there is a value of 0 disables XSS filtering. This is not dangerous if a directive Content-Security-Policyis activated.

But if you see security headers test your site - it does not have such an active directive. And probably many clients too.

https://securityheaders.com/?q=https%3A%2F%2Finvisioncommunity.com%2Fforums%2F&followRedirects=on

 

[bfarber]

You're missing the point.

If you set the value to 1 (i.e. enable XSS filtering) you will break functionality in the software. That is why we explicitly disable XSS filtering in the request - it is required for the software to actually work.

When you write in the editor some content, and it's posted to the site and then displayed in the output, this can easily trigger browser-based XSS filtering. When you combine this with things like embeds, or editing templates in the AdminCP as Mark pointed out, any heuristic scanner will pick up on this as a security issue when in fact it is explicitly intended behavior.

In short - no, we can't do that.