Passer le site en HTTPS empêche-t-il les injections SQL et le XSS ?
Réponse courte
Non. HTTPS chiffre le canal pour que les attaquants ne puissent ni lire ni altérer le trafic en transit, mais l'entrée malveillante arrive, est déchiffrée et traitée par votre application exactement comme avant. L'injection SQL et le XSS sont des failles applicatives corrigées par des requêtes paramétrées et l'encodage de sortie, pas par le chiffrement du transport. L'erreur suppose que le chiffrement assainit le contenu — il ne le fait pas ; l'attaquant envoie simplement la charge via la connexion HTTPS.
« On est en HTTPS maintenant, donc on est sécurisés » est l'un des mythes les plus tenaces de la sécurité web. HTTPS est essentiel, mais il résout un problème totalement différent de l'injection. Cette question vérifie si un candidat sait placer un contrôle à la bonne couche.
Ce qu'HTTPS fait réellement
TLS (le S de HTTPS) apporte trois choses sur le chemin réseau : la confidentialité (les espions ne peuvent lire le trafic), l'intégrité (il ne peut être modifié silencieusement en transit) et l'authentification du serveur. Cela déjoue les attaques de l'homme du milieu, le reniflage de paquets sur un Wi-Fi hostile et le vol d'identifiants sur le réseau. C'est un contrôle de couche transport. Il ne dit rien sur la sûreté du traitement des données contenues dans la requête.
Pourquoi l'injection reste intacte
L'injection SQL et le XSS sont des failles de la couche applicative. L'attaquant soumet une entrée comme ' OR 1=1 -- ou <script>...</script> via un formulaire ou un appel d'API parfaitement normal. En HTTPS, cette charge est chiffrée du navigateur au serveur, puis déchiffrée au serveur et remise à votre code exactement comme une valeur bénigne. Si votre code la concatène dans une chaîne SQL, l'injection se déclenche ; s'il la réfléchit dans du HTML sans encodage, le script s'exécute dans le navigateur de la victime. Le chiffrement protège la charge des tiers — il n'empêche pas l'application de la mal traiter. L'idée qu'une charge chiffrée « ne peut atteindre la base » inverse l'architecture.
Les défenses correctes
Corrigez l'injection là où elle vit, dans le code :
- Injection SQL : utilisez des requêtes paramétrées / préparées pour que l'entrée soit toujours traitée comme donnée, jamais comme SQL exécutable. Ajoutez des comptes de base à moindre privilège.
- XSS : appliquez un encodage de sortie contextuel au rendu des données utilisateur, validez l'entrée et déployez une Content-Security-Policy en défense en profondeur.
HTTPS et ces contrôles sont complémentaires, pas substituables. Déployez les deux. À retenir : HTTPS sécurise le tuyau ; les requêtes paramétrées et l'encodage de sortie sécurisent le traitement. Couches différentes, bugs différents.
Questions de suivi probables
- Qu'est-ce qui corrige réellement l'injection SQL au niveau du code, et pourquoi ça marche ?
- Quelle défense traite le XSS, et comment la Content-Security-Policy la renforce-t-elle ?
- Citez une classe d'attaque qu'HTTPS empêche réellement.