Security Headers

All of the following measures protect visitors of your website from attacks by altered resources embedded on the site or man-in-the-middle attacks.
The headers can be set in the web server configuration, htaccess for apache for example, and need to be adjusted for the specific needs of your website.
These adjustments luckily limit to special external resources and features.

Content Security Policy Header

The CSP header can instruct the client browser to accept scripts, images and other embedded resources only from specified, trusted sources.
This means that all external sources present in the CSP header will be allowed to be downloaded and executed on your website, but all scripts and images from other sources, that are probably dangerous and therefore not trusted, will be ignored.
This makes attacks on the users - for example via XSS, manipulated images or hidden iFrames - considerably more difficult.

For example:

This line will block everything that is embedded via script, link, img, iframe or object embed that does not come from the very same domain - including subdomain - the user is already on.

Since lots of websites use external resources from CDNs over stock images, this is not really a viable way to secure the website. Luckily we can fine grain the header to allow certain external services for certain resource types like so:

Now this header makes more sense, because it allows for certain external services to provide resources to the site.

This script-src directive for example allows for scripts from our own domain ('self') and from every googleapis.com subdomain via HTTPS to be loaded.

https://developers.google.com/web/fundamentals/security/csp/

The Feature Policy Header is preventing external scripts from accessing devices and resources of the visitors browser. In most cases there is no need to give an external script access to the users camera or microphone for example, hence this policy can be configured in a way to prevent access to these features. If in case a hacker succeeds in injecting bad code onto one of the external resources, it can not be exploited to hijack a visitors sensors or input devices to gather personal information and eavesdropping on him.

For disabling all hardware input devices such as the camera or speakers do:

This way there is no possibility for scripts to use any of the mentioned devices. If one of our own scripts needs to access one of the devices or features, we can allow this by setting the needed policy to 'self'. If we need to allow an external script to use one of the devices or features, we can explicitly allow it by entering the domain name of that script into the policy like geolocation maps.google.com.

https://developers.google.com/web/updates/2018/06/feature-policy

The X-Frame Options header is configured to prevent the website from being embedded as an iFrame on other pages that are not authorized to do so. This is aiming at phishing attacks in which the original website will be embedded into a manipulated phishing site to make the visitor think that everything is fine, but entered data like usernames and passwords will actually be sent to the attackers own server.

For allowing the website to embed itself into an iframe (for lightboxes for example):

You can allow a certain domain to display the website in an iframe by adding:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

The XSS-Protection Header is a way to activate the browser's own XSS filtering. Browsers such as Google Chrome or Internet Explorer have internal mechanisms that can detect XSS attacks and then prevent a web page from loading.

In the future, browsers may also provide a report about the incident to a given URL.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The referrer policy header determines whether and under which circumstances the browser forwards the currently visited website to subsequently visited websites. It can be configured to send only the domain to visited non SSL protected sub pages of the same domain and hide the referrer in case the user is navigating away from the website entirely. Restricting the referrer protects the visitor from passing on data about visited sites to potentially untrustworthy websites.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

The X-Content-Type-Options header has only one valid value: "no-sniff". The header instructs the browser to not guess the type of downloaded files in script or style tags. This can prevent attacks on the client, that use a fake MIME-type to trick the browser into loading a file as executable, even though it should not be. If the browser encounteres a file with a different MIME-type, it is going to ignore the file.

developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

The server can calculate an integrity hash for its resources. It takes the contents of a script and calculates a hash that will be submitted alongside the embeded code and gives a visitors browser the possibility to check, if the contents of this script matches the provided hash and thus has not been changed on the way to them. This limits the possibility for an attacker to hijack a resource in a man-in-the-middle attack, because if the hash mismatches the script content, the visitors' browser will reject the script and not execute it.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

We at sgalinski Internet Services have taken steps to make our internal tools as safe as possible. This is why we implemented a basic Security Header Policy into our own website-base, providing an A grade out of the box.