How Wattspeed checks your web security

Share
Andrei Zuica

and why you should consider improving your score

Introduction to web security

Just like everybody else, I am sure you are reading the news, so you often hear, lately, more than ever about governmental websites being hacked by some organizations. You would say that you do not care, since you are not the most important business in the world, so why should someone target you? I would say that I have seen many not so important businesses being attacked with various types of malware, taking control of the webpage, leaking passwords or credit card information and leading to the owner paying lots of money to regain control.

Yes, here at Wattspeed we are not security experts, but we are trying to provide our customers a whole package for monitoring every aspect of their website. That is why, we have added the Security audit, a section where you can check the minimum must have security checks on your website.

Why web security is important

The importance of security should be straightforward, it is meant to keep you safe from cyberattacks. So what can a vulnerable website lead to from a SEO point of view?

The Search Engine Journal makes reference to a study on web security performed by GoDaddy, according to which 73.9% of hacking events were done for SEO purposes. Such attacks are spam based, and they aim to modify the content of websites by adding links to malicious sites. It was noted that 1 out of 10 infected sites were found on Google’s blocklist. Even if your site is not successfully hacked, the constant attacks from site hackers can prevent Google Bot from adequately accessing your site. This causes your web server to slow down (throttle) your web traffic and even to stop showing web pages to Google. So that is another reason to have a good score.

Website security is basically preventing those types of attacks by using various techniques in order to keep you protected as much as possible. In this article, we are going to tell you what we are analyzing and what each section of our Security audit is about.

Where security headers jump in

Security headers can prevent or restrict what the browser is allowed to do. Limiting browser functionality is not meant to restrict your application, but rather make sure the content is loaded only from intended sources and that overall the application performs the way it was supposed to. Think of it as a plan B if something unexpected happens in certain parts of the app, perhaps due to a mistake or even a zero-day vulnerability, being prepared for exceptional situations is definitely not bad practice and that is what security is mainly about.

There are 6 security headers that we currently check. As best practice, some of them are considered as a must-have, thus the higher impact they have on the score.

  • Strict-Transport-Security: HSTS header forces browsers to access the website through HTTPS.
  • Content-Security-Policy: CSP header defines allowed sources by content type (e.g. text, images), helping against certain types of attacks, like Cross-Site Scripting (XSS) and data injection attacks.
  • X-Frame-Options: XFO header indicates whether the website allows the browser to render its pages in a frame. Blocking framing avoids clickjacking attacks. The frame-ancestors directive defined in Content-Security-Policy obsoletes this header for supporting browsers.
  • X-Content-Type-Options: Server uses this marker to specify that the MIME types used in the Content-Type headers should be respected and not be changed to avoid MIME type sniffing.
  • Referrer-Policy: Referrer-Policy controls which referrer information should be included with the requests.
  • Permissions-Policy: Permissions Policy has the ability to allow or block browser features and APIs (e.g. access the camera, Geolocation).

SSL beyond browser warnings

Nowadays, as an online business, not using HTTPS is not an option anymore. Whether you are hosting a personal blog or running a banking app, the potential to become the target of cyberattacks is always there, and users know it. Often, the SSL padlock you see when you are accessing a website is enough to make users feel safe, and that is the reason why browsers display it. However, securing your website is not always as simple as obtaining a certificate. It is a complex subject if you want to do it right, and it involves getting your hands “dirty” configuring protocols, algorithms, ensuring compatibility and performance. Chances are a good configuration is provided out of the box when you buy hosting, but monitoring SSL adds traceability when changes affecting device compatibility occur. For example, the automatic renewal of certificates may in some cases introduce changes further up in the certification chain. For many is business as usual, however older devices may not recognize the new authorities due to lack of support and will begin rendering legitimate websites as unsafe (red padlock). To check that you are using the right certificates, you can access the SSL section inside the Security tab and view your website’s certificate chain. You can also configure an SSL expiration alert via email or Slack by clicking the notification bell next to the section name and get notified up to 2 weeks prior to the end of the validity period.

JS Vulnerabilities

Some JavaScript libraries can contain vulnerabilities and depending on the version you’re using, the vulnerabilities may have been patched or others may have been introduced along the way. Certainly, there are many websites out there which use popular frontend libraries known to be vulnerable to XSS, prototype pollution, command injection, etc. These vulnerabilities can alter the website and even disclose sensitive information to attackers. You will see a green checkmark next to the vulnerability section if no vulnerabilities have been detected, or a table listing the affected libraries. To display additional information, click on the library name or expand the listing for quick reference. Mitigations usually include updating to a newer version, if possible, or replacing the affected library entirely.

How we calculate your score

Our security scan evaluates security headers and the SSL certificate chain, scoring them according to the criteria listed below. The scoring methodology was adopted from Scott Helm’s Headers Test and Ivan Ristić’s scoring formula for SSL Test.

Security Headers

Security scans for a list of 6 response headers, and it checks whether a certain header was sent by the server. Points are rewarded based on the severity of the headers which are set, except for the Strict-Transport-Security header, which is excluded over an HTTP connection.

How do we score a website’s security headers?

The highest grade you can get is an A+ and the lowest is an F.

The grades are composed based on the following score:

  • A+ for a score equal to or higher than 100
  • A for a score equal to or higher than 75
  • B for a score equal to or higher than 60
  • C for a score equal to or higher than 50
  • D for a score equal to or higher than 20
  • E for a score equal to or higher than 10
  • F for a score equal to or higher than 0

Security headers are scored as follows:

  • Strict-Transport-Security adds 25 points
  • Content-Security-Policy adds 25 points
  • X-Frame-Options adds 20 points
  • X-Content-Type-Options adds 10 points
  • Referrer-Policy adds 10 points
  • Permissions-Policy adds 10 points

SSL

Testing SSL involves a series of checks, where the main targeted aspects are the certificate chain and server configuration (protocols & ciphers).

How do we score a website’s SSL scan?

The standard grading is from A+ to F, however there is an additional grade (T) when a certificate is not trusted. Certificates act as a proof of identity for a server and are used to confirm whether communication endpoints are really who they say they are. Failing to do so can render the whole security of the connection vulnerable (man-in-the-middle attack), regardless of having a

Grades are awarded as follows:

  • A+ for a score equal to or higher than 95
  • A for a score equal to or higher than 80
  • B for a score equal to or higher than 65
  • C for a score equal to or higher than 50
  • D for a score equal to or higher than 35
  • E for a score equal to or higher than 20
  • F for a score equal to or higher than 0

An incorrect certificate having any of the following issues will bring the total score to 0:

  • Certificate not yet valid
  • Certificate expired
  • Hostname mismatch
  • Use of a certificate that is not trusted (unknown CA or some other validation error)
  • Use of a self-signed certificate
  • Insecure key
  • Insecure certificate signature (MD2 or MD5)

Protocols are scored based on the versions of TLS that are supported by the server. Since there can be multiple protocols supported, the score is determined by the average between the best and the worst.

Protocol support rating:

  • TLS 1.3 has a rating of 100
  • TLS 1.2 has a rating of 100
  • TLS 1.1 has a rating of 40
  • TLS 1.0 has a rating of 40

Ciphers are scored based on the strength against an attacker’s effort to break the symmetric key of the cipher suites in all protocols. Since there can be multiple ciphers for each protocol, the score is determined by the average between the best and the worst.

Ciphers strength rating:

  • STRONG has a rating of 100
  • SECURE has a rating of 100
  • WEAK has a rating of 80
  • INSECURE has a rating of 0

Score changes:

  • The server is using an invalid certificate — score changed to T
  • The server uses insecure ciphers — score changed to F
  • The server does not support TLS 1.3 or TLS 1.2 — score capped at C
  • The server supports TLS 1.1 or TLS 1.0 — score capped at B