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?
When X-Frame-Options Header is not set your application pages can be embedded within any other website with no restrictions, e.g. to create a malicious page with your original content augmented with dangerous fragments including phishing attempts, ads, clickjacking code, etc.
You can remove the HTTP header X-Frame-Options: SAMEORIGIN from WordPress by removing the send_frame_options_header function from the admin_init and login_init hooks.
'Multiple X-Frame-Options Header Entries' can result in only one 'X-Frame-Options' HTTP header being applied and the rest of them ignored or the configuration being incorrectly applied by the web browser.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With