RGPD et sécurité web ne sont pas des options pour les PME. Voici les garanties techniques concrètes à exiger de votre prestataire avant de signer un contrat.
En 2023, la CNIL a prononcé 42 sanctions pour un total de 89 millions d'euros d'amendes. Parmi elles, des PME condamnées pour des manquements techniques qui auraient coûté quelques jours de développement à corriger. La même année, l'ANSSI rapporte que les PME représentent plus de 40% des victimes de ransomwares en France. La sécurité web et la conformité RGPD ne sont plus des sujets réservés aux grandes entreprises — et les prestataires qui ne les prennent pas en compte font courir un risque réel et mesurable à leurs clients.
Pourquoi la sécurité web concerne les PME autant que les grandes entreprises ?
La surface d'attaque d'une PME est souvent plus large que celle d'une grande entreprise, proportionnellement à ses ressources de défense. Les attaques automatisées ne ciblent pas une entreprise en particulier — elles scannent des millions de sites à la recherche de vulnérabilités connues. Un CMS non mis à jour, un mot de passe par défaut non changé, une injection SQL dans un formulaire de contact : ces failles sont exploitables en quelques secondes par des outils automatisés.
Les conséquences pour une PME sont réelles :
- Amende CNIL : jusqu'à 4% du chiffre d'affaires mondial (article 83 du RGPD). Pour une PME à 5 M€ de CA, cela représente jusqu'à 200 000 €.
- Obligation de notification : toute violation de données personnelles doit être notifiée à la CNIL dans les 72 heures — et aux personnes concernées si le risque est élevé.
- Interruption de service : un ransomware ou une attaque DDoS peut paralyser le SI pendant des jours ou des semaines, avec des coûts opérationnels directs.
- Atteinte à la réputation : une fuite de données clients est difficilement réparable en termes de confiance — et désormais souvent publique.
Quelles sont les obligations RGPD pour une application web d'entreprise ?
Le RGPD impose des mesures techniques et organisationnelles proportionnelles aux risques. Pour toute application web traitant des données personnelles — formulaires clients, espaces membres, CRM, base prospects — ces obligations sont non négociables :
- Chiffrement des données sensibles : mots de passe hashés avec bcrypt ou Argon2 (jamais MD5 ni SHA1), données sensibles chiffrées au repos si leur exposition créerait un risque élevé
- Minimisation des données : ne collecter que ce qui est strictement nécessaire à la finalité déclarée, et supprimer après la durée de conservation définie
- Traçabilité des accès : journaux d'accès aux données personnelles, conservés et consultables en cas d'audit ou de violation
- Droit à l'effacement : capacité technique à supprimer toutes les données d'une personne sur demande — y compris dans les sauvegardes, ce qui implique une réflexion d'architecture
- Sécurisation des transferts : HTTPS obligatoire, pas de données sensibles en paramètre GET, headers HTTP sécurité configurés
- Registre des traitements : document interne listant chaque traitement de données, sa base légale, sa durée de conservation et ses destinataires
Ces obligations ne sont pas optionnelles. Elles s'appliquent dès le premier formulaire qui collecte un email. Un audit CNIL peut intervenir à la suite d'une plainte d'utilisateur, d'une notification de faille, ou d'un contrôle aléatoire.
Les 6 vulnérabilités OWASP les plus fréquentes dans les applications PME
L'OWASP (Open Web Application Security Project) publie le classement des vulnérabilités web les plus critiques. Voici les 6 plus fréquemment constatées dans les applications de PME, avec leurs impacts réels et les corrections techniques :
| Vulnérabilité | Impact concret | Correction Symfony |
|---|---|---|
| Injection SQL | Lecture ou destruction complète de la base de données | ORM Doctrine paramétré — jamais de requête SQL construite avec des variables non filtrées |
| Authentification défaillante | Accès non autorisé à des comptes administrateurs ou clients | Symfony Security Component, hashage Argon2, 2FA pour les accès sensibles |
| XSS (Cross-Site Scripting) | Exécution de scripts malveillants dans le navigateur des utilisateurs | Échappement automatique Twig, Content Security Policy headers |
| CSRF (Cross-Site Request Forgery) | Actions frauduleuses effectuées au nom d'un utilisateur authentifié | Token CSRF Symfony sur tous les formulaires de soumission |
| Exposition de données sensibles | Fuite de mots de passe, coordonnées clients, données financières | HTTPS strict, Argon2, headers sécurité (HSTS, X-Content-Type-Options) |
| Contrôle d'accès cassé | Un utilisateur A accède aux données d'un utilisateur B | Voters Symfony, vérification d'ownership systématique dans chaque use case |
Ce que votre prestataire web doit garantir contractuellement
Un contrat de développement web qui ne couvre pas la sécurité est un contrat qui transfère implicitement tous les risques au client. Ces points doivent être explicitement mentionnés :
Les garanties techniques minimales
- HTTPS activé par défaut dès la mise en production, sans exception
- Aucune donnée sensible stockée en clair — mots de passe, numéros de carte, données médicales
- Protection CSRF active sur tous les formulaires de soumission
- Mises à jour de sécurité des dépendances incluses dans la maintenance (CVE critiques traitées sous 72h)
- Logs d'accès conservés et accessibles au client sur demande
- Headers HTTP sécurité configurés sur le serveur de production
Les garanties RGPD
- Contrat de sous-traitance RGPD (DPA — Data Processing Agreement) signé si le prestataire traite des données personnelles
- Hébergement en Union Européenne clairement spécifié dans le contrat
- Procédure de notification de faille définie : délai de détection, canal de communication, responsabilités
- Capacité technique à satisfaire les droits des personnes : accès, rectification, effacement, portabilité
- Pas d'utilisation des données client à d'autres fins que la mission
Un prestataire qui refuse de signer un DPA ou qui est incapable de décrire ses mesures de sécurité concrètes est un signal d'alarme. Les bons prestataires ont ces réponses prêtes — parce qu'ils les appliquent déjà.
Les configurations serveur souvent négligées
La sécurité d'une application web ne dépend pas que du code. La configuration du serveur et du reverse proxy compte autant :
- HSTS (HTTP Strict Transport Security) : force le navigateur à toujours utiliser HTTPS, même si l'utilisateur tape l'URL en HTTP
- CSP (Content Security Policy) : déclare les sources autorisées pour les scripts, styles et images — bloque les injections XSS
- X-Frame-Options : empêche l'intégration de la page dans une iframe frauduleuse (clickjacking)
- Fail2ban : bloque automatiquement les IP après N tentatives d'authentification échouées
- Séparation des environnements : le
APP_ENV=devne doit jamais être actif en production — il expose le Symfony profiler et les stack traces complètes
Comment KSolution sécurise ses développements Symfony
Sur tous les projets KSolution, une checklist sécurité est appliquée à chaque mise en production : Symfony Security Component configuré avec voters par entité, tokens CSRF actifs sur tous les formulaires, headers HTTP sécurité (HSTS, CSP, X-Frame-Options, Permissions-Policy), hashage Argon2 pour les mots de passe, et audit des dépendances avec symfony security:check avant chaque déploiement.
Les données personnelles sont isolées dans le code source avec leur durée de conservation documentée. PHPStan au niveau 9 détecte les incohérences de types qui peuvent masquer des failles avant que le code n'arrive en production. Chaque projet inclut un DPA signé et une documentation des traitements RGPD.
Audit sécurité : comment évaluer l'exposition de votre application actuelle ?
Si votre application web tourne depuis plus de 2 ans sans audit de sécurité, elle présente statistiquement des vulnérabilités — dépendances avec CVE connues non patchées, configuration serveur par défaut, fonctionnalités développées avant que les standards RGPD ne soient appliqués.
Un audit de sécurité couvre en général : les dépendances obsolètes (CVE publics), la configuration du serveur web et PHP, les failles applicatives OWASP Top 10, et la conformité RGPD des traitements en place. Sur une application Symfony de taille moyenne, cela prend entre 2 et 4 jours et produit un rapport priorisé — du critique à corriger cette semaine au mineur à planifier dans le prochain sprint.
Pour évaluer l'exposition de votre application, contactez KSolution pour un audit de sécurité — le rapport inclut les corrections concrètes, pas seulement la liste des problèmes.
