We Defend Our Sites with Secure Headers

Content Security Policy: What they are and how to implement them

Security in the web is never guaranteed at 100 but with a little care you can greatly limit the damage that various attackers can bring to your site or application server.

In this article, I’ll primarily cover the implementation of security headers that you can apply to sites running on Apache servers. Apache.

Content Security Policies are nothing more than a set of rules that define who and what can interact with our system.

Remember that a thorough security policy must be defined with the various needs of your site in mind.

The way in which to apply the instructions I will provide to you is controversial in the industry and should in any case be evaluated one by one in relation to your specific situation.

Below you will find the most common implementations, but I recommend from now on reading this in-depth, which contains, among other things, also the syntax to apply headers in webservers other than Apache.

First of all the main file on which we will work is .htaccess which regulates what can or cannot be viewed from the outside. For example, the default WordPresse .htaccess file is as follows:

[code lang=”html”] BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule :index .php – [L] RewriteCond {REQUEST_FILENAME} !-f
RewriteCond {REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

END WordPress[/code]

What are the headers I need?

Well, now we need to insert headers to increase security. There are several that I list below:

X-XSS-Protection “1; mode-block”
In Chrome and Internet Explorer, block those XSS attacks that send malicious code as part of the http request.

Strict-Transport-Security “max-age-31536000; includeSubdomains;”
If your site is reachable from both http and https, the http request may be intercepted, even in the event of an immediate redirect to https. This header tells the browser to only use https, avoiding this possibility.

X-Frame-Options “deny”
Prevents page inclusion in both frames and iframes.

X-Content-Type-Options nosniff
Prevents the browser from overwriting the mime-types of elements on the page at its discretion, thus avoiding possible XSS attacks.

Content-Security-Policy: “…”
Advanced version of X-XSS-Protection. This directive is very useful for mitigating XSS attacks, but it is really difficult to manage the effects of the parameters that will be inserted in place of the dots. For this reason, unfortunately, many choose not to use it.

Let’s insert the first headers

At this point we can start to insert the first heders into our .htaccess, strictly before the general rule of the WordPress.

let’s start with X-XSS-Protection.

add this at the top first of all.

Header set X-XSS-Protection “1; mode-block”

Note, depending on your engine you may need to activate the php header module: in case the initial wording will be as composed:

[code lang=”html”] < IfModule mod_headers.c >
Header set X-XSS-Protection “1; mode-block”
< /IfModule >

BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule :index .php – [L] RewriteCond {REQUEST_FILENAME} !-f
RewriteCond {REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

END WordPress[/code]

Now let’s implement the others, except for content policies.

[code lang=”html”] Strict-Transport-Security Strict-Transport-Security Header Set “max-age-31536000” env-HTTPS
Header set X-XSS-Protection “1; mode-block”
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff

BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule :index .php – [L] RewriteCond {REQUEST_FILENAME} !-f
RewriteCond {REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

END WordPress[/code]

How do I check if protection is enabled?

You can use several tools to do the necessary checks.

I have used this site https://securityheaders.io/ which gives you, in addition to the rating, also some tips on how to solve any problems. Also if you use Chrome there is a nice extension that you will find here http headers chrome extension.

If you have finished your checks, security should now be increased. But beware: some of these directives don’t get along with vanish-type cache systems, so if you don’t change your rating, try to temporarily disable the cache.

The Content-Security Policy

As I mentioned, this directive is a bit challenging to fix, because with it you go to calibrate, line by line, everything that passes through your site and from your site.

Let’s see a little example:

Header always set Content-Security-Policy “default-src ‘self’ .tawk.to .twimg.com .google-analytics.com https://syndication.twitter.com;

Here we indicate the first part of the policy where we tell the server that we only accept sources that come from the same domain default-src ‘self’, then we add sources that can have a dialogue with us, for example the analitycs of google .google-analytics.com, and we end the line with a ;

Well, if you entered this rules as I described you …. probably doesn’t work anymore !!!! :-)))

Don’t worry: it’s normal. Yes because there are countless external sources that we use when we assemble a site: let’s see what others are needed.

script-src ‘self’ .twimg.com .twitter.com .googletagmanager.com ‘unsafe-inline’ ‘unsafe-eval’ .google-analytics.com .jsdelivr.net https://sharebutton.net .sharebutton.net http://maps.googleapis.com https://maps.gstatic.com https://ajax.googleapis.com https://www.google.com https://www.gstatic.com https://cdn.syndication.twimg.com/;

So here we are: we are missing the various scripts that regulate and make our plug-ins work. As above, the main rule is self, then we add the authorized domains.

Ok.

We did everything right.

Now we just have to take a test!

No, I don’t! :-))) Some things are still missing, such as fonts and frames, css fonts, and objects. Just like I told you before, let’s add them.

style-src ‘self’ ‘unsafe-inline’ .jsdelivr.net http://fonts.googleapis.com https://ton.twimg.com/ http://platform.twitter.com;

img-src ‘self’ data: ;source

frame-src .example.com https://www.google.com/recaptcha/ https://syndication.twitter.com/ https://platform.twitter.com/;

object-src ‘self'”

Summarizing Content Secuity Policy

It is extremely important that all these last headers are written in a single row, so the rule in our example will be:

Header always set Content-Security-Policy “default-src ‘self’ .tawk.to .twimg.com .google-analytics.com https://syndication.twitter.com ; script-src ‘self’ .twimg.com .twitter.com .googletagmanager.com ‘unsafe-inline’ ‘unsafe-eval’ .google-analytics.com .jsdelivr.net https://sharebutton.net .sharebutton.net http://maps.googleapis.com https://maps.gstatic.com https://ajax.googleapis.com https://www.google.com https://www.google.com jsdelivr.net https://cdn.syndication.twimg.com/ https://www.gstatic.com http://cdn.iubenda.com http://fonts.googleapis.com https://ton.twimg.com/ http://platform.twitter.com;img-src ‘self’ data: frame-src .example.com https://www.google.com/recaptcha/ https://platform.twitter.com/ https://syndication.twitter.com/;object-src ‘self'”

In conclusion I tell you that applying this methodology is complicated and definitely not suitable for beginners. However, knowing how to increase the security of your site is by no means wasted time. If you want, other sources can be found here:

And in case you need help or just want to delve deeper, you know that you can contact me at any time.