X-FRAME-OPTIONS is shown twice and X-XSS-PROTECTION is shown wrong

Question

I am trying to fix my headers. I see two errors when checking the network requests as I visit my page:

1) X-FRAME-OPTIONS: SAMEORIGIN is shown twice:

Cache-Control:no-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Wed, 04 Oct 2017 12:58:30 GMT
Keep-Alive:timeout=3, max=1000
Server:Apache
Set-Cookie:laravel_session=eifQ%3D%3D; expires=Wed, 04-Oct-2017 14:58:30 GMT; Max-Age=7200; path=/; secure; httponly
Set-Cookie:XSRF-TOKEN=n0%3D; expires=Wed, 04-Oct-2017 14:58:30 GMT; Max-Age=7200; path=/
Transfer-Encoding:chunked
X-CDN:Incapsula
X-Frame-Options:SAMEORIGIN * <-------------- HERE
X-Frame-Options:SAMEORIGIN * <-------------- HERE
X-Iinfo:7-6626704-6651371 NNNN CT(0 0 0) RT(1507121414380 495318) q(0 1 1 -1) r(2 2) U16
X-XSS-Protection:%E2%80%9C1;mode=block%E2%80%9D <-------- Strange Encoding here...

2) I can see the following error on the console for X-XSS-PROTECTION:

Error parsing header X-XSS-Protection: â1;mode=blockâ: expected 0 or 1 at character position 0. The default protections will be applied.

I am using Laravel 5.0. The FrameGuard.php middleware is not active by default since Laravel 4.2, but you have the option to enable it if needed. When it's disabled, I see the above errors and I really can't understand why, so my first though was to overwrite those headers by actually using that middleware.

When I add the Illuminate\Http\Middleware\FrameGuard.php middleware, which contains the below code, nothing seems to change:

public function handle($request, Closure $next)
{
    $response = $next($request);

    $response->headers->set('X-XSS-Protection', '1; mode=block');
    $response->headers->set('Content-Type','text/html; charset=UTF-8');
    $response->headers->set('X-Frame-Options', 'SAMEORIGIN', true);

    return $response;
}

I also use Socialite which provides Facebook authentication. Is there a chance that it modifies any headers?

Cyclone

Did you set the middleware priority, so that your middleware is called the last? And you can probably debug if the corrupt headers are already there when you get the response in your middleware. Also if I use decodeURIComponent("%E2%80%9C1")="“1". This means the error probably has been introduce by you only somewhere by using a smart quote instead of a normal quote. Did you copy past some code from web or a word doc? Also you can detect which file has the smart quote using grep -r "“" . – Globetrotter

Any update on this? – Globetrotter

Answer 1

The webserver may be adding headers to responses in addition to those sent by PHP. We can check which headers the webserver adds by creating an empty HTML file in the public directory, such as public/dummy.html

Then, visit that page in the browser, http://example.com/dummy.html, and check which headers the response includes. Alternatively, we can use the curl command to show the response headers:

$ curl -I 'http://example.com/dummy.html'

HTTP/2 200
date: Mon, 16 Oct 2017 20:34:24 GMT
...
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN

If we see the x-xss-protection or x-frame-options headers in this output, it means that the webserver is sending these headers. There may be a corrupted value for x-xss-protection in the webserver configuration (it looks like someone pasted stylized double quotation marks (“…”) instead of straight quotes ("…") which the server interprets as part of the header's value).

For nginx, look for add_header ... directives in the configuration files. If using Apache httpd, check for Header set ... directives in the server config or the .htaccess file.

It also appears as if the site uses the Incapsula CDN, which may be injecting the headers as well, but I couldn't find any information in the Incapsula documentation that suggests this is the case.

Laravel Socialite does not add these headers to responses.

Baby

Just a small remark - why not just do curl -v instead of all the proposed flags? – Subtemperate

@Denis - Good point! Certainly less typing. I chose the curl command above for relevance because it outputs only response headers. For casual debugging, either should work. – Baby