Posted by Peter Birk Pakkenberg, Software program Engineer
X-Requested-With (XRW) is a nonstandard header.
When a consumer installs and runs an utility that makes use of a WebView to embed net content material, the WebView will add the X-Requested-With header on each request despatched to servers, with a price of the appliance APK identify. It’s then left to the receiving net server to find out if and the best way to use this info.
We need to shield the consumer’s privateness by solely sending this header on requests if the app developer explicitly opts-in to share with companies embedded throughout the WebView. We’re introducing new and purpose-built strategies of shopper attestation that resolve essential security use circumstances in a privacy-sensitive method.
To let present on-line companies that rely upon this header migrate away from utilizing it, we are going to run a Deprecation Origin Trial, whereas eradicating the header for normal visitors.
Why are we making this variation?
In early use circumstances, the X-Requested-With header was used to detect click on fraud from malicious apps. It was additionally used to let a server know it is interacting with AJAX requests and needn’t reply with HTML. The header was shortly adopted by frequent frameworks (jQuery, Dojo, Django) as a protection in opposition to CSRF assaults. Nonetheless, a number of vulnerabilities (reminiscent of browser extensions impersonating web sites) appeared round its use.
Android WebView adopted the X-Requested-Header with the appliance identify as the worth, as a solution to enable on-line companies to detect misleading apps that have been utilizing hidden webviews to generate faux visitors. Whereas this downside nonetheless exists in the present day, the header as it’s at the moment carried out doesn’t absolutely resolve the issue, as apps can simply change the worth being despatched on some requests in later Android variations.
The header, as at the moment carried out by default in Android WebView, doesn’t observe the precept of significant consent of all events exchanging the knowledge and the Android Platform Safety Mannequin’s definition of multi-party consent.
APK identify additionally incorporates particular details about the context through which the consumer is consuming the net content material, and may leak the id of the app to the net service.
How does this proposal have an effect on the header?
It is essential to notice that the non-WebView use circumstances is not going to change due to this proposal, as purchasers and servers nonetheless can and can set the header in regular JavaScript environments.
Even in the present day, WebView is not going to overwrite the header if the header has already been set on an AJAX request by a JavaScript framework.
This removing solely targets the WebView use case, which provides the header to each HTTP request made by the browser (that’s, not the XMLHttpRequest use case).
What’s the influence of eradicating this function?
At the moment content material homeowners might determine to depend on X-Requested-With to attribute visitors and management entry with out using their very own authentication. Different companies use it for reporting of mixture patterns about their consumer base.
All of those use circumstances will likely be affected by the removing of the header on requests, and within the majority of circumstances the place the header isn’t modified by dishonest apps, it gives helpful info to on-line companies.
Given this, we plan to restrict disruption in the course of the deprecation and transition to purpose-built substitute indicators by providing a Deprecation Origin Trial to keep up the prevailing habits.
We ask for suggestions on current use circumstances that at the moment depend on and could also be impacted by these modifications.
Subsequent steps and the way forward for XRW
As we steadily roll out the removing, origins collaborating within the trial will likely be exempted (that’s, WebView will proceed to ship the header to those origins for so long as the trial lasts). The deprecation trial is predicted to stay lively for a minimum of a yr to provide companions time to regulate for the change.
Additional, in the course of the deprecation origin trial, we will likely be creating new privacy-preserving APIs to match the use circumstances the place the XRW header is getting used in the present day, reminiscent of shopper attestation APIs.
Individually from the deprecation trial, we are going to present an opt-in API for utility builders. This API will enable particular person apps to selectively ship the header to chosen origins, which can be utilized to keep up performance of legacy websites that aren’t migrating, and the API will stay after the deprecation trial has completed.
Useful assets
Key areas the place we’re in search of suggestions
- Key use circumstances for the XRW header in the present day (e.g., cost authentication, account takeover fraud)
- How essential the XRW header is for every of those use circumstances
- Desired capabilities that any new privacy-preserving alternate options would ideally have
