Upload de fichiers dans un SIRH : guide de sécurisation pratique
Pourquoi l'upload est un point critique dans les SaaS RH
Un SIRH ou un logiciel de paie manipule énormément de fichiers :
Chacun de ces fichiers est une porte d'entrée potentielle si l'upload n'est pas correctement sécurisé.
Les attaques classiques
Exécution de code
L'attaquant upload un fichier PHP, JSP ou un script déguisé en image. Si le serveur l'exécute, l'attaquant prend le contrôle. C'est la base, mais on la retrouve encore sur des applications en production.
Stored XSS via SVG
Un fichier SVG peut contenir du JavaScript. Si votre application affiche le SVG uploadé dans le navigateur d'un autre utilisateur, le script s'exécute dans son contexte — vol de session, exfiltration de données.
Path traversal
L'attaquant manipule le nom du fichier pour écraser des fichiers système : ../../../etc/passwd ou ../../config/database.yml. Si votre backend utilise le nom de fichier tel quel, c'est exploitable.
Déni de service
Upload d'un fichier de 10 Go quand la limite n'est pas configurée. Ou upload d'un zip bomb (un fichier compressé de quelques Ko qui se décompresse en plusieurs Go).
Le guide de sécurisation
1. Validez le type MIME côté serveur
Ne vous fiez pas à l'extension. Vérifiez le contenu réel du fichier (magic bytes). Un fichier .jpg qui commence par <?php n'est pas une image.
2. Renommez systématiquement
Ne conservez jamais le nom de fichier original. Générez un UUID et stockez le nom original en base de données, séparément.
3. Stockez hors du webroot
Les fichiers uploadés ne doivent jamais être servis directement par le serveur web. Stockez-les sur un service externe (S3, GCS, Supabase Storage) et servez-les via des URLs signées avec expiration.
4. Limitez la taille
Configurer une limite de taille au niveau de :
5. Scannez les fichiers
Pour les applications qui manipulent des données sensibles (paie, RH), un scan antivirus sur les fichiers uploadés est recommandé. ClamAV est open source et s'intègre facilement.
6. Contrôlez l'accès
Chaque fichier doit être associé à une organisation. L'URL de téléchargement doit vérifier que l'utilisateur a le droit d'accéder au fichier. Les URLs publiques non expirantes sont à proscrire.
7. Journalisez
Qui a uploadé quoi, quand, depuis quelle IP. En cas d'incident, ces logs sont essentiels.
Ce que CleanIssue vérifie
Lors d'un Audit complet, on teste systématiquement les fonctionnalités d'upload : type de fichiers acceptés, comportement avec des fichiers malveillants, accès entre organisations, URLs de téléchargement. C'est l'un des vecteurs les plus fréquemment exploitables sur les SaaS RH qu'on audite.
Pour aller plus loin
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
MFA dans les SaaS RH : pourquoi 62 % des éditeurs français n'y sont pas encore
L'authentification multi-facteurs est un standard. Pourtant, la majorité des SaaS RH français ne la proposent pas à leurs utilisateurs. Analyse des freins et solutions.
Zero Trust pour une petite équipe SaaS : par où commencer
Le Zero Trust n'est pas réservé aux grands groupes. Voici comment une équipe de 5 à 30 personnes peut appliquer les principes du Zero Trust sans infrastructure lourde.
Supabase RLS : les 5 erreurs qu'on retrouve dans chaque audit de SaaS RH
Les Row Level Security policies de Supabase sont puissantes mais trompeuses. Voici les erreurs les plus fréquentes qu'on rencontre lors de nos audits d'applications RH.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.