Chapter 17 Safety
Part of scaling is exposing your app to more people, including people that you don’t fully trust. This chapter discusses some of the things you need to think about if you’re going to create a public facing app. (If you’re only using your app inside your company this chapter isn’t so important as you can generally assume that your own colleages won’t deliberately attempt to hack your code).
Key idea is what you can trust. Never trust anything supplied by the user - constant variables, not code.
Places where that might surprise you:
- Creating glue strings
- Reading yaml
- Allowing the user to supply transformation expressions for dplyr or ggplot2.
Also note that Shiny input controls provide client-side validation - a malicious user can avoid this by running code in their browser console. For untrusted input, always do client side validation too.
Shiny.setInputValue(id, value);; if that was prevented could still craft a custom websocket message. Each change would make it harder for a lay person to break Shiny’s security, but would provide little barrier for an experienced attacker.
Don’t put passwords in code. Instead use
config.ymlor env vars.
If implementing bookmarkable state, make sure you’re not putting any
confidential data in the URL.
Cached plots shared across users by default.