Audisto Security Checker

How to detect security related issues on your website

The security hints offer insights in a site’s security issues. Keeping an eye on this may prevent problems with privacy and the site’s appearance in browsers. Solving security related issues can help to build trust and lead to higher user interaction.

With this hints section you can identify security issues.

Example: Audisto Security Check with the security hint reports for the current crawl

Example: Audisto Security Check with the security hint reports for the current crawl

Here is the list of all specific hints related to website security, that can be identified with the help of the Audisto Crawler.

Table Of Content

Hints

<a> link contains user and password

Description

An anchor's href contains user and password, such as http://user:password@example.com. This may not be desired, and it is also not supported by Internet Explorer as of version 10.

Example
http://user:password@example.com
Importance

This hint points out a serious security issue. Login data should not usually be linked to directly on a website. The login data may be crawled with malicious intent and abused later on.

Operating Instruction

If instances of this hint are discovered, we suggest removing all links from your website that contain login data.

<a> link uses data: protocol

Description

An anchor's href uses the data: protocol. Detect all documents on the crawled website that contain links using the data: protocol.

Example
<a href="data:image/png;base64,(...base64-encoded png data...)"></a>
Importance

The data: protocol can be used to provide inline data elements, e.g. images, fonts, JavaScripts and other files, without requiring an additional request. It is not fully supported by Internet Explorer. This might cause issues with accessibility and user experience.

Operating Instruction

Evaluate all cases in which a link uses the data: protocol on the crawled website and decide wether it has to be replaced or not.

<a> link uses file: protocol

Description

An anchor's href uses the file: protocol, which is used to open files on the user's computer.

Example
<a href="file://C:/programs/filename.html">link</a>
Importance

The file: protocol is used to reference local files. If used on a public website, it might lead to unexpected issues with the user experience.

Operating Instruction

We suggest removing all references with the file: protocol on your website.

<form> POST to HTTPS from HTTP

Description

The form posts to an HTTPS URL, but resides on an HTTP URL. Use this report to identify all URLs within the website that contain forms, which are submitting data from an HTTP resource to an HTTPS resource, using the POST method.

Examples

What happens?

http://example.com/form.html posts to https://example.com/form_submit.php

Example form markup:

<form action="https://example.com/form_submit.php" method="POST">
...
</form>
Importance

If a form action is defined to use the HTTPS protocol, this indicates that the entered data should be transferred using a secured channel. However, while the data would be sent encrypted, it is still a security issue. If the form data is sent from a URL that is not secured with SSL, then the form itself might be compromised by a man in the middle attack before the data gets posted.

Operating Instruction

You should deliver all forms encrypted, i.e. use HTTPS.

<form> Unsafe GET to HTTP from HTTPS

Description

The form submits itself to an HTTP URL, but resides on an HTTPS URL. The form is using the GET method. Use this report to identify all URLs on the crawled website that contain forms which use the GET method to submit from HTTPS to HTTP.

Example

Form included in https://example.com/

<form action="http://example.com/form-submit.php" method="GET">
...
</form>
Importance

In this situation, the data is transferred over an unsecured connection to the form action URL and the response will also be sent unsecured. Due to use of the GET method, the form input data will be part of the URL and openly visible to anyone able to access the URL. More than that, the GET method is cacheable, which allows the data to be cached on third party systems. This can be a severe security issue.

Operating Instruction

If you want to transfer your form input data safely, you may consider also delivering the form's target URL over HTTPS and switch from the GET method to the POST method.

<form> Unsafe POST to HTTP from HTTPS

Description

The form submits itself to an HTTP URL, but resides on an HTTPS URL. The form is using the POST method. Use this report to identify all URLs on the crawled website that contain forms that use the POST method to submit from HTTPS to HTTP.

Example

Form included in https://example.com/

<form action="http://example.com/form-submit.php" method="POST">
...
</form>
Importance

In this situation, the data is tranferred over an unsecured connection to the form action URL and the response is also be sent unsecured. This can be a severe security issue.

Operating Instruction

If you want to transfer your form input data safely, you can consider delivering the form's target URL over HTTPS too.

Content-Security-Policy HTTP header missing

Description

If the Content-Security-Policy HTTP header is missing, it is flagged with this hint. This report indicates that your site is not protected from Cross Site Scripting (XSS) and similar security attacks, which is provided by the Content-Security-Policy header.

Example

The simplest form of Content-Security-Policy directive is one that restricts access to your own domain:

Content-Security-Policy: default-src 'self'

The directive can also be used to restrict access to only the https version of your domain:

Content-Security-Policy: default-src https://example.com
Importance

Content Security Policy is an additional level of security that can be added to your site to further protect it from attacks, most notably from Cross Site Scripting (XSS). Content Security Policy is implemented with parameters in the Content-Security-Policy HTTP header directive. Essentially, the parameters allow you to define what gets loaded from where, or in more technical terms, which domains and which resources are allowed to load.

Operating Instruction

We suggest that you use this report to identify web pages that are missing a Content Security Policy header and then add one to each of those pages.

Cookies set without secure flag

Description

If cookies are set without using the secure flag, it is flagged with this hint. This report identifies all URLs that set cookies without a secure flag.

Example

Setting the secure flag is different on each platform. For example, on ASP.NET, you use:

<httpCookies requireSSL='true'/>

In Ruby, you set for an individual cookie as follows:

cookies[:foo, :secure => true] = "bar"
Importance

Always setting cookies to be secure provides an additional level of security for your site. Session hijacking can be particularly malicious when cookie data is stolen since it typically includes user identifiers, passwords and other critical data. So it is best to ensure that cookie exchange is always done via an SSL-secured connection. This is easy to do. Simply set the secure flag for all your cookies to on.

Operating Instruction

We suggest that you use this report to identify cookies that are not secure, and if any are not, we recommend you secure all of them using the secure flag.

Safe HTTPS URL loads unsafe resource

Description

If an HTTPS URL contains an unsafe resource, that is loaded using HTTP, it is flagged with this hint.

Example

Exampe code for https://www.example.com/:

<script type="text/javascript" src="http://www.example.com/file.js"></script>
Importance

All files that get loaded while opening a document over HTTPS, e.g. images, fonts, stylesheets, JavaScripts, should be requested over the HTTPS protocol as well. If elements are loaded using an unsafe HTTP connection, these might get compromised by a man in the middle attack while being loaded. This can compromise the security of the SSL secured request.

If this happens, the increased risk will be reflected in the SSL symbol in all modern browsers. Instead of displaying a green SSL lock, it would be yellow, orange or red to highlight loading of unsafe resources.

Operating Instruction

In documents only available over HTTPS, you should only include files loaded via the HTTPS protocol.

Strict-Transport-Security HTTP header has short duration

Description

If the Strict-Transport-Security HTTP header is set to a short duration, it is flagged with this hint. This report identifies if your web server is NOT properly protected by HTTP Strict Transport Security (HSTS) because a short duration means your site does not have the policy applied for a sufficient period of time.

Example

The duration of your HTTP Strict-Transport-Security (HSTS) policy is defined by the max-age parameter of the Strict-Transport-Security header. Anything less than a year is considered to be a short duration. This is because if max-age is not set sufficiently high, it will expire in the short term and leave your site vulnerable.

For example, if max-age is set to 10 minutes (i.e. 600 seconds), it is considered a short duration:

Strict-Transport-Security: max-age=600

This example sets the duration to be one year which is valid duration (i.e. not a short duration):

Strict-Transport-Security: max-age=31536000

The unit of max-age is seconds, so this line implements HSTS for one year, which is 31,536,000 seconds (i.e. 365 days x 24 hours x 60 minutes x 60 seconds). So anything less than 31536000 seconds is a short duration.

If you use preloading, then the duration must be one year. Preloading is set as follows:

Strict-Transport-Security: max-age=31536000; preload
Importance

While HTTPS has emerged as a more secure protocol than HTTP, it still has vulnerabilities. So just having an SSL certificate is no longer enough to ensure the security of your site. For example, 301 Redirects from HTTP to HTTPS are susceptible to interception by hackers, and in turn, stealing of cookies or session data, or other valuable information.

HTTP Strict Transport Security (HSTS) has emerged in the last few years as a way to add another level of security to your site. HSTS is implemented using the Strict-Transport-Security directive which provides an HTTP response header back to a web browser, or user agent, at the beginning of an interaction. This directive forces the connection to use HTTPS and ignores any calls to load resources via HTTP.

The directive has a variety of parameters that can be used, the most important of which is max-age because this indicates the duration of validity for the HSTS policy. Typically, it is set to one week or one month for testing purposes and then one year or more when put into production.

Crucially, if you want to use preloading, the max-age must be set to one year. Turning preloading on means browsers can only connect to your domain using HTTPS. However, since this is a browser function, it requires some setup: you need to submit your domain and follow the apporpriate guidelines defined here. Once your domain is on the preload list, the various browsers will only allow HTTPS connections to your site.

Operating Instruction

We suggest that you use this report to identify whether the HSTS security policy has been implemented on your site for a sufficient duration and if the duration is too short consider increasing it by setting max-age to 31,536,000 seconds, or more.

Strict-Transport-Security HTTP header is invalid

Description

If a Strict-Transport-Security HTTP header is not properly defined, it is flagged with this hint. This report identifies if your server is NOT properly protected by HTTP Strict Transport Security (HSTS).

Example

An example of an invalid HSTS header is:

Strict-Transport-Security: max-age=-1

The max-age parameter must exist and be greater than or equal to 0 for the HSTS header to be valid.

An example of a valid header is:

Strict-Transport-Security: max-age=31536000

The unit of max-age is seconds, so this line implements HSTS for one year, which is 31,536,000 seconds (i.e. 365 days x 24 hours x 60 minutes x 60 seconds).

Importance

While HTTPS has emerged as a more secure protocol than HTTP, it still has vulnerabilities. So just having an SSL certificate is no longer enough to ensure the security of your site. For example, 301 Redirects from HTTP to HTTPS are susceptible to interception by hackers, and in turn, stealing of cookies or session data, or other valuable information.

HTTP Strict Transport Security (HSTS) has emerged in the last few years as a way to add another level of security to your site. HSTS is implemented using the Strict-Transport-Security directive which provides an HTTP response header back to a web browser, or user agent, at the beginning of an interaction. This directive forces the connection to use HTTPS and ignores any calls to load resources via HTTP.

The directive has a variety of parameters that can be used, the most important of which is max-age because this indicates the duration of validity for the HSTS policy. Typically, it is set to one week or one month for testing purposes and then one year or more when put into production.

Operating Instruction

We suggest that you use this report to identify whether the HSTS security policy has been properly implemented on your site using a valid HSTS header. If not, then HSTS should be properly implemented.

Strict-Transport-Security HTTP header missing

Description

If the Strict-Transport-Security HTTP header is missing, it is flagged with this hint. This report identifies if your web server is NOT protected by HTTP Strict Transport Security (HSTS), which is implemented by the Strict-Transport-Security HTTP header.

Example

A typical Strict-Transport-Security HTTP header looks like this:

Strict-Transport-Security: max-age=31536000

The unit of max-age is seconds, so this line implements HSTS for one year, which is 31,536,000 seconds (i.e. 365 days x 24 hours x 60 minutes x 60 seconds).

Importance

While HTTPS has emerged as a more secure protocol than HTTP, it still has vulnerabilities. So just having an SSL certificate is no longer enough to ensure the security of your site. For example, 301 Redirects from HTTP to HTTPS are susceptible to interception by hackers, and in turn, stealing of cookies or session data, or other valuable information.

HTTP Strict Transport Security (HSTS) has emerged in the last few years as a way to add another level of security to your site. HSTS is implemented using the Strict-Transport-Security directive which provides an HTTP response header back to a web browser, or user agent, at the beginning of an interaction. This directive forces the connection to use HTTPS and ignores any calls to load resources via HTTP.

The directive has a variety of parameters that can be used, the most important of which is max-age because this indicates the duration of validity for the HSTS policy. Typically, it is set to one week or one month for testing purposes and then longer when put into production.

Operating Instruction

We suggest that you use this report to identify whether the HSTS security policy has been implemented on your site and, if it has not been, to take steps to implement it.

Strict-Transport-Security HTTP header sent more than once

Description

If the Strict-Transport-Security HTTP header is sent more than once, it is flagged with this hint. This report identifies multiple Strict-Transport-Security HTTP header directives which can create unexpected behavior.

Example

A typical Strict-Transport-Security header looks like this:

Strict-Transport-Security: max-age=31536000

The unit of max-age is seconds, so this line implements HSTS for one year, which is 31,536,000 seconds (i.e. 365 days x 24 hours x 60 minutes x 60 seconds).

Importance

HTTP Strict Transport Security (HSTS) has emerged in the last few years as a way to add another level of security to your site. HSTS is implemented using the Strict-Transport-Security directive which provides an HTTP response header back to a web browser, or user agent, at the beginning of an interaction. This directive forces the connection to use HTTPS and ignores any calls to load resources via HTTP.

Occasionally though, more than one Strict-Transport-Security HTTP header can be sent. This is typically the result of sloppy programming, bad communication or a misconfigured server. For example, a programmer could send an HSTS header while server administrators will inject their own HSTS header. This results in multiple HSTS headers, in which case only the first is used, so either the programmer or the server administrator will see unexpected behavior on the site.

Operating Instruction

We suggest that you use this report to identify issues that have led to multiple HSTS headers and then rectify the situation by ensuring better communication among your website team or better programming to avoid multiple HSTS headers.