Does Your Website Have a Secure Header?

[For non-developers]

What are they?

HTTP Security headers, at their simplest, increase your website or application’s security by:

• Restricting code coming from outside or even within your website that it doesn’t recognize
• Forcing your web browser to communicate only through a secure connection that can’t be bypassed or overridden
• Preventing certain unsecure elements from being loaded on the website
• Preventing attackers from being able to inject dangerous code into your website through your URL

With an HTTP Security Header, the Content Security Policy (CSP) will create a notification any time it picks up anything suspicious, and it won’t load that element.

How are they implemented?

Security headers can be implemented in any platform or content management system (CMS) your website is on. You can actually find tutorials on the internet for any of these, or ask your web service provider to implement this for you. These headers are only a few lines of code, but they make a big difference!

Is this important?

Wherever there are security flaws, developers adapt to fight them. If your website’s security is on your mind, then a security header is definitely important. Ecommerce websites that gather personal information and collect payment are some of the most important cases that benefit from this added security. We are recognized as a top E-Commerce Design & Development Company on DesignRush. —————————————————————

[For developers]

What are they?

According to the Open Web Application Security Project (OWASP),  HTTP Security Headers are HTTP response headers that your web application can use to increase the security of your application. They are able to:

• Restrict the resource and scripts that a website uses, whether it be internal or external to the website. Basically whitelisting your scripts, stylings, and any other resources your website uses.
• Force browsers to only communicate over a secure connection (HTTPS), and prevents the client from overriding an SSL certificate warnings (caused by an invalid or fake certificates).
• Prevent iframe elements from being loaded on to the website.
• Help prevent against reflected cross-site scripting attacks, which is when an attacker injects HTML and/or JavaScript elements via the website URL.

The Content Security Policy (CSP) can be the longest and most complex of the HTTP security headers available to implement. This is the policy in which you specify the trusted sources of resources and scripts. Any time a requested resource or script violates part of the CSP, the web browser will fire a POST request specifying the resource and the associated violation, while not loading the resource itself. Typically this appears in the web browser’s console.

How are they implemented?

Most security vulnerabilities can be mitigated or fixed by implementing the necessary security header. These headers can be implemented through Apache configuration files, Nginx configuration files, Microsoft IIS or whatever platform or Content Management System (CMS) you are using. There are tutorials on almost any web solution you may be using. These security headers are typically only a few lines of code. Here’s an example for implementing a security header in WordPress (although it’s recommended to implement through your web server software). This security header is added to the wp-config.php file and doesn’t allow iframe elements: header(‘X-Frame-Options: DENY);

Is this important?

If security is a concern on your website, security headers are absolutely important. All modern web browsers support security headers, but can vary in levels of support of headers such as CSP. Security headers are especially important on any website that deal with ecommerce, sensitive user information, private company information, etc. If you have any data to protect you should be using security headers. Vulnerabilities in security headers have been found and published in the past, but they are continually improving and more widely supported, it’s better to think of them as another layer of security then an absolute solution.   Further Reading: https://geekflare.com/http-header-implementation/#WordPress https://geekflare.com/http-header-implementation/ https://www.dionach.com/blog/an-overview-of-http-security-headers https://www.owasp.org/index.php/OWASP_Secure_Headers_Project https://www.keycdn.com/blog/http-security-headers