Posted by Peter Birk Pakkenberg, Software Engineer
X-Requested-With (XRW) is a nonstandard header.
When a user installs and runs an application that uses a WebView to embed web content, the WebView will add the X-Requested-With header on every request sent to servers, with a value of the application APK name. It is then left to the receiving web server to determine if and how to use this information.
We want to protect the user’s privacy by only sending this header on requests if the app developer explicitly opts-in to share with services embedded within the WebView. We are introducing new and purpose-built methods of client attestation that solve important safety use cases in a privacy-sensitive manner.
To let current online services that depend on this header migrate away from using it, we will run a Deprecation Origin Trial, while removing the header for general traffic.
Why are we making this change?
In early use cases, the X-Requested-With header was used to detect click fraud from malicious apps. It was also used to let a server know it’s interacting with AJAX requests and needn’t reply with HTML. The header was quickly adopted by common frameworks (jQuery, Dojo, Django) as a defense against CSRF attacks. However, several vulnerabilities (such as browser extensions impersonating websites) appeared around its use.
Android WebView adopted the X-Requested-Header with the application name as the value, as a way to allow online services to detect deceptive apps that were using hidden webviews to generate fake traffic. While this problem still exists today, the header as it is currently implemented does not fully solve the problem, as apps can easily change the value being sent on some requests in later Android versions.
The header, as currently implemented by default in Android WebView, does not follow the principle of meaningful consent of all parties exchanging the information and the Android Platform Security Model’s definition of multi-party consent.
APK name also contains specific information about the context in which the user is consuming the web content, and can leak the identity of the app to the online service.
How does this proposal affect the header?
It’s important to note that the non-WebView use cases will not change because of this proposal, as clients and servers still can and will set the header in normal JavaScript environments.
Even today, WebView will not overwrite the header if the header has already been set on an AJAX request by a JavaScript framework.
This removal only targets the WebView use case, which adds the header to every HTTP request made by the browser (that is, not the XMLHttpRequest use case).
What is the impact of removing this feature?
Today content owners may decide to rely on X-Requested-With to attribute traffic and control access without employing their own authentication. Other services use it for reporting of aggregate patterns about their user base.
All of these use cases will be affected by the removal of the header on requests, and in the majority of cases where the header is not modified by dishonest apps, it provides useful information to online services.
Given this, we plan to limit disruption during the deprecation and transition to purpose-built replacement signals by offering a Deprecation Origin Trial to maintain the existing behavior.
We ask for feedback on existing use cases that currently rely on and may be impacted by these changes.
Next steps and the future of XRW
As we gradually roll out the removal, origins participating in the trial will be exempted (that is, WebView will continue to send the header to these origins for as long as the trial lasts). The deprecation trial is expected to remain active for at least a year to give partners time to adjust for the change.
Further, during the deprecation origin trial, we will be developing new privacy-preserving APIs to match the use cases where the XRW header is being used today, such as client attestation APIs.
Separately from the deprecation trial, we will provide an opt-in API for application developers. This API will allow individual apps to selectively send the header to chosen origins, which can be used to maintain functionality of legacy sites that are not migrating, and the API will remain after the deprecation trial has finished.
Helpful resources
Key areas where we are seeking feedback
- Key use cases for the XRW header today (e.g., payment authentication, account takeover fraud)
- How important the XRW header is for each of these use cases
- Desired capabilities that any new privacy-preserving alternatives would ideally have
Discussion about this post