How secure is your Joomla site? Joomla 4’s new features to manage security headers from within your site make protecting your site even easier.

There are a range of HTTP Headers you can implement when securing your website. Amongst them, a specific one called Content Security Policy (CSP) can enable an optional extra layer of security protection by applying modern protections built into your browsers that helps them to protect your site and users against some common threats for your website.

These include Cross Site Scripting (XSS) and data injection attacks which can cause anything from a site defacement all the way up to data theft and distribution of spam and malware. Clearly, that’s something every website owner wants to avoid.

Generally HTTP Headers can be implemented in three ways:

• Server level configuration using httpd.conf
• Via .htaccess file across a hosting account
• Meta elements in a particular page.

All of these are effective, but typically require some technical knowledge as to how to implement them on your hosting, as well as in Joomla. As such many sites do not have them in place protecting their sites.

As part of Joomla 4, Yves Hoppe, David Jardin & Tobias Zulauf have developed new tools for the Joomla Core to help every site integrator with the setup of the headers. That allows a wider range of users to understand and set up that headers and even apply some of the basic protections by default. Following JandBeyond at the end of May, I chatted with Tobias about the new functionality.

Patrick: Before my May JCM article on “Joomla 4: What to expect?”, I installed Joomla 4 Beta Dev to start getting a feel for the new features, particularly Workflow.

In the list I started looking at when deciding what to focus on for that article, Content Security Policy was something appearing amongst the more technical features, so I’d put that aside as something to look at later.

That was until a few people started pointing out it’s both a powerful and important new security feature in Joomla. What’s the background on what led you to develop the new HTTP Security Headers and the Content Security Policy component?

Tobias: David and I attended a security conference in Germany where I was introduced to HTTP Headers and Content-Security-Policy. After that conference I started building a plugin for Joomla 3.x that allowed me to set that headers from within the Joomla Backend.

With that plugin being released and me getting more into the CSP, we discussed how we could easily implement CSP in the Joomla core as one of the main types of issues the Joomla Security Strike Team had regularly reported were Cross Site Scripting (XSS) issues back then.

Later David came up with the great idea to use the a CSP report-uri endpoint allowing the site to be set into an “Detect” mode that let your site collect the violations of your site and provide an UI Interface to create the final CSP rule. At a JSST Sprint in Cologne Yves built the initial version of com_csp.

Patrick: In your JandBeyond presentation you gave some interesting examples of the types of security issues it’s designed to protect against.

XSS are a common security issue that the CSP security headers avoid and that’s one that is highlighted more in several of the resources linked below.

The example that caught my attention in your video though was the “Last Cookie Wins” scenario. As someone looking at adding affiliate links on my blog, I’ll be looking at using CSP to prevent that happening on my site. Can you explain that concept a bit more and how CSP helps?

Tobias: That example is based on an article from a german IT news site. Basically when you set an affiliate referral link from your site that site saves your referral code via a cookie in the browsers. When the user now goes via another site or another link that cookie is replaced with the latest referral code. That is fine and how it is designed to work.

But there are browser plugins running in the visitors browsers that are injecting javascript that replaces that cookie with the cookie of the developer of that plugin. But when your site does not allow that browser plugins to inject unsave javascript code this can not happen on your site anymore.

In the end with that we can make sure only we control the experience on our site and only allow trusted external sources to be loaded.

Patrick: So let’s take a look into the tools in Joomla 4. Between the Joomla Docs, Tobias’ JandBeyond session, and installing a J4 Beta Dev version to test things myself, I think I’ve worked out a rough workflow readers can consider following to implement CSP.

• Check that the“System - HTTP Headers” plugin is turned on. It is enabled by default in Joomla 4.
• Next go to System > Content Security Policy > Options, to configure CSP.
• Enable the switch “Content Security Policy (CSP)”, and initially set the mode to “Detect”. 
• Now the component will detect and log all the headers that are reported as violations on the site.
• After letting the site run in detect mode for a while, go to System > Content Security Policy again and review the violations collected
• All reports about known things and domains that you include can be set to published.
• Once that whitelist has been set up that way, switch to Automatic mode to apply the Content-Security-Policy.
• Once you saved the options the Content-Security-Policy is then in effect.

The feature in Joomla 4 is initially turned on by default, and optional for sites to implement. Why do you think all users should seriously consider turning the feature on as part of their Joomla 4 installation?

Tobias: We have two different things here. General HTTP Headers and Content-Security-Policy.

The first set of headers can be easily configured in the “System - HTTP Headers” plugin you mention. The most of the available headers already come with sensible default values. The only thing you usually have to enable yourself is the “Strict-Transport-Security (HSTS)” header as this only applies to sites running on https.

But for the latter it is not as easy as switching on a button and don’t care about that thing anymore. When you want to set up Content-Security-Policy I would strongly recommend getting some knowledge about what that header does before you enable it and the second suggestion would be to start on a simple site first. For the start I recommend this article by Scott Helme: “Content Security Policy - An Introduction” as well as his “CSP Cheat Sheet” under this article Here I have collected some more sites to checkout about CSP. When you are familiar with that topic now with that topic feel free to check out the tools we built into the core to protect your sites.

But to get back to your question of why I think that everyone should take a look at the http security headers. That is easy: the web and the browsers have evolved over the years and they build advanced tools to protect and improve your sites. Naturally those new tools can break existing sites or require some input so the browsers tend to not enable such features by default.

Using HTTP Headers we as site administrators can choose to enable that modern protections and tell the browsers to protect our sites. Starting from simple things like not allowing our sites to be loaded as iframe or telling the browsers not to leak the referrer to insecure sites up to the more advanced features like content security policy.

With 4.0 the core made a good step in the right direction to ship with a solid basic configuration of the HTTP Security Headers and also provide the tools to use the advanced features to protect your sites.

Patrick: I encountered the impact of CSP on Joomla.org sites when I submitted my articles for the May edition. With CSP turned on, but missing some whitelisted entries, you can quickly find out where your site’s got issues with various content types.

The examples I experienced on the Joomla.org sites were things users might commonly encounter when they turn the HTTP Headers on - linking to Google Fonts or Adobe TypeKit, embedding Youtube videos, and even setting up Two Factor Authentication where a Google Authenticator QR Code needs to appear.

Once the Content Security Policy Reports discover items on your site using Detect mode, you then just need to publish the item for it to be allowed going forward.

What other things would users typically see in their reported item lists that they need to review?

Tobias: You should expect to see all sites and services that you include like the google services and you should also get a feeling what they load for google maps or youtube to be up and running. But depending on how many different users your site has over the detect phase you will also notice some stuff you can not explain or make use of. A good resource in such cases is a Google Search and this GitHub repo called “CSP, WTF?” There you can find a long list of explained and even not explained reports that happened in the live.

Patrick: Is there a rule of thumb users can rely on when auditing blocked elements?

Tobias: The rule of thumb would be the following. Before whitelisting something you can not explain, try to reproduce the error yourself and see whether it is fixed after whitelisting the mentioned report. After the initial setup is done it might make sense to implement some long time reporting. I personally use a simple PHP script that I also published on GitHub called “csp-reporter-php”. For the joomla.org Network of sites we now days use a service called report-uri.com.

Patrick: Are there things now Extension Developers should consider for Joomla 4 to help users streamline changes to their Content Security Policy when their extension is installed?

Tobias: The main protection that CSP provides is to disallow any inline JavaScript and CSS that eliminates many of XSS attacks against your users and visitors. But when enabled this also applies to your legitimate use in your extensions.

For 4.0 it would be recommended to get the frontend of your extension running with strict Content Security Policy enabled. For 4.1 compatibility it would be recommended that this also applies to your backend.

We know that it is still a requirement to have inline JavaScript and CSS, for that reason we have implemented nonce and hash support into our Document APIs when you use them the core will make sure they are whitelisted but we will still block any malicious to protect our sites.

For more details please check the Extension Developer Section of the HTTP Header Management Documentation. And please contact us on any questions so we get as many extensions as possible ready for Content-Security-Policy.

Patrick: Tobias, you’ve also published the System - HTTP Headers plugin for Joomla 3 sites. The Joomla 3 plugin implements the headers, but without the management and reporting functionality the CSP Component provides, correct?

Tobias: Yes. As mentioned above this was the starting point where we build the core tools on top. That has been kept synced with the core changes to be up-to-date with the 4.x version.

There are two main reasons that there is no com_csp in Joomla 3.x. The first is that in order to make it right we need to add some small features to the Document API. And the second thing is that also the core uses many inline JavaScript and CSS right now. With 4.x the core made great progress in that area so we now finally can start to think about strict Content-Security-Policy for the core too.

As my plugin exists on 3.x you have no excuse to not set the headers it supports to enable the modern browser protections and you can also start looking into CSP right now.

Patrick: Fantastic. Thanks for your time. I’ve got to head off now and install the System - HTTP Headers plugin on 70 Joomla 3 sites now.

Resources and further reading

There’s lots more to understanding Content Security Policy, so here’s a list of resources to help you through learning how the new features work, as well as other resources to help you configure policies on your sites.

Joomla Documentation

• https://docs.joomla.org/J4.x:Http_Header_Management
• https://docs.joomla.org/Help4.x:Components_CSP_Reports
• https://docs.joomla.org/Help4.x:Components_CSP_Reports_Options

System HTTP-Headers Plugin for Joomla 3

• https://extensions.joomla.org/extension/httpheader/
• https://github.com/zero-24/plg_system_httpheader

CSP Evaluator

• https://csp-evaluator.withgoogle.com/

Further reading on CSP

• https://scotthelme.co.uk/content-security-policy-an-introduction/
• https://developers.google.com/web/fundamentals/security/csp
• https://csp.withgoogle.com/docs/index.html
• https://research.google/pubs/pub45542/