I have added the following line in my .htaccess file to set the HSTS header
Header always set Strict-Transport-Security "max-age=63072000;includeSubDomains;"
To test the HSTS header, I have done the below steps:
Access the application in the chrome browser
Open the developer tool and check the HSTS header in the Response headers
The first time when I access the application and verified it in the developer tool, I could see the HSTS header in all the PHP files, image files, CSS files, and JS files.
Again when I load the application, I could see images, CSS, and JS files are loaded from the memory/disk cache and these files are missing the HSTS header in response headers.
However, PHP files still shows the HSTS header in the reponse headers.
Missing HSTS header in the resource files(image/CSS/JS files) is accepted? OR It is considered as security hole? If so how can I fix this?
Thank you in advance
The idea behind an HSTS header is that content is always downloaded over an encrypted connection.
Once the files are downloaded and put in your memory/disk cache they are no longer encrypted.
When your browser gets the files from memory/disk cache they also don't need to be downloaded over any connection. The memory/disk cache is a trusted resource. That's why the HSTS header is not needed.
Related
Using the HTTP header, I set the CSP of that one page like so:
Content-Security-Policy: frame-ancestors 'self'; img-src https://www.example.com
Then firefox tries to load the favicon.ico and gets this error:
Content Security Policy: The page’s settings blocked the loading of a resource at https://www.example.com/favicon.ico (“default-src”).
Is there a way in Firefox to know how it came to this conclusion? (i.e. a way to trace the CSP processing for a page).
Note 1: The favicon.ico request never makes it to the server.
Note 2: The page I am testing is a .php script which at first was in the root folder (/my-script.php). The issue with the favicon.ico file started when I moved that script in a sub-folder (/sub-folder/my-script.php). The script returns a JSON file (not HTML). I do not seem to have such an issue with HTML pages, some of which also appear under sub-folders.
I am currently trying to configure the response headers for a Wordpress website.
Web Server: Apache 2
Operating System: Ubuntu 16.04
Right now, I have figured out that I am able to modify the HTTP response headers for the website through 3 different ways:
Configuring apache2.conf in /etc/apache2
Configuring the .htaccess file within the Wordpress directory
(I do not have mod_headers.c therefore I cannot use this method)
Directly specifying the headers to use in the header.php file of the current Wordpress theme
Previously I set the website's response headers through directly specifying the HTTP headers in the header.php file (which contains all the scripts and whatnot to be used for each page). However right now, I'm trying to move all header configuration into apache2.conf such that all sites hosted on the server have the same response headers.
However, after restarting the Apache server, I am getting duplicate response headers even though I had removed all header declarations from the header.php file, and I am not sure why...
Because of security issues, the authorities of the main domain that my department's site is on is requiring us to only specify one instance of each HTTP header.
Does anyone know how to resolve this issue, also, what are the best practices for setting HTTP response headers for sites hosted on an Apache 2 server?
I have configured my website on http2 but even after reading so many article i am unable to figure out few of its implementation.
I have removed common.css from header file of my website. and added the these lines to .htaccess file.
<IfModule http2_module>
#Check if there's a cookie saying the css has already been loaded:
SetEnvIf Cookie "cssloaded=1" cssloaded
#If no cookie, and it's an html file, then push the css file
#and set a session level cookie so next time it won't be pushed:
<filesMatch "\.([pP][hH][pP]?)">
Header add Link "</assets/css/common.css>;rel=preload;as=style" env=!cssloaded
Header add Set-Cookie "cssloaded=1; Path=/; Secure; HttpOnly" env=!cssloaded
</filesMatch>
</IfModule>
but My website is not loading common.css at all. it's breaking. My website is behind Apache server and website is fully build on codeIgniter.
I did add these to my common_head.php file too
<?php
header: header('Link: </assets/css/jquery-ui.css>; rel=preload; as=style,</assets/css/jquery.mCustomScrollbar.min.css>; rel=preload; as=style,</assets/css/slick.min.css>; rel=preload; as=style,</assets/css/slick-theme.min.css>; rel=preload; as=style,</assets/css/bootstrap.min.css>; rel=preload; as=style,</assets/css/common.css>; rel=preload; as=style,,</assets/css/jplayer.blue.monday.min.css>; rel=preload; as=style');
?>
Now i can see all the css file in inspect element and also can see initialtor Push/others but it is not applying on the page. Page is broken.
Apache server: 2.4.6
Please let me know where I am doing wrong?
That code looks familiar! Glad to know my blog post is proving useful :-)
I have removed common.css from header file of my website. and added the these lines to .htaccess file.
That’s where you went wrong. It needs to be referenced as normal in the HEAD and also pushed.
When the browser sees the common.css reference it will go to fetch it and see it’s already been pushed and just use the pushed resource.
Without reference the server will push it but the browser will just ignore it.
Note HTTP/2 Push is complicated and there’s lots of things like this where you can go wrong. See this post for more info: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/. Many are saying that it’s not worth the gains to use it, and the gains are questionable anyway as you can easily over push and cause the page to load slower rather than faster.
I'm running a new site on Google App Engine with a custom domain and I want to require all traffic to come through via https.
I created a test script at http://rublonde.com/tmp:
<?
header("Strict-Transport-Security: max-age=180; includeSubdomains");
print $_SERVER['HTTP_X_FORWARDED_PROTO'];
(The content of the site doesn't really match the domain name, I'm just temporarily using this domain as a custom domain so I can get the HTTPS header thing working.)
In Google App Engine, the HTTP_X_FORWARDED_PROTO will be either http or https. On the first load of this page, I assumed it would get the the HSTS header and then on subsequent loads of the page, Chrome should automatically be requesting the page via https.
Am I misunderstanding how HSTS works? Am I doing something wrong?
Ah, I realized that HSTS headers are ignored when sent over an http connection (I think because they need to be associated with a valid certificate that comes with the https connection).
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#HSTS_mechanism_overview
A server implements an HSTS policy by supplying a header over an HTTPS
connection (HSTS headers over HTTP are ignored).
I'm using Nginx as web server and Firefox to view response headers. For testing, I had two files on the server with the same content: test.html and test.php. In the Nginx configuration file, the expires directive is set to 30d in the server context.
When accessing test.html in a web browser multiple times, the browser first obtains a 304 Not Modified response and serves a copy cached in the browser. However, when accessing test.php, the browser always makes a full request to the server (200 OK) without using the browser cache.
The questions are:
Is the behaviour (i.e. different treatment of HTML and PHP generated files) normal?
What could be done to make web browsers cache HTML and PHP generated files in the same way?
nginx sets the response header for the static file, included in the headers are:
Cache-Control
Expires
Last-Modified
Cache-Control tells the client (at least) how to cache the content.
Expires and Last-Modified allow the client to determine when to fetch new content.
What you must do is ensure that PHP sends the same headers, or sensible headers if not exactly the same; Now that you know which headers are important, inspecting the requests in your browser will tell you how to achieve this.