ResourceIsolation: Fetch metadata based resource isolation plugin

In firesafety: A Collection of Security Related Plugins for 'fiery'

Fetch metadata based resource isolation plugin

Description

This plugin uses the information provided in the ⁠Sec-Fetch-*⁠ request headers to block unwanted requests to your server coming from other sites. Setting up a strict control with which requests are allowed is an important part of preventing some cross-site leaks as well as cross-site request forgery attacks.

Details

Compared to the other security measures in firesafety, the reource isolation plugin is a server-side blocker of requests. Both CORS and CORP sends back a full response and it is then up to the browser to determine if the response becomes available to the site. In contrast, this plugin will return a 403 response if the request fails to be accepted. This is not to say that resource isolation is better than CORS, CORP or other measures. They all target different situations (or the same situation from different angles) and works best in unison. You can read more about this type of defence at MDN and XS-Leaks Wiki

How it works

Resource isolation takes advantage of the ⁠Sec-Fetch-*⁠ headers that browser send along with requests. These headers informs the server about the nature of the request. Where it comes from, what action initiated it, and how it will be used. Based on this information the server may chose to allow a request to proceed or deny it altogether. This plugin runs a request through a range of tests and if it passes any of them it proceeds:

1. Does the request have the ⁠Sec-Fetch-*⁠ headers

2. Is allow_cors == TRUE and is Sec-Fetch-Mode set to cors

3. Is Sec-Fetch-Site set to allowed_site or a more restrictive value

4. Is the request method GET, the Sec-Fetch-Mode navigation, and the Sec-Fetch-Dest not one of those given by forbidden_navigation

You can have different permissions for different paths. The default during initialization is to add it to ⁠/*⁠ so that all all paths will share the same policy, but you can strengthen or loosen up specific paths as needed. A good rule of thumb is to make the policy as restrictive as possible while allowing your application to still work as intented. Further, if you have paths that do not have a resource isolation policy in place these should have CORS enabled.

Initialization

A new 'ResourceIsolation'-object is initialized using the new() method on the generator and pass in any settings deviating from the defaults

Usage

resource_isolation <- ResourceIsolation$new(...)

Fiery plugin

A ResourceIsolation object is a fiery plugin and can be used by passing it to the attach() method of the fiery server object. Once attached all requests will be passed through the plugin and the policy applied to it

Active bindings

name

The name of the plugin

Methods

Public methods

• ResourceIsolation$new()

• ResourceIsolation$add_path()

• ResourceIsolation$on_attach()

• ResourceIsolation$clone()

---

Method new()

Initialize a new ResourceIsolation object

Usage

ResourceIsolation$new(
  path = "/*",
  allowed_site = "same-site",
  forbidden_navigation = c("object", "embed"),
  allow_cors = TRUE
)

Arguments

path

The path that the policy should apply to. routr path syntax applies, meaning that wilcards and path parameters are allowed.

allowed_site

The allowance level to permit. Either cross-site, same-site, or same-origin.

forbidden_navigation

A vector of destinations not allowed for navigational requests. See the Sec-Fetch-Dest documentation for a description of possible values. The special value "all" is also permitted which is the equivalent of passing all values.

allow_cors

Should Sec-Fetch-Mode: cors requests be allowed

---

Method add_path()

Add a policy to a path

Usage

ResourceIsolation$add_path(
  path,
  allowed_site,
  forbidden_navigation = c("object", "embed"),
  allow_cors = TRUE
)

Arguments

path

The path that the policy should apply to. routr path syntax applies, meaning that wilcards and path parameters are allowed.

allowed_site

The allowance level to permit. Either cross-site, same-site, or same-origin.

forbidden_navigation

A vector of destinations not allowed for navigational requests. See the Sec-Fetch-Dest documentation for a description of possible values. The special value "all" is also permitted which is the equivalent of passing all values.

allow_cors

Should Sec-Fetch-Mode: cors requests be allowed

---

Method on_attach()

Method for use by fiery when attached as a plugin. Should not be called directly.

Usage

ResourceIsolation$on_attach(app, ...)

Arguments

app

The fiery server object

...

Ignored

---

Method clone()

The objects of this class are cloneable with this method.

Usage

ResourceIsolation$clone(deep = FALSE)

Arguments

deep

Whether to make a deep clone.

Examples

# Create resource isolation policy denying all navigation requests
resource_isolation <- ResourceIsolation$new(forbidden_navigation = "all")

# Allow cross-site requests on a subpath
resource_isolation$add_path(
  path = "/all_is_welcome/*",
  allowed_site = "cross-site"
)


# Use it in a fiery server
app <- fiery::Fire$new()

app$attach(resource_isolation)

firesafety documentation built on Sept. 10, 2025, 10:27 a.m.