Security & Auditing#
Sessions are stored on the server in RStudio Connect. Encrypted session cookies stored only on the client are deprecated, as they provide inferior security.
When signing into RStudio Connect, a browser cookie is used to keep the user logged in. See the Limiting Session Lifetime section for details about the default session lifetime and how to change it.
The server will periodically check the data store for expired cookies and
remove them. This happens once per hour by default, but is configurable using
configuration setting. This does not affect the lifetime of web sessions,
which is controlled by the
Preventing Brute Force & Dictionary Attacks#
By default, RStudio Connect allows as many login attempts as it can handle from any source when using the PAM, LDAP, and Password authentication providers. Users will be able to log in directly by entering their user name and password.
true enables a CAPTCHA form in the login screen, and requires that
CAPTCHA be solved in order to authenticate. Both visual and audio CAPTCHA
challenges are provided for accessibility needs.
Hiding RStudio Connect Server Version and Build Information#
By default RStudio Connect sets the
Server HTTP header to the Connect
version with commit offset, which looks something like
v1.2.3-1234. If you would like to hide this information you can configure
Server.ServerName to be any
string. If you would also like to hide the version and build information
within the Connect dashboard you may configure the
There are a variety of security settings that can be configured in RStudio Connect. Some of these settings are enabled by default but can be customized while others are opt-in. Below are some of the security features worth considering.
Web Sudo Mode#
When a user performs a sensitive operation in a web browser (such as creating a
new API key), they will be asked to reenter their login credentials. Once the
user enters their password properly, their session will enter a privileged
state internally referred to as "web sudo mode" which will allow them to perform
these sensitive operations for a certain window of time without entering their
password again. Note that this privileged mode is a notion purely internal to
RStudio Connect and entirely unrelated to the server's actual
sudo or PAM
This feature is not available on servers configured to use Single Sign-On (SSO) via OAuth2, OpenID, SAML, or proxied authentication, as these providers don't have a mechanism for re-prompting the user for their password.
For all other authentication providers, the
WebSudoModeDuration configuration options are available within the section
pertaining to that provider. If
WebSudoMode is set to
false, then this
protection is disabled; effectively, all authenticated users are always in
WebSudoModeDuration controls the length of time for which a
user stays in this privileged mode. From within the section pertaining to your
authentication provider (such as
[LDAP]), you could
; /etc/rstudio-connect/rstudio-connect.gcfg ; This example is using password authentication. Use PAM or LDAP as appropriate. [Password] WebSudoMode = true WebSudoModeDuration = 10m
In this case, users would be prompted for their password before performing sensitive actions, then would be allowed to continue performing sensitive actions for up to 10 minutes without additional prompts. After that point, any sensitive actions would require entering their password again.
Regardless of the setting, web sudo mode will never affect calls made outside of a browser using a token or an API key.
Limiting Session Lifetime#
The default RStudio Connect configuration enforces the following limits on authenticated sessions:
- Sessions are invalidated after 24 hours, regardless of activity.
- Inactive sessions are considered idle and invalidated after 8 hours.
Once a session is considered invalid, the user will need to reauthenticate before continuing to interact with RStudio Connect.
These limits follow good security practices by ensuring that users enter their credentials daily.
The session lifetime and inactive threshold are configurable settings. Adjust
the maximum session lifetime by changing the
setting. Session inactivity is controlled with the
Configure these session settings according to your organization's security policies.
We use a 24 hour default for
Authentication.Lifetime because it means that
access will be revalidated against your authentication provider (e.g. your
Active Directory server) at least once a day. The 8 hour default for
Authentication.Inactivity tries to avoid forcing a user to reauthenticate
more than once during a typical work day.
Our first configuration example has shorter thresholds than the configured defaults. Users will need to reauthenticate after being idle for 30 minutes or after their session lasts for 12 hours. The 30 minute inactivity limit means that sessions may be idle "no longer than a lunch break."
; /etc/rstudio-connect/rstudio-connect.gcfg [Authentication] Lifetime = 12h Inactivity = 30m
This second configuration example has longer thresholds than our configured defaults. Users will need to reauthenticate once a week or after being inactive for a full day. Adopt this type of configuration with care; your organization may want users to reauthenticate more frequently.
; /etc/rstudio-connect/rstudio-connect.gcfg [Authentication] Lifetime = 7d Inactivity = 1d
RStudio Connect uses session cookies to track and enforce both the session lifetime and inactive threshold.
If a user's session expires or is considered inactive with an application left running in their browser that application's process will not be terminated immediately. Further attempts to interact with the application will then cause it to close and then the user will be asked to reenter credentials.
Shiny applications may be able to outlive sessions when opened in Solo mode
if their timeout settings are greater than
determine the default values for how long a browser running a Shiny
application can remain idle. By default these are set to 1 hour but
individual applications may set higher values independently from the
If you can guarantee that your server should only ever be accessed over a
TLS/SSL connection (HTTPS), then you can consider enabling the
HTTPS.Permanent setting. This
elevates the security of your server by requiring that future interactions
between your users and this server must be encrypted.
Enabling this setting may keep users from being able to access your RStudio Connect instance if you later disable HTTPS or if your certificate expires. Use this setting only if you will permanently provide a valid TLS/SSL certificate on this server.
Behind the scenes, this makes two changes:
Introduces HTTP Strict Transport Security (HSTS) by adding a
Strict-Transport-SecurityHTTP header with a
max-ageset to 30 days. HSTS ensures that your users' browsers will not trust a service hosted at this location unless it is protected with a trusted TLS/SSL certificate.
Secureflag on cookies that are set. This prohibits your users' browsers from sending their RStudio Connect cookies to a server without an HTTPS-secured connection.
You can constrain the TLS version used by HTTPS. This may help you meet the security policy for your organization.
specifies the minimum TLS version. Clients using a lower TLS version will be
rejected. The default minimum TLS version is TLS 1.0. You can configure this
setting to 1.0, 1.1, 1.2, or 1.3.
We recommend that you check that the browsers and clients used within your organization are compatible with your minimum TLS version choice. The SSL Labs User Agent List enumerates the TLS capabilities for most popular browsers.
Here is an HTTPS configuration permitting TLS versions 1.2 and above:
[HTTPS] Listen = 443 MinimumTLS = 1.2
Some Windows builds of the
RCurl package are not compatible with TLS 1.1
or TLS 1.2. Windows users should execute
options(rsconnect.http = 'curl')
to use the local
curl binary, if installed, instead of the outdated
Older versions of the RStudio IDE may use webviews that are not compatible with TLS 1.1 or TLS 1.2. In this case, attempting to pair with RStudio Connect without TLS 1.0 would open a blank screen instead of a login window. Open the blue link from the pairing window in the browser, or install a newer version of RStudio Connect as a workaround.
We recommend using a secure proxy if you need finer control over HTTPS.
Using a Secure Proxy#
If you would prefer that the RStudio Connect process not have access to your TLS/SSL certificates, you may wish to configure a proxy to handle HTTPS requests. To accomplish this:
Ensure that your
Server.Addressis set to the proxy address and uses the
true, which will set the
Secureflag on all cookies.
trueto suppress the warning regarding running RStudio Connect over an unsecured connection, because the connection between the client and the proxy will be secured.
If necessary, enable the
HTTPRedirect.Listenoption to redirect proxied plain HTTP connections to HTTPS.
Because the connection between the proxy and RStudio Connect is not secured in this case, please ensure that the proxy and RStudio Connect are connecting on a trusted network where an adversary would not be able to capture plain text credentials. For example, many cloud providers allow isolating servers from the internet while permitting load balancers to access them. Please see your cloud provider's documentation for more details.
setting can be used to configure HTTP responses with the
X-Content-Type-Options header. This header can protect your users from a
certain class of malicious
is disabled (the default), the
X-Content-Type-Options HTTP header is given
the value of
nosniff. This instructs browsers not to inspect the content in
an attempt to identify its type.
is enabled, the
X-Content-Type-Options HTTP header is not sent; browsers are
free to analyze the content to detect its type.
X-Frame-Options HTTP header is used to control what content can be
embedded inside other content in a web browser. The relevant attack is
commonly referred to as a “clickjack
and involves having your users interact with a sensitive service without their
For the purposes of the
X-Frame-Options header, RStudio Connect
distinguishes between “dashboard” and “user” content. The dashboard is
any of the internal services or assets that are shipped with RStudio Connect.
User content is anything uploaded by a user (reports, Shiny applications,
Plumber APIs, etc.)
X-Frame-Options header value for user-uploaded content. By
default it is
NONE, meaning that the header will not be set. This allows
user-provided content to be embedded in iframes from any location. If you do
not intend for others to embed user content on their sites, you can set this
to a value of
SAMEORIGIN to ensure that only sites on the same server will
be able to embed your users' content. The RStudio Connect dashboard itself
uses iframes to present user content in the dashboard, so it is not
recommended to set this option to
X-Frame-Options header value for internal services and assets
provided with RStudio Connect and defaults to a value of
DENY. This means
that other sites will not be able to embed the RStudio Connect dashboard. This
setting is more secure in that it protects against clickjacking attacks
against the Connect dashboard, but if you plan to embed the dashboard
elsewhere you may need to tune this setting.
Some advertised values for this header are not supported across all browsers. RStudio Connect does not restrict the values of these headers.
RStudio Connect will return cookies with the attribute
SameSite=None by default.
This will allow content hosted by RStudio Connect to be displayed embedded in
iframes without additional options. With
SameSite=None, each cookie emitted by
RStudio Connect will have a secondary cookie with
-legacy suffix in its name
and without the
SameSite attribute. This second cookie is needed for additional
compatibility with some browsers (i.e. Safari 12).
If you don't intend to embed content hosted by Connect in an iframe and
your organization requires a more secure cookie setup you can configure the
Server.SameSite option with
Lax value as in the example below:
[Server] SameSite = "Lax"
If you need to include additional HTTP headers that are not covered by any of
the above features, you can include your own custom headers on all responses
from RStudio Connect using the
This feature can be used to accommodate various other security practices that are not explicitly available as options elsewhere in Connect. For instance, X-XSS-Protection, Content Security Policy (CSP), HTTP Public Key Pinning (HPKP), and Cross-origin Resource Sharing (CORS) could all be configured using custom headers.
Custom headers are added to the HTTP response early during request processing. Values may later be overwritten or modified by other header settings. This includes both the security preferences described earlier in this chapter and other headers used internally by RStudio Connect, by Plumber, or by Shiny. You should not depend on a custom header that conflicts with a header already in use by RStudio Connect.
Server.CustomHeader takes a value of the header name and its value
separated by a colon. Whitespace surrounding the header name and its value are
trimmed. You can use this setting multiple times as in the following example:
; /etc/rstudio-connect/rstudio-connect.gcfg [Server] CustomHeader = “HeaderA: some value” CustomHeader = “HeaderB: another value”
RStudio Connect records information about changes to the system. These events can later be retrieved for auditing purposes.
This table contains the event types logged by the auditing system:
||Create a user|
||Change an existing user|
||*Delete a user|
||Set or remove a lock for an existing user|
||Add new content|
||Upload a bundle for a content|
||Deploy content to the server. Content may need to be published after deployment.|
||Change content settings|
||Activate a token. Tokens are used by the
||Create a group|
||*Change an existing group|
||Delete a group|
||Add a user to a group|
||Remove a user from a group|
||Give a user view or edit access to content|
||Remove a user from view or edit access list|
||Give a group view or edit access to content|
||Remove a group from view or edit access list|
||Change from a specific list of viewers to "just me"|
||Add API key|
||*Change an existing API key|
||Remove API key|
||Add vanity URL|
||Update vanity URL|
||Remove vanity URL|
||Remove a bundle|
||Download a bundle|
||Create a tag/category|
||Delete a tag/category|
||Update a tag/category|
||Associate a tag with some parent tag/category|
||Associate a tag with content|
||Disassociate a tag with content|
||Change to application environment variables|
||A user has started a dashboard session|
||A user needed to re-authenticate for a privileged action after a WebSudo timeout|
The items marked with an asterisk can only be done via the
Audit Log File Output#
If you have a need for audited events to be written to a file, in a way
similar to RStudio Connect's access log, you can use the
options to control this.
configuration option can be set to
JSON. Setting it to
none disables echoing audit log entries to a file and is the default.
Setting it to
JSON will format audit log entries in CSV or JSON,
respectively, and write the formatted data to the file named by the
option is ignored if
none setting prevents recording auditing information to a log file on disk. The auditing system cannot be disabled and always records changes to the Connect database. These recorded operations are always available in the Audit Logs screen of the Connect dashboard and through the Connect Server API.
When formatting entries in CSV, fields are written in the following order:
The database ID of the audit log record.
The timestamp of the record, in RFC 3339.
The database ID of the user that performed the action.
The description of the user.
The action the user performed.
The description of the event.
When formatting entries in JSON, each text line written to the audit log file
will be a single, complete JSON object with the same data as for CSV with
RStudio will refuse to start if the specified audit log file already exists and has content that appears to contradict the requested entry format. In other words, if the file looks like it is in CSV format but the configuration requests JSON or looks like JSON and the configuration requests CSV, the server will not start.
The specification of the JSON object is the one used for Audit Logs in the Connect Server API.
Audit Logs Command-Line Interface#
usermanager CLI tool can produce the same output present in the audit
log file output with the flags
--jsonlog. Filtering by a time
interval is also possible. See the CLI appendix for more
information on using the
usermanager CLI to dump audit logs.
Application Environment Variables#
User-specified environment variables for applications are encrypted on-disk and in-memory. They are decrypted only when a process is about to be started.