7 Security Response Headers Your WCMS Should Use

Nowadays there are many dangerous web attacks that can harm your site and data. There are many tools for static and dynamic security scans of websites that suggest improvements from site developers and administrators. The growing demand for protection can be seen in many regulations, standards and best practices. Security is a cornerstone of each software project and that is why each WCM system should secure its content by embracing the latest trends that are supported by protocols and browsers. There are many types of attacks that can be prevented – XSS, Clickjacking, MTM – stealing/modifying data in transit. The HTTP protocol defines headers that all modern browsers understand and use to protect a user’s and/or site’s data, and which help you to avoid those kinds of attacks.

Usually, site administrators and/or developers make sure that the best practices are applied. Said another way, they hold the key to a site’s security 😊. However, adopting some of them could change the work of other users, like marketers, authors, content editors and designers. E.g. they won’t be able to add a reference to an external resource without explicit permission from the administrator. This might impact a marketer’s work, but at the same time, it would also apply to anonymous and frontend users, who wouldn’t be able to inject dangerous scripts. This way the security headers will prevent the loading of malicious scripts. As a result, it won’t be possible to execute a script coming from a 3^rd party application into your WCM system and your data will be protected. Another sample that could be implemented could protect you from clickjacking and XSS attacks. Those scenarios are very common for WCM systems and when people are working on many content items.

This responsibility for this is on the developers and administrators, and they should be up to date with what needs to be applied on configuration level. They shouldn’t "leave the door open" and rely on other layers of protection because this is never ending battle.

If your WCM system is not using HTTP security headers it is never too late. Look at the list below and ask your administrators which of them are currently applied to your website and if some of them are not, ask why.

Security Headers in HTTP Response for Your WCM

Content-Security-Policy

HTTP header that controls resources the user agent is allowed to load. Specifies the server origins and script endpoints for page resources. Helps for XSS protection.

Warning: Misconfiguration may block some resources from loading.

This is one of the most powerful weapons for protection against XSS. But keep in mind that if turned on by default, it blocks almost all external resources from loading, and this may prevent pages from using external CSS, fonts, images, scripts etc. So, the site administrator should allow all trusted domains in the header configuration for each respective resource type.

There is a graceful report-only policy that can be configured by the administrator to allow fine-tuning the header without breaking any existing pages and looking in the developer console to find out which resources are coming from external places.

For more information on its usage, you can learn more here and here.

Public-Key-Pins

Tells a web client to associate a specific cryptographic public key with a certain web server to decrease the risk of MITM attacks with forged certificates. For more information on its usage, read more here.

This header requires configuration of the public key of the used certificate for transport layer encryption.

Referrer-Policy

Governs which referrer information, sent in the Referer header, should be included with requests made.

For more information for its usage, read here.

Strict-Transport-Security

Prevents sending data over an unencrypted channel (when a secured one is available). Strict - Transport - Security - HSTS tells browsers that content should only be communicated with using HTTPS, instead of using HTTP. It converts automatically all HTTP requests to HTTPS if the site has been opened previously with HTTPS with valid certificate.

For more about its usage, you can learn more here.

X-Content-Type-Options

Prevents Content Sniffing for styles and scripts.

For more information on this, read here.

X-Frame-Options

HTTP header that indicates whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>. Helps protecting against clickjacking attacks.

For more information on its usage check out this cheat sheet.

X-XSS-Protection

Prevents reflected cross site scripting attacks. Value (1; mode=block) prevents rendering the page if an attack is detected.

For more information on using this, read more here.  

Going One Step Further

Admins can do this manually through the server configuration, but of course a better solution would be to use a built-in solution that comes with your WCM system. We understand how important security is and we are the first WCM on the market providing a HTTP Response Headers Module integrated into our product. If you are interested in understanding more about how we do it in Sitefinity, please read more here.