# Serveur Web Webship : Paramètres sécurisés par défaut
Un serveur web sécurisé ne devrait pas dépendre du fait qu'un opérateur se souvienne d'un réglage supplémentaire à 2 heures du matin. Il devrait partir d'une configuration de base protectrice, rejeter les configurations non sûres et exiger des choix délibérés avant d'exposer des fonctionnalités sensibles.
C'est le modèle derrière Webship. Sa configuration par défaut active les principales défenses de requête et de réponse, limite les ressources qu'un attaquant peut consommer, et laisse les surfaces de contrôle optionnelles désactivées. Vous pouvez ajuster ces paramètres par défaut pour une application réelle, mais vous n'avez pas à découvrir chaque protection avant l'arrivée de la première requête.
Sécurisé par défaut ne signifie pas sécurisé sans contexte. Les certificats, l'autorisation des applications, la politique réseau, les secrets et la réponse aux incidents relèvent toujours de l'opérateur. Le rôle de Webship est de rendre le point de départ sûr évident—et de rendre l'affaiblissement accidentel plus difficile.
Les protections qui commencent activées
Webship permet six couches dans sa configuration de base :
| Couche | Comportement par défaut | Ce qu'elle réduit | | --- | --- | --- | | Protection des fichiers point | Refuse les segments de chemin statiques préfixés par un point | Exposition accidentelle des fichiers d'environnement, des métadonnées du dépôt et de la configuration locale | | Pare-feu d'application Web | Bloque les modèles d'attaque connus | Injection SQL, script intersites (XSS), traversée, sondes de chemins sensibles, injection de commandes, falsification d'en-têtes et encodages de requêtes non pris en charge | | Contrôles DDoS | Fonctionne en mode normal avec un état client limité | Inondations de requêtes, suivi illimité et épuisement de ressources évitable | | Défi du bot | Utilise un cookie de défi signé | Abus automatisé à faible coût et balayage répété | | En-têtes de sécurité de réponse | Ajoute une politique restrictive pour le navigateur | Confusion MIME, encadrement, fuite de réferrer, capacités dangereuses du navigateur et chargement large de contenu | | Bouclier API | Utilise le mode blocage et rejette les routes inconnues une fois qu'un contrat API est défini | Points de terminaison fantômes, méthodes non prévues, types de contenu inattendus et exigences d'autorisation manquantes |
Le WAF par défaut place également des limites strictes autour de ce qu'il inspecte : 32 KiB d'en-têtes de requête, un chemin de 2 048 octets et un corps de requête de 1 MiB. Ce sont des limites de sécurité, et non des commutateurs de performance arbitraires. Si une application a légitimement besoin de requêtes plus volumineuses, augmentez la limite pertinente pour cette application et testez le résultat au lieu de désactiver l'inspection globalement.
La protection DDoS commence en mode normal à 600 requêtes par minute avec une tolérance de rafale de 100 par clé client. Sa table d’état des clients est limitée à 65 536 entrées. Ces valeurs sont une référence, et non un modèle de trafic universel : une API publique, un service de téléchargement et un panneau d’administration interne ne devraient pas partager les mêmes limites spécifiques à l’application.
Les protections du navigateur font partie du niveau de base
La politique d’en-tête de réponse de Webship est activée même lorsqu’une application oublie d’ajouter la sienne. La valeur par défaut inclut :
- X-Content-Type-Options : nosniff;
- une politique de refus de cadre
- Referrer-Policy : no-referrer ;
- Strict-Transport-Security pendant un an, y compris les sous-domaines ;
- Politique de sécurité du contenu limitée au contenu de la même origine, avec des restrictions de cadrage et d'URI de base ;
- Politique de permissions désactivant l'accès à la géolocalisation, au microphone et à la caméra.
Ces paramètres par défaut sont intentionnellement restrictifs. Examinez HSTS avant de l'appliquer à un domaine avec des sous-domaines qui ne sont pas entièrement prêts pour HTTPS. Examinez la politique de sécurité du contenu (Content-Security-Policy) avant qu'une application ne charge des scripts, des styles, des polices, des images ou des connexions provenant d'autres origines. Une configuration sécurisée par défaut doit échouer de manière visible lors du déploiement, et non être affaiblie silencieusement en production.
Les surfaces optionnelles restent fermées
Webship n'expose pas toutes les fonctionnalités simplement parce que le binaire les contient. Le proxy inverse, WebTransport, les points de terminaison d'observabilité, le TLS automatique, la provenance des réponses et le point de contrôle MCP sont désactivés par défaut.
Le point de terminaison MCP est limité à la boucle locale lorsqu'il est activé et nécessite une configuration de sécurité explicite. Les métriques et les statistiques nécessitent que l'instrumentation soit activement activée. La gestion automatique des certificats oblige l'opérateur à choisir un répertoire ACME, des contacts, un stockage et à accepter les conditions d'utilisation. Cela empêche que les fonctionnalités opérationnelles ne deviennent des surfaces réseau inattendues.
Le récepteur de base se lie également à 127.0.0.1. Un opérateur doit sélectionner explicitement une adresse publique. Ce choix unique crée un point de contrôle utile pour les règles de pare-feu, les autorisations de service, l'identité TLS et la topologie de déploiement.
Le proxy inverse préserve la limite de confiance
Lorsque la mise en place d'un reverse proxy est activée, le passage TLS reste le paramètre par défaut. Webship transmet le trafic chiffré sans prendre possession du texte clair de l'application ni des clés de session actives. L'origine demeure responsable du TLS et du protocole négocié.
Activez la terminaison TLS uniquement lorsque Webship doit inspecter les requêtes HTTP, router par chemin, appliquer une politique WAF et API, réécrire les en-têtes ou mettre en cache les réponses. La terminaison n'est pas intrinsèquement moins sûre ; elle déplace la frontière de confiance. La décision importante est de savoir quelle machine est autorisée à voir le texte en clair et pourquoi.
Le passage direct a également des limites fonctionnelles. Le routage TCP est basé sur le SNI ClientHello car la requête HTTP est cryptée. Le passage HTTP/3 nécessite que les routes partagent une seule origine UDP. Si vous avez besoin de sécurité consciente du contenu en périphérie, terminez le TLS à cet endroit et protégez séparément le trajet de la périphérie à l'origine.
Une base de production que vous pouvez examiner
L'extrait suivant rend explicites les défauts importants au lieu de compter sur leur omission :
listen = "0.0.0.0:443"
deny_dotfiles = true
[tls]
unknown_sni = "reject"
[ddos]
enabled = true
mode = "normal"
requests_per_minute = 600
burst = 100
block_seconds = 60
max_tracked_clients = 65536
[security]
enabled = true
rate_limit_max_entries = 65536
[security.waf]
enabled = true
mode = "block"
sqli = true
xss = true
traversal = true
sensitive_paths = true
header_abuse = true
max_header_bytes = 32768
max_path_bytes = 2048
max_body_bytes = 1048576
[security.response_headers]
enabled = true
nosniff = true
frame_deny = true
referrer_no_referrer = true
hsts = "max-age=31536000; includeSubDomains"
content_security_policy = "default-src 'self'; frame-ancestors 'none'; base-uri 'self'"
permissions_policy = "geolocation=(), microphone=(), camera=()"Sur un écouteur multi-domaine, unknown_sni = "reject" empêche un nom d'hôte non reconnu de recevoir le certificat par défaut de l'écouteur. Les écouteurs TLS automatiques de Webship rejettent déjà les noms inconnus jusqu'à ce qu'un certificat existe.
La validation est un contrôle de sécurité
Webship valide la configuration avant de lier les écouteurs. Les champs inconnus, les limites invalides, les identités incomplètes, les écouteurs en conflit et les combinaisons de protocoles non prises en charge empêchent le démarrage avec une erreur spécifique. La même validation s'exécute avant qu'une configuration en direct ne soit installée. Un rechargement échoué laisse la configuration actuelle active.
Le chemin de configuration MCP authentifié ajoute une autre protection : il refuse les modifications en direct qui désactiveraient un WAF actif, une couche DDoS, un bouclier API, un défi pour bots, une politique d'authentification en périphérie ou une couche d'en-tête de réponse. Les vérifications de version empêchent un administrateur d'écraser un instantané de configuration plus récent. Les paramètres liés au processus nécessitent toujours un redémarrage au lieu de prétendre qu'une modification partielle en direct a réussi.
C'est une distinction utile. Les paramètres sécurisés protègent un déploiement nouveau. La validation transactionnelle et les mises à jour protégées protègent un déploiement en cours.
Quels opérateurs doivent encore décider
Avant d'exposer Webship à Internet :
- Configurez une identité TLS de confiance et protégez la clé privée.
- Définir la gestion des SNI inconnus pour la topologie de l'écouteur.
- Confirmez que HSTS et Content-Security-Policy correspondent à chaque application et sous-domaine.
- Définir les points de terminaison d'API Shield, les méthodes acceptées, les types de contenu et les exigences en matière d'autorisation.
- Ajoutez des limites de débit spécifiques à chaque itinéraire au lieu de vous fier uniquement au seuil global.
- Activez l'authentification en périphérie pour les hôtes ou chemins protégés et utilisez des jetons à courte durée de vie.
- Garder les écouteurs MCP et d'observabilité privés, authentifiés et séparés du trafic public.
- Exécutez Webship avec un compte dédié sans privilèges, une racine d'application en lecture seule si possible, et uniquement les capacités du système d'exploitation dont il a besoin.
- Validez la configuration avant le déploiement, puis testez le trafic bloqué et autorisé dans un environnement canari.
- Surveillez les événements d'audit de sécurité et répétez le passage du mode normal au mode en attaque ou en verrouillage.
Une valeur par défaut plus sûre est un début, pas une affirmation
Aucun serveur web ne peut décider quels utilisateurs doivent voir vos factures, quelles origines peuvent appeler votre API, ou à quelle vitesse votre point de terminaison commercial doit accepter les requêtes. Ces contrôles nécessitent une connaissance de l'application.
Webship fournit la couche inférieure : des analyseurs bornés, une configuration stricte, des en-têtes de réponse défensifs, l'inspection des requêtes, des contrôles contre les abus et des surfaces optionnelles fermées. Le résultat n'est pas une « sécurité résolue ». C'est un écart plus réduit entre l'installation d'un serveur et son fonctionnement responsable.
Examinez la documentation complète de Webship avant le déploiement en production. Le schéma de configuration et le binaire en cours d'exécution restent les sources faisant foi pour la version exacte que vous utilisez.