!doctype html>
HTTP Strict Transport Security (HSTS) is for a web server to inform the client browser it will not connect using HTTP. HSTS will automatically convert all attempts to access using HTTP to HTTPS requests instead. This is one of the most misunderstood subjects for some reason. You would think every government institution, bank, credit card, insurance or healthcare company would want this enabled by default, right? Most do not!
The clients HTTP request will be responded with an HTTPS encrypted response. An HTTPS acknowledgement over HTTP! Yes! That is bad right? No! You want this! You are redirecting and altering the clients HTTP request, to an encrypted request over HTTPS. Technically, you made the secure request before the client made a non-secure connection. This is the only "secure" information over the redirected HTTP response packet (the ack response to the client syn request) you are sharing with the connecting clients. The HTTP request contains nothing in the packets other than a rerout response to HTTPS. This is our preference and lowers your risk profile for attack vectors. Truly, turning off HTTP is the best, but the standards have not been updated to address this issue.
Not adding HSTS is serious mistake! Any major application/browser works with it and we do not recommend making headers a global configuration, but rather add the headers in each Web site config file. Any enterprise internal environment should have this globally. You must always be in control of the clients, the clients should never have control under their terms.
The following are the recommended headers to ensure every client never connects to the application/site unless it is secure and remains connected securely. To have the HTTP request rejected and respond with an HTTPS connection instead, it requires preloading to be enabled. ***Add (preload) to the configuration once you submit your site here!
If there is a fatfinger or something not quite setup correctly, your site will be unavailable. If this happens, turn off HSTS and troubleshoot the issue. As always, test and restest in a sandbox prior to going live.
nano /etc/nginx/sites-available/EXAMPLE_com.conf
server {
listen 80;
listen [::]:80;
server_name EXAMPLE.com www.EXAMPLE.com;
return 301 https://EXAMPLE.com; <--Will always send everyone to our default site https://EXAMPLE.com
root /var/www/htmnl/example;
index index.html;
access_log /var/log/nginx/access.log combined;
error_log /var/log/nginx/error.log warn;
location / {
try_files $uri $uri/ =404;
}
}
systemctl restart nginx
nano /etc/nginx/sites-available/EXAMPLE_com_ssl.conf
server {
..............................
etag off;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block; report=<uri>";
proxy_cookie_path / "/; HTTPOnly:Secure";
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Feature-Policy "accelerometer 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; payment 'none'; usb 'none'";
add_header NEL "{\"Report-To\":\"default\",\"max_age\":31536000,\"include_subdomains\":true}";
add_header X-Frame-Options DENY;
add_header Cache-Control "public, max-age=31536000";
add_header MyHeader "Feel safe zombiesecured headers in use!!! It took %D microseconds for Zombiesecured to serve this request on %t";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
}
systemctl restart nginx