R Shiny Application Security Review

By default a Shiny app runs inside one R process, and any object created outside the server function belongs to that whole process, not to the one visitor who triggered it.

Why a Shiny session is only private if your code makes it that way

Shiny scopes objects by where you define them. Anything created inside your app’s server function is visible only within that one browser session, but a value or function defined in app.R outside server, or in global.R, is created once and then shared with every session running in the same R process, under Shiny’s own scoping rules. How many sessions actually land on that one process is a hosting decision: the Open Source edition of Shiny Server ships with only the Simple Scheduler, which binds a single R process to the whole app up to a configured number of concurrent connections, so every visitor shares whatever that process holds until a Pro-only multi-process scheduler, or an equivalent setting on Posit Connect or shinyapps.io, spreads sessions across more than one.

Shiny itself has no login screen, so who can reach the app depends entirely on whatever sits in front of it. A self-hosted instance running Shiny Server Professional can gate access with PAM or Kerberos, a flat-file username and password list, Google authentication, or proxied authentication, where an upstream proxy sets a username header that Shiny Server is configured to trust. Deployed on Posit Connect instead, the same app can sit behind SAML, OpenID Connect, LDAP or Active Directory, PAM, Kerberos, Connect’s own proxied authentication, or a built-in password system. shinyapps.io keeps this simpler again: an app’s Visibility is either Public or Private, and a Private app only admits the specific email addresses you invite, who then sign in with a Google, GitHub or shinyapps.io account.

What a session takes in matters as much as who reaches it. fileInput() hands your server a temporary file referenced by datapath, alongside the browser-reported name, size and MIME type, and that temp file can already be gone once the same user uploads again, so anything you need from it has to be read immediately. Shiny’s own security guidance is to keep a password or API key out of your source code entirely, in an environment variable or the config package instead, and never in version control. renderUI() writes reactive HTML back into the page, and every Shiny tag function escapes what you give it by default, unless the content is wrapped in HTML(), which switches that escaping off for whatever it is handed.