Sécurité web : les bases que 80 % des sites ignorent encore

La sécurité web a mauvaise réputation : on l'imagine complexe, réservée aux grandes entreprises, pertinente uniquement si on gère des données bancaires. C'est une erreur de perception qui coûte cher. En 2025, les attaques automatisées ne ciblent pas les grandes entreprises en priorité — elles ciblent les sites les plus faciles à compromettre, c'est-à-dire ceux qui ignorent les bases.

Le constat — La sécurité web, c'est d'abord de la négligence#

La grande majorité des incidents de sécurité sur des sites PME ne sont pas le résultat d'attaques sophistiquées. Ils résultent d'oublis basiques, de configurations par défaut non modifiées, et de dépendances non maintenues.

Voici ce qu'on retrouve en audit sur la plupart des sites existants :

• Pas de HTTPS ou HTTPS mal configuré. HTTPS sans forçage de la redirection HTTP → HTTPS, certificats expirés, ou protocoles obsolètes (TLS 1.0, TLS 1.1).
• Aucun en-tête de sécurité HTTP. La configuration par défaut des serveurs web n'inclut pas les headers de sécurité. Ces quelques lignes de configuration sont pourtant déterminantes.
• Formulaires vulnérables aux XSS. Les inputs utilisateur non échappés avant affichage permettent à un attaquant d'injecter du JavaScript dans la page — et potentiellement de voler les sessions des visiteurs.
• Requêtes SQL non paramétrisées. L'injection SQL reste l'une des failles les plus exploitées depuis 20 ans. Elle est pourtant évitable avec des pratiques de développement élémentaires.
• Accès admin sans MFA. Un mot de passe seul sur l'interface d'administration, c'est un vecteur d'attaque brut.

Google pénalise désormais explicitement les sites non sécurisés dans Chrome (indicateur "Non sécurisé" dans la barre d'adresse) et la sécurité est un critère de classement indirect via les Core Web Vitals et les signaux de confiance.

La solution — La checklist des fondamentaux#

1. HTTPS obligatoire partout

Toutes les pages, sans exception, doivent être servies en HTTPS. La redirection automatique de HTTP vers HTTPS doit être configurée côté serveur, pas seulement côté CMS. Le certificat TLS doit être en version 1.2 minimum (TLS 1.3 recommandé). Les certificats Let's Encrypt sont gratuits et renouvelables automatiquement — il n'y a aucune raison de ne pas les utiliser.

2. Les headers de sécurité essentiels

Ces en-têtes HTTP sont envoyés par votre serveur à chaque réponse. Ils indiquent au navigateur comment se comporter face à certains risques :

• Strict-Transport-Security (HSTS) : force le navigateur à n'utiliser que HTTPS pour votre domaine, même si l'utilisateur tape "http://"
• X-Content-Type-Options: nosniff : empêche le navigateur de deviner le type MIME d'un fichier (vecteur d'attaque méconnu)
• X-Frame-Options: DENY : empêche votre site d'être intégré dans une iframe (clickjacking)
• Referrer-Policy : contrôle quelles informations de navigation sont partagées lors des clics sur des liens
• Permissions-Policy : restreint l'accès aux APIs sensibles du navigateur (caméra, micro, géolocalisation) aux seules pages qui en ont besoin

3. Content Security Policy (CSP)

La CSP est l'outil le plus puissant contre les attaques XSS. Elle permet de déclarer explicitement quelles sources de scripts, styles, images et iframes sont autorisées sur votre site. Tout ce qui ne correspond pas à la politique est bloqué par le navigateur, même si un attaquant a réussi à injecter du code.

Une CSP bien configurée ressemble à ceci dans vos headers :

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xxx'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;

La CSP demande un paramétrage minutieux selon les dépendances de votre site (Google Analytics, polices tierces, widgets). Mal configurée, elle peut bloquer des ressources légitimes. Bien configurée, elle élimine la majorité des vecteurs XSS.

4. Protection contre les injections SQL

L'injection SQL consiste à insérer du code SQL dans un champ de formulaire pour manipuler la base de données. La protection est simple : n'utiliser que des requêtes paramétrées (prepared statements) ou un ORM qui les génère automatiquement. Ne jamais concaténer directement des inputs utilisateur dans une requête SQL.

5. Validation côté serveur

La validation côté client (dans le navigateur) est utile pour l'expérience utilisateur, mais ne constitue aucune protection. N'importe qui peut désactiver le JavaScript ou envoyer des requêtes directement à votre serveur. Toute validation de données doit être faite côté serveur, avant tout traitement ou stockage.

Checklist rapide : HTTPS actif et forcé ✓ → Headers de sécurité configurés ✓ → CSP en place ✓ → Requêtes paramétrées ✓ → Validation serveur ✓ → MFA sur l'admin ✓. Si votre site coche ces six points, vous avez éliminé 80 % des vecteurs d'attaque courants.

Notre approche chez Webomax#

Sur chaque projet Next.js que nous livrons, la sécurité est configurée par défaut et non en option :

• Headers de sécurité dans next.config.js : HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy sont systématiquement inclus.
• CSP adaptée à chaque projet : on définit la politique selon les ressources réellement utilisées, et on la teste avant mise en production avec le mode Content-Security-Policy-Report-Only.
• Supabase comme backend : les requêtes passent par le SDK Supabase qui utilise des requêtes paramétrées et Row Level Security — l'injection SQL est structurellement impossible.
• Variables d'environnement pour toutes les clés et secrets, jamais exposées dans le code source.
• Audit avant livraison avec securityheaders.com et Mozilla Observatory — on vise un score A ou A+.

Un site bien construit est aussi un site sécurisé. Ces pratiques ne ralentissent pas le développement — elles font partie du standard. Découvrez comment nous construisons des sites web performants et sécurisés.

Ce qu'il faut retenir#

La sécurité web n'est pas réservée aux banques et aux grandes plateformes. Les fondamentaux sont accessibles, documentés, et souvent gratuits à mettre en place :

• HTTPS est le minimum absolu — et il est gratuit
• Les headers de sécurité se configurent en quelques lignes et ont un impact immédiat
• La CSP est l'arme la plus efficace contre les XSS
• Les injections SQL s'évitent avec des pratiques de développement standard
• La validation côté serveur n'est pas optionnelle

Si vous ne savez pas si votre site est correctement sécurisé, testez-le sur securityheaders.com maintenant. Vous aurez votre réponse en 10 secondes.