What is the Timing-Allow-Origin header?

This header is a very important mechanism for controlling cross-origin timing information sharing. This HTTP header essentially dictates which origins are permitted to access detailed timing data from a particular resource. When a web browser makes a cross-origin request for timing-related information, this header acts as the one that dictates whether the requested data can be accessed by the initiating domain. In other words, it helps regulate the flow of timing information, which can help boost both security and performance in cross-origin requests.

If we go into the details, we find that the Timing-Allow-Origin header works in conjunction with the Resource Timing API. It ensures that sensitive timing details, such as the duration of network requests and other metrics, are shared only with authorized domains. By limiting the allowed origins, this header plays a key role in protecting user privacy and maintaining the integrity of cross-origin communications.

The Importance of Timing-Allow-Origin

The significance of the Timing-Allow-Origin header becomes evident when considering the huge impact it has on web performance and security. By carefully controlling which domains can access detailed timing information, this header will help mitigate the risk of information exposure to unauthorized parties. From a technical point of view, it contributes to the implementation of the same-origin policy, one of the most important security measures out there, which prevents malicious websites from accessing sensitive data from other domains.

And let’s not forget that this header also has a role in optimizing web performance. By allowing authorized domains to access specific timing data, it facilitates the fine-tuning of applications and websites for enhanced efficiency. Thanks to this optimization it is possible to achieve a smoother user experience, faster loading times, and improved overall performance.

Despite its importance and benefits, the Timing-Allow-Origin header is not widely used, in fact, it can be considered a relatively new header: it was first supported by a major browser barely 4 years ago. Currently, it’s used by 0,15% of websites out there, according to data provided by Webtechsurvey.

Timing-Allow-Origin browser compatibility

As we mentioned before, this is a pretty new header, and until a few years ago there was no browser support for it, but that changed in January 2020 thanks to Microsoft Edge, which was the first major browser to support it.

Support from other major players came years later, as reported by CanIUse.com: both Google Chrome and Mozilla Firefox started to support it in February 2024, Apple Safari in January 2024 and Opera in December 2023.

What’s the Timing-Allow-Origin syntax?

The Timing-Allow-Origin header doesn’t have a complex syntax. In fact, its usage is very straightforward. The header takes the form of a simple HTTP response header, and it simply involves specifying the allowed origins that are permitted to access timing information.

The syntax is the following:

Timing-Allow-Origin: <origin>  | *

In the above example, <origin> represents the specific origin (domain) that is granted permission to access the timing information.
The asterisk * serves as a wildcard, allowing any origin to access the timing information.

And that’s it. This flexibility enables developers and sysadmins to customize the level of access based on their specific security and performance requirements.

Examples of Timing-Allow-Origin

As we have already mentioned, the syntax for this header is pretty simple, so let’s see a couple of examples of it.

If you want to grant timing information access to a single origin, you would specify:

Timing-Allow-Origin: https://example.com

In this example, the allowed domain is “example.com”.

You can allow even allow multiple domains, for example:

Timing-Allow-Origin: https://example.com, https://myshinydomain.com

In this case, both example.com and myshinydomain.com are allowed.

Meanwhile, if you want to allow any origin to access the timing information, you would use the wildcard:

Timing-Allow-Origin: *

To maintain top security and performance, remember to set the header to allow only specific domains.

How to configure Timing-Allow-Origin

Configuring the Timing-Allow-Origin header is done by setting it on the server side. Here’s a basic guide on how to do it.

First, decide whether you want to restrict access to a specific origin or allow any origin. Remember the examples above: you can set the header to a specific origin or use the wildcard * to allow any origin.

Enabling Timing-Allow-Origin in Apache

This can be done either in Apache’s configuration files or in your .htaccess file, so let’s see both methods.

Apache configuration file

Open your Apache configuration file. This could be the main configuration file (httpd.conf) or a virtual host file.

Find the section for the specific domain or add the following lines if you are configuring globally:

<IfModule mod_headers.c>

Header set Timing-Allow-Origin "https://example.com"

</IfModule>

Replace “https://example.com” with the actual origin you want to allow.
If you want to allow any origin, remember to use a wildcard instead:

<IfModule mod_headers.c>

Header set Timing-Allow-Origin "*"

</IfModule>

Save the configuration file and restart Apache to apply the changes:

systemctl restart apache2

.htaccess file:

If you don’t have access to the main Apache configuration file, you can use the .htaccess file in the root directory of your website:

Open or create the .htaccess file in your website’s root directory, then add the following lines:

<IfModule mod_headers.c>

Header set Timing-Allow-Origin "https://example.com"

</IfModule>

Replace “https://example.com” with the actual origin or use “*” to allow any origin:

<IfModule mod_headers.c>

Header set Timing-Allow-Origin "*"

</IfModule>

Save the .htaccess file.

Setting up Timing-Allow-Origin in Nginx

Enabling Timing-Allow-Origin in Nginx is done by adding an “add_header” directive to your Nginx configuration. Here’s a basic guide:

First off, open your domain’s Nginx configuration file. The Nginx configuration file is typically located at /etc/nginx/nginx.conf or in the /etc/nginx/conf.d/ directory. The exact path may vary based on your operating system and Nginx setup.

Find the server block corresponding to your website. This block contains the configuration for the specific server.

Within the server block, add the following line to set the Timing-Allow-Origin header:

add_header Timing-Allow-Origin "https://example.com";

Replace “https://example.com” with the specific origin you want to allow, or use “*” to allow any origin.

Save the changes to the Nginx configuration file and exit the editor.

Before putting the changes into effect, it’s a good practice to test the configuration for syntax errors:

nginx -t

If the test is successful, reload Nginx to apply the changes:

systemctl reload nginx

Or restart it:

systemctl restart nginx

How to test the Timing-Allow-Origin settings

Make sure to check our guide below to test your settings:

Start by accessing our http security scanner.
Now input your domain in the scan box.
Make sure to tick the two boxes below, named ‘Clear cache’ and ‘Follow redirects’.
Click the Scan button.
Scroll down to the section named ‘HTTP Security Headers’, and look for your ‘Timing-Allow-Origin’ test results: a ‘Passed’ in green means that you’re good to go, but getting a ‘Failed’ in red means that you will have to update your settings.

Timing-Allow-Origin FAQ

Let’s answer some of the most common questions about this header.

What is the purpose of the Timing-Allow-Origin header?

This header regulates cross-origin access to timing information. It controls which domains are authorized to retrieve detailed timing data from a particular resource.

How does the Timing-Allow-Origin header enhance web security?

By specifying permissible origins, the header helps enforce the same-origin policy, preventing unauthorized domains from accessing sensitive timing information.

What values can be set for Timing-Allow-Origin?

The header can be set to a specific origin (for example, https://example.com) to allow access only to that domain or even multiple domains. Alternatively, the wildcard * can be used to permit any origin to access the timing information.

What implications does the wildcard (*) have?

Using * allows any origin to access timing information, providing flexibility but requiring careful consideration of security implications. It’s important to make sure that this practice aligns with the website’s security requirements.

Does Timing-Allow-Origin impact website performance?

Its impact is small, but yes, by providing controlled access to timing data, the header helps to optimize web performance, leading to faster load times, which results in an improved user experience.

Is Timing-Allow-Origin the same as Access-Control-Allow-Origin?

No. They are both HTTP headers, but they serve different purposes. We already know that Timing-Allow-Origin controls cross-origin access to timing information, allowing or denying websites the ability to retrieve detailed timing data from a specific resource.
Meanwhile, Access-Control-Allow-Origin controls which origins are allowed to access resources on a web page from a different domain.
So, while both deal with cross-origin communications, they have different purposes.

Summary

The Timing-Allow-Origin header has the important task of simplifying the exchange of timing data between websites. Its role, though technical, is clear: it is the one in charge of allowing or denying access to timing information, thus optimizing the performance and efficiency of web interactions.

Looking at the technicalities of the Timing-Allow-Origin header, we can see that it boosts web security by controlling which domains can access detailed timing data, aligning with the well-known same-origin policy. It also provides a small boost for web performance, contributing to faster loading times; and, while the header is relatively new and currently utilized by a modest percentage of websites, its impact on web security and performance is clear.