Security Considerations

IP access rules

Posit Workbench can be configured to deny access to specific IP addresses or ranges of addresses. Access rules are defined in the configuration file /etc/rstudio/ip-rules

Access rules are established using the allow and deny directives and are processed in order, with the first matching rule governing whether a given address is allowed or denied. For example, to allow only clients within the subnet but also deny access to you would use these rules:

deny    all

All clients outside of the specified subset are denied access because of the deny all rule at the end of the configuration.

Note that changes to the configuration will not take effect until the server is restarted.

Frame origin

For security reasons, Workbench will not load inside a browser frame (such as a frameset or iframe) by default. You can modify this behavior by using the www-frame-origin option. For example, if you would like to host Workbench inside a browser frame at, you can tell Workbench to allow this as follows:


There are several special values available for the www-frame-origin option:

Value Meaning
none The default; do not allow Workbench to load in any frame.
same Allow Workbench to load in a frame if it has the same origin (host and port) as Workbench.
any Allow Workbench to load in a frame from any origin (not recommended) Allow Workbench to load in a frame at

To interact programmatically with Workbench in an iframe, see the Tutorial API.

CSRF attack mitigation

To help mitigate against CSRF attacks, Workbench can automatically reject any request originating from an Origin or Referer that does not match the Host, X-Forwarded-Host, Forwarded: host or X-RStudio-Request headers. To enable this check, add the following configuration:


In some cases, such as if running behind a proxy that you cannot modify, this check may be too strict, and can prevent access to Workbench, causing requests to return a 400 status. In such cases, it is recommended that you disable the check. Origin checking is currently disabled by default, but will likely be enabled by default in a future version of Workbench.

You may wish to consider some origins to be safe in all cases, causing Workbench to consider such Origin or Referer values to be allowed instead of being rejected, even if they do not match a Host header. To specify such origins, add each of them as a www-allow-origin setting in rserver.conf. For example:


Note that wildcards (*) are accepted and will match any character, including hostname separators. For instance, the previous example of * will match both and

Additional headers

In some cases, you may need to have Workbench set additional headers on client responses. To do this, simply specify server-add-header for each header that you need to add, in the form Header Name:Header Value. For example, to have the server set a few extra custom headers:

server-add-header=X-Header-1:Value 1
server-add-header=X-Header-2:Value 2