Protecting your resources from web attacks using a new Feature called FetchMetadata
In June 2020 Google published an article called “Protect your resources from web attacks with Fetch Metadata” on web.dev. It's a new set of request headers to protect your site against common attack vectors for web applications.
What is FetchMetadata
In the nutshell FetchMetadata sends your Joomla site a set of http headers with every request your visitor makes to tell the application how the requested resource was called so the application can decide how to react to them. The specification mentions the following headers: Sec-Fetch-Site, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-User when you want to read up some more detail on the.
The web.dev article also mentions the following cross-origin attack vectors FetchMetadata helps to protects against:
- cross-site request forgery (CSRF)
- cross-site script inclusion (XSSI)
- timing attacks
- cross-origin information leaks
- speculative execution side-channel (Spectre) attacks
What are the steps to implement FetchMetadata
In that article the author writes about 5 Steps or better rules to be implemented in order to use FetchMetadata. Let's take a look at them.
Step 1: Allow requests from browsers which don't send Fetch Metadata
Not all browsers have implemented FetchMetadata yet, so for now we still want to allow all Browsers that do not have them implemented yet. You can check the current browser compatibility matrix at the Mozilla MDN, as of this writing it is supported in Chrome, Edge and Opera in its desktop and mobile browsers. For Firefox that is still under development.
Step 2: Allow same-site and browser-initiated requests
This rule makes sure that all requests made from the same site (e.g. loading an JSON endpoint or images) and browser initiated requests such as bookmarks or navigation on your site is still allowed.
Step 3: Allow simple top-level navigation and iframing
With this rule we allow top-level navigation requests and iframing as we still want our site to be allowed to be open when linked on another site as well as when embedded for example with an iframe.
Step 4: Opt out endpoints that are meant to serve cross-site traffic (Optional)
Some endpoints of your site such as API endpoints are expected to accept cross-site traffic by its nature so they have to be whitelisted here to make sure they will still be loaded.
Step 5: Reject all other requests that are cross-site and not navigational
The last rule is straight forward: Everything that is not catched by the rules above is rejected by the site.
How can I get FetchMetadata into my Joomla site?
Well we got you covered. As for all requests where the Joomla application is triggered we can detect the headers set by the browsers and use them to decide on whether we load the site or not.
So we took that as a task and built a free and easy to use Joomla plugin that implements the rules for your sites. It's called “FetchMetadata by zero24” and can be found on the JED as well as on GitHub.
In order to use it it is as simple as installing the plugin and activating it. All the rules mentioned above are covered by the implementation and the only time you have to configure it is when you provide cross-site endpoints from your site. In the future we might add more options when there is demand for more specific rules or a reporting-only feature. Feel free to contact us on GitHub with any questions regarding that plugin, bugs or feature requests.
What are the next steps?
As Joomla 4.0 is not accepting any new features, but we think that this is an important protection feature for all Joomla sites we plan to propose a FetchMetadata implementation as a Core feature for Joomla 4.1 but at this point that Code has not been written yet. Until that has happened you can use the plugin with your Joomla to protect it.
This article has been written by the developer of the plugin and does not represent the Joomla Project’s opinion or vision.