The Permissions-Policy directive (formerly known as Feature-Policy) is an essential component of modern web security, designed to give developers and website owners granular control over browser features that could affect performance, security, and privacy.

One of the directives within this policy is "sync-xhr", which controls the use of synchronous XMLHttpRequests (XHRs) in web applications. Synchronous XHRs were once commonly used to send requests to the server and receive responses without refreshing the page. However, this method has fallen out of favour due to its negative impact on performance, usability, and the overall browsing experience.

History and Origin of Permissions-Policy

The Permissions-Policy header was introduced by Google in 2018 under the original name Feature-Policy. The objective was to give developers more control over the use of powerful browser features that, if left unrestricted, could introduce security, privacy, or performance vulnerabilities. With the increasing complexity of web applications and the reliance on third-party content, developers needed a way to manage which parts of their websites could access certain features or APIs.

Synchronous XMLHttpRequests (XHR) have been part of the web for many years, offering a way to send HTTP requests and wait for a server response before continuing execution. However, synchronous XHRs block the main thread, freezing the user interface until the response is received, which can lead to poor user experiences, such as unresponsive web pages or application timeouts. Modern best practices encourage the use of asynchronous requests (e.g., using fetch or asynchronous XHRs), which allow the browser to continue running other tasks while waiting for the server response.

The sync-xhr directive was added to give developers the ability to disable the use of synchronous XHRs, ensuring that websites adhere to best practices for performance and user experience.

What Does the Sync-XHR Directive Do?

The "sync-xhr" directive in the Permissions-Policy header controls whether a website or any embedded content can make synchronous XMLHttpRequests. This means that developers can restrict access to this outdated feature and prevent its use in web applications, reducing the likelihood of performance bottlenecks and improving the responsiveness of their websites.

For example:

• Setting sync-xhr=() disallows all synchronous XMLHttpRequests, ensuring that no part of the website or its embedded content can block the main thread with this outdated method.
• Setting sync-xhr=* allows synchronous XHRs to be used throughout the site, but this is generally discouraged due to the negative impact it can have on performance and user experience.

By restricting the use of synchronous XHRs, website owners can ensure that their sites provide a smoother, more responsive experience and reduce the risk of performance issues.

Why Was It Added?

The sync-xhr directive was introduced to address several key concerns related to performance, user experience, and security:

1. Improving Performance: Synchronous XHRs block the browser’s main thread while waiting for a response from the server, leading to poor performance and unresponsive user interfaces. This is particularly problematic in modern, dynamic web applications where responsiveness is critical. The sync-xhr directive was added to prevent the use of this inefficient method, ensuring that websites rely on more modern, non-blocking techniques for server communication.

2. Preventing Browser Lockups: Because synchronous XHRs block the main thread, they can cause browsers to become unresponsive if the server takes too long to respond. This not only frustrates users but can also lead to a higher abandonment rate as users are forced to refresh or close the page. The directive ensures that developers avoid this issue by preventing the use of synchronous requests, keeping the user interface responsive at all times.

3. Mitigating Security Risks: While synchronous XHRs are primarily a performance issue, they can also introduce security concerns in some scenarios. For instance, blocking the main thread could create opportunities for Denial of Service (DoS) attacks, where a malicious actor forces the server to take a long time to respond, freezing the browser for extended periods. Additionally, older, poorly designed code that uses synchronous XHRs might not properly handle errors or timeouts, potentially leading to vulnerabilities that could be exploited. The sync-xhr directive helps mitigate these risks by encouraging developers to follow best practices and avoid the use of outdated methods.

4. Encouraging Modern Web Development Practices: The use of synchronous XHRs has been discouraged for years in favour of asynchronous approaches, which provide a more user-friendly experience. The sync-xhr directive supports this by giving developers a mechanism to enforce the use of more modern techniques, like fetch or Promises, which enable asynchronous, non-blocking requests.

Use Cases It Guards Against

The sync-xhr directive is valuable in preventing several problematic use cases:

1. Blocking the User Interface: When a web page uses synchronous XHRs, the user interface becomes unresponsive while the browser waits for a server response. This results in poor user experiences, especially on slow networks or when the server is under heavy load. The sync-xhr directive prevents this by disallowing synchronous requests, ensuring the user interface remains responsive.

2. Performance Degradation: Websites that use synchronous XHRs can suffer from significant performance issues, especially when multiple requests are made. This can slow down the entire application, leading to higher bounce rates as users abandon the site due to slow or unresponsive behaviour. The directive forces developers to use more efficient, non-blocking techniques, improving performance.

3. Potential DoS Attack Vectors: Synchronous XHRs can be exploited by attackers who send requests designed to keep the browser blocked for long periods, effectively rendering the site unusable for the user. By preventing the use of synchronous XHRs, the directive reduces the risk of such DoS attacks.

4. Third-Party Content Misuse: Many websites incorporate third-party content, such as analytics tools, ads, or widgets, which may use synchronous XHRs. If these third-party scripts rely on outdated techniques, they can degrade the performance of the entire website. The sync-xhr directive allows developers to prevent third-party content from using synchronous requests, ensuring that the performance of the site is not negatively affected.

Why Should You Set Permissions-Policy Sync-XHR Correctly?

There are several compelling reasons why website owners should ensure the sync-xhr directive is configured properly:

1. Improving User Experience: Synchronous XHRs block the main thread, leading to unresponsive web pages and frustrating user experiences. By configuring the sync-xhr directive to disable synchronous requests, website owners can ensure that their sites remain responsive and user-friendly, especially during long-running tasks or slow network conditions.

2. Boosting Website Performance: Performance is a critical factor for user retention and engagement. Sites that use synchronous XHRs risk slowing down the entire browsing experience. The sync-xhr directive forces developers to use non-blocking, modern techniques, improving overall website performance and reducing page load times.

3. Reducing Security Risks: While the primary concern with synchronous XHRs is performance, there are also security implications, such as the potential for DoS attacks or vulnerabilities introduced by outdated code. Configuring the sync-xhr directive correctly reduces the likelihood of these security risks, ensuring a safer and more stable web application.

4. Encouraging Modern Development Practices: The web is evolving towards asynchronous, non-blocking interactions, and the use of synchronous XHRs is widely considered a bad practice. By setting the sync-xhr directive to disallow synchronous requests, developers are encouraged to adopt best practices, such as using fetch or Promises, which provide a more efficient and scalable way to handle server communication.

5. Minimising Third-Party Impact: Third-party scripts, such as ads or analytics tools, may rely on synchronous XHRs if they are outdated. Allowing these scripts to block the main thread can degrade the performance of the entire website. The sync-xhr directive allows developers to prevent third-party content from using these blocking requests, ensuring that external elements do not negatively impact the user experience.

Conclusion: Ensuring Modern Performance with the Sync-XHR Directive

The Permissions-Policy sync-xhr directive is a vital tool for managing access to the synchronous XMLHttpRequest (XHR) feature, which can negatively impact website performance and user experience if misused. While synchronous XHRs were once common, they are now considered outdated and problematic due to their tendency to block the browser’s main thread, leading to unresponsiveness and performance degradation.

By configuring the sync-xhr directive to disallow synchronous requests, website owners can ensure that their sites follow modern web development best practices, improve performance, and reduce security risks. Whether managing your own content or dealing with third-party scripts, enforcing this directive is essential for providing a smooth, responsive, and secure browsing experience for users.