Some security options need a little more consideration than others. Some can be switched on without further thinking about it, others need a lot of thinking and probably testing right after switching them on.

No-brainers

Forbid Content-Type Sniffing

This option forbids that the browser tries to handle unexpected content-types for mostly CSS and JavaScript. Some browsers, upon unexpected information about the file just being loaded, will try to understand what type of content is in that file. And then they might try to find a better use for the file as the one that was specified in the document. This is almost always useless and can be abused by attackers.

My recommendation: just switch it on

Remove outgoing information about your server

This option will filter any HTTP Headers your server sends that will give attackers an idea of what software and what version of the respective software is in use on your server. Whether it's the Drupal version, the apache version, the PHP version or any other hint about what kind of software your server uses, a potential attacker can just look up vulnerabilities for those and abuse them.

This might make it harder to debug certain issues with your server. Keep in mind that you can always enable or disable this feature with a simple click. So in case you miss some headers when debugging, switch it off and later back on again.

My recommendation: just switch it on

Cross-site scripting protection

In case an attacker can send a manipulated link to one of your customers, or inject malicious content into your website, this option protects the user by letting the browser scan the document for attacks.

This option has two settings: you can either remove unsafe scripts or prevent rendering of the site at once.

There are hundreds of attacks known and chances are that, when an attacker compromised your site he uses more than just one. The remove unsafe scripts options will let the browser defuse any attack he detects, but attacks he did not detect will still get carried out. That's where the prevent rendering option comes into play. If the browser detects a single attack on the page, he will not render the page at all.

My recommendation: prevent rendering

Thinking required

There are a few features based on whether your site consistently uses HTTPS or not. 

If you are sure that HTTPS is used everywhere in your website and your server probably already redirects traffic that requests http to https, there are a few options that you should activate in wao.io.

Redirect HTTP URLs to HTTPS

This will not only ensure that none of your users will see insecure content, but also that a request for http does not even get through to your server. wao.io takes over and redirects your client to the https version of the requested resource. This does not only increase security, but also the performance of the redirect.

My recommendation: if you use https consistently, switch it on

Cookie Security

This option, too, has two different settings. You can either protect cookies from being exposed over insecure connections or completely forbid them for insecure connections.

Both options will add the secure flag to any cookie you set via the Set-Cookie HTTP header. This means, that the client will not send these cookies when using an insecure http connection. The forbid option will even strip all Set-Cookie HTTP headers when the connection is insecure.

My recommendation: if you use https consistently, forbid cookies for insecure connections

Restrict embedding in other web pages

Now that we ruled out the features that base on HTTPS, let's get to the features that handle everything around iframes.

To come to an elaborate decision for these options, you need to know whether you want or need your site to be displayed in iframes and - if you do - what are the domains that use those iframes.

With the following option you can control where iframes that include your web site are allowed. One possible answer to the iframe question is "I do not know", in which case you should no restrict embedding. If you do know however that no iframes are necessary for your site and business to work correctly, you should just forbid embedding right away.

In case you know the domains that make use of iframes to display your site, there are two possible outcomes: the domain that uses the iframe is either always the domain that is included in the iframe, or it is not. In the first case you can allow embedding only from same origin, in the latter your can specify a list of the domains that are allowed make use of iframes.

My recommendation: either forbid or specify a list of origins

Restrict cookies to same site

This feature, too, is all about embedding your web page in other peoples iframes. If your site should not be embedded by others, you should forbid cross-site usage. If it is embedded by others, you should probably allow it only for navigational requests. If you really need to allow it for non-navigational requests, I assume your service is technically challenging and you would not need this guide anyways.

My recommendation: either forbid cross-site usage or allow it for navigational requests

Restrict sending of referrer information (Referrer-Policy)

The browser will happily let everybody know what URL your visitor just looked at, when making a request.

This means no matter if it is loading a JavaScript from tracking or ad services, an image from an image hoster or a web site after your visitor leaves yours, the browser will send the full URL that the request originates from. This is a potential leak of information, as these third parties now might know how many items the user has in his basket or what product he just looked at.

Now some services rely on the referrer as means of authorization. Maybe the image hoster only wants to display the images at your exact site. Even then he should maybe not be able to detect how many items are in your clients basket.

While the referrer policy has a bunch of options that restrict in detail over what kind of connection what depth of information is shared, I have a favourite. And that is because it will respect privacy by almost never breaking any of the use cases for referrer mechanics.

My recommendation: Send nothing when less secure, referrer origin when cross-origin, referrer URL otherwise


Any of the features that I did not discuss in this article need a deeper understanding of what they do, when not to use them and especially what they could break if used wrong. If you need more information on any of those features or on the topics discussed here, just contact our support team. We will be happy to help!

Did this answer your question?