Google-developed standard goes further to protect web apps from XS-Leak, CSRF, and more
Google’s Fetch Metadata request headers provide web servers with extra security information that can help decide whether to block or allow requests.
They also allow a user to deploy a Resource Isolation Policy, a strong defense-in-depth mechanism.
This can not only protect a user from potentially harmful attacks, such as CSRF, cross-site script inclusion (XSSI), and cross-site leaks (XS-Leaks), but can also help servers to differentiate between cross-site and same-origin requests.
Lukas Weichselbaum, staff information security engineer at Google, released a blog post explaining how to use the feature, and why we should all be employing it.
RELATED Google rolls back Chrome SameSite cookie changes due to coronavirus concerns
He told The Daily Swig: “Many classes of security vulnerabilities in the web are caused by a lack of context when authenticated requests are processed by web servers.
“For example, browsers attach cookies to requests regardless if they’re initiated by the user or by an attacker-controlled document causing vulnerabilities like CSRF, XSSI, XS-Leaks, clickjacking, and enabling web information leaks through the abuse of microarchitectural side-channel attacks such as Spectre.
“Fetch Metadata request headers close this gap by providing simple enums to the server, allowing it to discard malicious cross-site traffic and therefore enabling developers to tackle a vast range of issues at once.”
Pilot programs
Before Fetch Metadata headers were introduced, a server could not differentiate between a same-origin, same-site, or cross-site request.
By using Sec-Fetch-* headers, it is possible for developers to apply security policies, for instance only allowing legitimate requests made by their own application.
Weichselbaum told The Daily Swig that it was fairly easy to implement. Google initially rolled out a resource isolation policy based on Fetch Metadata in three pilots – Google Photos, Google Contacts, and My Activity.
Read the latest browser security news
“We usually first enable the policy in logging mode which allows us to confirm that we're not blocking any legitimate traffic and then switch on enforcement,” he said.
“In logging mode, we even found some external uses of some of our resources that were used for login detection. This is blocked now thanks to Fetch Metadata.
“Meanwhile, resource isolation is enabled by default for all new applications built on our core framework and we’re in the process of mass migrating hundreds of existing apps right now.”
Browser support
While it should be used as an additional, rather than primary, layer of security, it is likely that the Fetch Metadata standard will be supported by all web browsers in the future.
It is already available for use in Chrome, Edge, Opera – unsurprising, since these browsers are all based on Chromium, and has also been enabled for use in Firefox.
RELATED Firefox becomes latest browser to support Fetch Metadata request headers
Weichselbaum said: “All major browsers except Safari support, or will support, Fetch Metadata. This is already quite an amazing coverage for a new security feature!
“Safari didn't oppose the idea at W3C TPAC 2019, and we’re hoping that they’ll also implement Fetch Metadata once it has gained some traction.
“However, it’s a bit of a chicken/egg problem. Sometimes browser vendors wait to implement a new feature until they see it’s getting traction, but to gain traction, broad browser support is needed.”
READ MORE New Safari clipboard API includes additional browser security, privacy mechanisms
