Points clés
- Les applications internes bénéficient d'une attention sécurité systématiquement inférieure aux applications exposées publiquement — alors qu'elles traitent souvent des données plus sensibles.
- Les erreurs les plus répandues : injection SQL, gestion d'erreurs inadéquate, absence de contrôle d'accès au niveau objet, secrets codés en dur dans le code source.
- Le développement en mode "MVP rapide" dans les équipes métier crée des applications sans équipe sécurité impliquée et sans cycle de vie formel.
- Les bibliothèques et frameworks tiers non mis à jour constituent une dette de sécurité croissante dans la quasi-totalité des codebases en production.
Le paradoxe des applications internes
Les applications internes — outils de reporting, portails RH, applications de gestion métier développées en interne — bénéficient souvent d'une attention sécurité bien inférieure aux applications exposées publiquement. Ce paradoxe est contre-intuitif : ces applications traitent souvent des données plus sensibles (données employés, données financières internes, informations stratégiques) et leurs vulnérabilités sont exploitables par tout attaquant ayant obtenu un accès initial au réseau interne.
L'hypothèse sous-jacente — "c'est interne, donc c'est protégé par le périmètre réseau" — est invalidée par deux évolutions : la compromission du périmètre est régulièrement réalisée via le phishing ou la compromission de comptes utilisateurs, et le modèle Zero Trust remet en question la notion même de réseau interne de confiance. Une application interne vulnérable est un vecteur de propagation latérale et d'élévation de privilèges pour un attaquant ayant franchi le périmètre.
Les vulnérabilités les plus fréquemment observées
L'injection SQL reste la vulnérabilité la plus fréquemment identifiée dans les applications internes lors des audits, malgré des années de sensibilisation. Elle résulte d'une construction de requêtes SQL par concaténation de chaînes incluant des entrées utilisateur non validées — une pratique que les ORM modernes et les requêtes paramétrées éliminent, mais qui persiste dans les applications développées avant leur généralisation ou par des développeurs non sensibilisés.
L'absence de contrôle d'accès au niveau objet (Broken Object Level Authorization — BOLA dans l'OWASP API Top 10) est une autre erreur structurelle fréquente : une application vérifie que l'utilisateur est authentifié mais ne vérifie pas s'il est autorisé à accéder à l'objet spécifique qu'il demande (un autre utilisateur, un document appartenant à une autre entité). Cette vulnérabilité permet l'accès non autorisé à des ressources en modifiant simplement un identifiant dans l'URL ou la requête API.
Les secrets dans le code source
La présence de secrets (clés API, credentials de bases de données, tokens d'authentification) codés en dur dans le code source est l'une des erreurs les plus communes et les plus impactantes. Elle résulte de la commodité du développement — stocker un credential dans le code pour ne pas avoir à configurer un gestionnaire de secrets — et de l'absence de contrôles automatiques dans les pipelines de déploiement.
Des outils de détection de secrets dans le code (GitLeaks, TruffleHog, git-secrets, Semgrep) permettent de scanner les dépôts pour identifier ces expositions. Ces outils doivent être intégrés dans les hooks pre-commit et les pipelines CI/CD pour détecter les secrets avant qu'ils atteignent le dépôt. La gestion des secrets doit être déléguée à des solutions dédiées (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et les variables d'environnement ne doivent pas être substituées au code mais documentées dans les procédures de déploiement.
Le shadow development et les applications métier non gouvernées
Le développement d'applications métier par les équipes non-IT — via des outils low-code/no-code, des scripts Python ou R développés par des data scientists, des automatisations Power Automate — crée un "shadow development" analogue au shadow IT. Ces applications traitent souvent des données sensibles, sont rarement soumises à des revues de sécurité, et ne bénéficient d'aucun cycle de vie formel (mise à jour des dépendances, tests de sécurité, procédure de décommissionnement).
La gouvernance du développement applicatif doit donc couvrir ce périmètre, avec une approche proportionnée à la sensibilité des données traitées plutôt qu'une interdiction systématique qui ne ferait que rendre ces développements encore moins visibles.