Pierrot s’est fait pirater

Sécuriser ses applications Shiny

🔗 arthurdata.github.io/rencontresR2026

2026-06-16

Bonjour

Il y a 3 ans…

Aux 🔗 Rencontres R 2023, Pierrot maquettait son application Shiny.

La cuisine se dessine.

Il y a 1 an…

Aux 🔗 Rencontres R 2025, Pierrot testait son application Shiny.

La cuisine est solide : tiroirs testés, modules emboîtés, repas cuisiné.

Pierrot 2026

Pierrot est fier

Son application est maquettée.

Elle est testée.

Elle est en production chez son client.

Tout va bien.

… jusqu’à ce matin

Le coup de fil

📞 “Pierrot, on a un gros problème avec l’app…”

> Vous avez été piratés.

La cuisine cambriolée

La belle cuisine de Pierrot…

La porte forcée

Les tiroirs vidés

Le coffre-fort ouvert

Les craintes de Pierrot…

Ce qu’il avait prévu

✅ Mal montée

✅ Pas robuste

✅ Mal testée

Ce qu’il avait oublié

❓ Cambriolée

Pierrot n’avait pas pensé à…

… la sécurité 🔐

La sécurité fait partie du métier

Au même titre que :

✅ Les tests

✅ La documentation

Pas réservée aux experts en cybersécurité. C’est notre métier de dev.

Bonne nouvelle : Shiny est bien foutu

🔗 shiny::runApp("security/apps/reprex1")

Inputs ≈ strings.

On tape :

<script>alert()</script>

✅ Pas d’évaluation = safe.

Mauvaise nouvelle

🔗 shiny::runApp("security/apps/reprex2")

Une seule diff : HTML(input$message) au lieu de input$message.

On tape :

<script>alert()</script>

💥 le script s’exécute.

🐛 Faille XSS

L’injection de code

Le principe : injecter du code malveillant qui sera ensuite exécuté par l’application.

3 grandes familles

🐛 XSS (Cross-Site Scripting) : côté navigateur (client)

🐛 Command Injection : côté serveur

🐛 SQL Injection : côté base de données

Le point commun : exploiter l’absence de validation des données utilisateur.

Command Injection

Command Injection

Du code R exécuté côté serveur

Une saisie utilisateur depuis l’interface…

…Évaluée par l’application…

➜ N’importe qui peut exécuter du code R sur votre serveur.

Lecture de fichiers, accès au système, exfiltration de secrets

Command Injection — Reprex safe

🔗 shiny::runApp("security/apps/reprex3")

glue("Ton choix est : {input$xyz}")

On tape :

Hello {1+1}

L’input reste une string, jamais évaluée comme du code.

✅ Pas d’évaluation = safe.

La feature évolue…

🔗 shiny::runApp("security/apps/reprex4")

glue(input$xyz)

L’input est traité comme du code à interpréter, plus comme du contenu.

On rajoute les accolades :

Hello {1+1}

→ Hello 2.

💥 L’input est évalué comme du code.

Démo offensive

🔗 shiny::runApp("security/apps/reprex4")

{system("ls /")}
{readLines("/etc/passwd")}
{system("whoami")}
{system("rm -rf /")}
{system("useradd hacker")}

…oups 🙊

Pourquoi c’est sournois

glue(input$template) ≈ eval(parse(text = input$template))

Mais glue() est plus discret car il évalue automatiquement ce qu’il y a entre {}.

🥇 Bonne pratique #1

Figer le template :

glue("{input$template}")

“Mais j’ai un selectInput !”

🔗 shiny::runApp("security/apps/reprex5")

selectInput → 3 choix uniquement… côté UI.

Console navigateur :

Shiny.setInputValue("color", "{1+1}")

💥 selectInput contourné.

🥇 Bonne pratique #2

Valider côté serveur

input_color <- match.arg(
  input$color,
  choices = c("red", "green", "blue")
)

Ou via switch() / if selon le besoin.

Toute donnée venant du client doit être validée serveur-side. Toujours.

Insecure Deserialization

🔗 shiny::runApp("security/apps/reprex6")

Un .rds généré par l’attaquant :

evil <- function() {
  system("touch /tmp/hacked")
}
saveRDS(evil, "evil.rds")

Du code s’exécute à l’utilisation de l’objet, pas à readRDS().

💥 Code attaquant exécuté côté serveur.

🥇 Bonne pratique #3

Privilégier des formats simples

✅ .csv, .txt, .json — du contenu, pas du code sérialisé.

🛡️ Si vraiment besoin d’un .rds : sandbox.

(callr, processx en environnement restreint, container…)

Règle n°1

Ne fais jamais confiance à l’entrée utilisateur, quel que soit le contexte.

SQL Injection

SQL Injection

🔗 shiny::runApp("security/apps/reprex7")

paste0("SELECT … WHERE id = ", input$x)

Tape 1 ➜ Robert ✅

Tape 1 OR 1=1 ➜ toute la table 💥

Démos offensives

1 OR 1=1

Fuite : on récupère toutes les lignes de la table.

1; DROP TABLE users

Destruction : selon le driver, la table disparaît.

“Mais j’ai un selectInput !” (bis)

🔗 shiny::runApp("security/apps/reprex8")

selectInput → 5 IDs uniquement… côté UI.

Console navigateur :

Shiny.setInputValue("user_input", "1 OR 1=1")

💥 Même fuite, malgré le selectInput.

🥇 Bonne pratique #4

❌ Avant

rv$query <- paste0(
  "SELECT * FROM users WHERE id = ",
  input$user_input
)
rv$result <- dbGetQuery(
  con, rv$query
)

✅ Avec sqlInterpolate

rv$query <- sqlInterpolate(
  con,
  "SELECT * FROM users WHERE id = ?id",
  id = input$user_input
)
rv$result <- dbGetQuery(
  con, rv$query
)

Même attaque 1 OR 1=1 ➜ requête vide, table intacte.

🥇 Bonne pratique #4

❌ Avant

rv$query <- paste0(
  "SELECT * FROM users WHERE id = ",
  input$user_input
)
rv$result <- dbGetQuery(
  con, rv$query
)

✅ Ou avec glue_sql

rv$query <- glue_sql(
  "SELECT * FROM users WHERE id = {input$user_input}",
  .con = con
)
rv$result <- dbGetQuery(
  con, rv$query
)

📖 shiny.posit.co/r/articles/build/sql-injections/

XSS

XSS : Cross-Site Scripting

Du code JS exécuté côté navigateur

L’attaquant injecte du code dans une page…

…stocké côté serveur ou simplement reflété…

➜ exécuté chez tous les visiteurs qui consultent la page.

XSS : Un mur de commentaires

🔗 shiny::runApp("security/apps/reprex11")

Pierrot poste un message :

Salut tout le monde !

Tout fonctionne ✅

XSS : Un attaquant arrive

🔗 shiny::runApp("security/apps/reprex11")

Un autre poste :

<script>alert(...)</script>

💥 Alert chez tous les visiteurs.

Et à chaque rechargement : ça repart.

XSS : Le vrai vol

🔗 shiny::runApp("security/apps/reprex11")

L’attaquant raffine :

<script>
  ...createElement("button")...
  fakeBtn.onclick = ...
  document.body.prepend(fakeBtn);
</script>

💥 Faux bouton de connexion pour tous.

➜ Vol silencieux des credentials.

🥇 Bonne pratique #5

Échapper le contenu utilisateur avec htmltools::htmlEscape()

❌ Avant

glue::glue(
  "<p><strong>{row$pseudo}</strong>",
  " : {row$message}</p>"
)

✅ Après

glue::glue(
  "<p><strong>{htmlEscape(row$pseudo)}</strong>",
  " : {htmlEscape(row$message)}</p>"
)

Le <script> devient du texte affiché, pas exécuté.

À appliquer sur tout contenu utilisateur : pseudo et message.

La cuisine sécurisée de Pierrot

La cuisine sécurisée de Pierrot

Les 3 portes à fermer

🐛 Command Injection : jamais évaluer un input

🐛 SQL Injection : sqlInterpolate() ou glue_sql(), toujours

🐛 XSS : htmlEscape() tout ce qui s’affiche

🔐 Et la règle n°1 : ne jamais faire confiance à l’utilisateur

Et tout ce qu’on n’a pas eu le temps de voir

🔑 L’authentification : shinymanager, Posit Connect, OAuth… C’est un autre sujet, mais essentiel.

📦 Les dépendances à jour : pas de Dependabot natif en R.

Mise à jour régulière, surveillance manuelle des annonces upstream des paquets critiques.

Pour aller plus loin

S’entraîner

🔗 connect.thinkr.fr/hackthisshiny/

Lectures

🔗 shiny.posit.co/r/articles/build/sql-injections/

🔗 OWASP — XSS Prevention Cheat Sheet

🔗 vuejs.org/guide/best-practices/security

Merci

Des questions ?

🔗 arthurdata.github.io/rencontresR2026

Pierrot vous remercie.