Correction de l'avertissement concernant l'en-tête HSTS (Strict-Transport-Security) manquant dans Nextcloud

Lorsque Nextcloud signale « L'en-tête HTTP Strict-Transport-Security n'est pas configuré », la correction doit être apportée au niveau de la couche de service des réponses HTTPS : Apache, Nginx ou le proxy inverse public qui termine la connexion TLS. Le manuel d'administration actuel de Nextcloud indique qu'un en-tête manquant ou une durée max-ageinférieure à 25 15552000secondes constitue un avertissement de sécurité. Une fois l'en-tête présent sur le point de terminaison HTTPS public, les navigateurs peuvent se souvenir que l'hôte doit utiliser HTTPS pendant la durée déclarée.

La modification de base est mineure, mais son étendue est importante. Appliquez HSTS uniquement à un point de terminaison HTTPS fonctionnel doté d'un certificat valide. Commencez par l'hôte uniquement ; ajoutez includeSubDomainsHSTS preloadseulement lorsque chaque nom d'hôte concerné est prêt pour HTTPS. Ce guide reflète la documentation d'administration de Nextcloud disponible en octobre 2026, y compris ses recommandations en matière d'avertissements de sécurité et de renforcement de la sécurité des serveurs .

Que signifie cet avertissement ?

L'en-tête de réponse HTTP Strict Transport Security (HSTS) indique au navigateur d'utiliser HTTPS pour les requêtes ultérieures adressées à un nom d'hôte. Il empêche le navigateur de revenir au protocole HTTP non chiffré après avoir reçu cette politique via une connexion HTTPS valide. Nextcloud vérifie la réponse publique et émet un avertissement lorsqu'il ne détecte pas de politique avec la durée de vie minimale recommandée.

HSTS ne remplace pas l'activation de TLS ni la redirection HTTP vers HTTPS. Le navigateur n'accepte une politique HSTS que si elle est transmise via HTTPS. Lors d'une première visite, avant que le navigateur n'ait pris connaissance de cette politique, la requête initiale peut rester vulnérable, sauf si le nom d'hôte figure dans une liste de préchargement du navigateur. Une redirection HTTP vers HTTPS classique demeure utile, mais ne remplace pas l'en-tête HSTS.

Déterminez quel serveur doit envoyer l'en-tête.

Avant de modifier la configuration, suivez la requête publique. Si les utilisateurs se connectent directement à Apache ou Nginx via HTTPS, configurez l'hôte virtuel TLS de ce serveur web. Si un équilibreur de charge, un serveur d'entrée, un CDN ou un proxy inverse termine la connexion TLS publique, configurez la couche qui envoie la réponse au navigateur. L'ajout de l'en-tête uniquement à une connexion HTTP interne peut ne pas affecter la réponse publique.

Nextcloud documente l'utilisation des proxys inverses comme un modèle de déploiement pris en charge et exige que les administrateurs définissent les proxys de confiance le cas échéant. La gestion HSTS par le proxy est indépendante de la gestion des URL et des adresses IP client par Nextcloud. En particulier, overwriteprotocolelle permet à Nextcloud de reconnaître le schéma externe dans certaines configurations de proxy ; sa configuration n'ajoute pas l'en-tête de réponse HSTS. Consultez le guide de configuration officiel des proxys inverses de Nextcloud si l'application génère des liens HTTP ou signale d'autres avertissements liés aux proxys.

Avant de modifier la politique

• Confirme https://cloud.example.comle chargement sans erreur de certificat et utilise la chaîne de certificats prévue.
• Vérifiez si les requêtes HTTP sont redirigées vers le même nom d'hôte via HTTPS.
• Identifiez les autres services et sous-domaines du même domaine parent avant d'envisager includeSubDomains.
• Veuillez maintenir un accès à une interface d'administration ou à une console serveur. Un navigateur ayant mis en cache HSTS refusera à l'utilisateur de contourner les erreurs de certificat pendant la durée de la politique.

Remplacez cloud.example.comles noms d'hôtes d'exemple par le vôtre dans Nextcloud. Ne copiez pas ces noms d'hôtes dans votre configuration de production.

Configurer HSTS dans Apache

Dans l'hôte virtuel Apache TLS qui héberge Nextcloud, activez le module headers et ajoutez la politique de sécurité. Le guide de renforcement de Nextcloud recommande une période de six moisincludeSubDomains ; la version suivante, réservée à l'hôte, constitue un point de départ prudent :

<VirtualHost *:443>
    ServerName cloud.example.com

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>

    # Existing Nextcloud and TLS directives
</VirtualHost>

Assurez-vous que mod_headersle service HTTPS est activé dans la configuration Apache de votre distribution. Ajoutez la directive à l'hôte virtuel HTTPS, et non à celui du port 80. Validez la configuration à l'aide de la commande appropriée à votre distribution, puis rechargez Apache via son gestionnaire de services. Par exemple, de nombreuses distributions basées sur systemd prennent en charge le service HTTPS sudo apachectl configtestsuivi de sudo systemctl reload apache2`--service`. Sur certaines distributions, le service s'appelle `--service` httpd. Utilisez la commande correspondant au nom de votre paquet et de votre service.

Configurer HSTS dans Nginx

Dans le serverbloc Nginx qui écoute le trafic HTTPS et sert le nom d'hôte public de Nextcloud, ajoutez :

server {
    listen 443 ssl;
    server_name cloud.example.com;

    add_header Strict-Transport-Security "max-age=15552000" always;

    # Existing certificate and Nextcloud configuration
}

Ce alwaysparamètre permet à Nginx d'ajouter l'en-tête quel que soit le statut de la réponse. La documentation Nginx mentionne une règle d'héritage qui peut surprendre les administrateurs : add_headerles directives de configuration de niveau inférieur modifient le comportement d'héritage normal. Si un locationbloc imbriqué définit ses propres add_headerdirectives, l'en-tête HSTS au niveau du serveur risque de ne plus y être hérité. Vérifiez la configuration active et testez des URL représentatives, notamment la page de connexion et une ressource statique. Consultez la documentation officielle du module d'en-têtes Nginx .

Avant d'appliquer les modifications, exécutez la commande suivante sudo nginx -t. Si la validation réussit, rechargez Nginx à l'aide de la commande de service de votre système, généralement `nginx.reload` sudo systemctl reload nginx. Tout test de syntaxe ayant échoué doit être corrigé avant le rechargement.

Configurer un proxy inverse ou un terminateur TLS

Si le trafic HTTPS public aboutit à un proxy inverse, ajoutez l'en-tête HSTS à la réponse HTTPS de ce proxy. Par exemple, un proxy peut l'envoyer même si sa connexion au serveur Nextcloud utilise HTTP. N'envoyez pas l'en-tête HSTS uniquement dans la réponse non chiffrée du serveur en supposant que le navigateur la verra.

Vérifiez si le proxy et le serveur ajoutent déjà le même en-tête. La présence de champs HSTS dupliqués peut compliquer le diagnostic, et un proxy peut écraser ou masquer un en-tête du serveur. Choisissez une couche exposée au public pour gérer la politique, ou configurez les couches de manière à ce que le navigateur reçoive une valeur unique et claire. Après avoir modifié le proxy, assurez-vous qu'il transmet bien l'hôte et le schéma attendus à Nextcloud et que les liens HTTPS fonctionnent toujours.

Vérifier la réaction du public

Utilisez une requête adressée au nom d'hôte HTTPS public, et non pas seulement à une adresse localhost ou à une adresse backend :

curl -sSI https://cloud.example.com
curl -sSIL http://cloud.example.com

Dans la première réponse, recherchez un seul en-tête similaire à :

Strict-Transport-Security: max-age=15552000

La deuxième commande intervient après les redirections. Vérifiez que l'URL HTTP atteint bien le nom d'hôte HTTPS prévu, puis examinez la réponse HTTPS à la recherche de l'en-tête HSTS. Les navigateurs ignorent les messages HSTS reçus via HTTP simple ; l'en-tête n'a donc pas besoin d'apparaître lors de la redirection initiale sur le port 80. Vous pouvez également utiliser les outils de développement de votre navigateur : ouvrez le panneau Réseau, rechargez la page HTTPS, sélectionnez la réponse du document et examinez les en-têtes de réponse.

Vérifiez plusieurs chemins de réponse si votre configuration comporte des emplacements imbriqués, plusieurs niveaux de proxy ou une gestion distincte des ressources statiques. Ensuite, accédez aux paramètres d'administration de Nextcloud et actualisez l'aperçu de sécurité. L'actualisation d'un avertissement peut prendre du temps ou refléter l'URL publique exacte que Nextcloud sonde ; comparez donc cette URL avec celle que vous avez testée.

Choisissez soigneusement la portée et la durée de vie. Adaptez-vous aux besoins des utilisateurs et choisissez avec soin la portée et la durée de vie.

Une période max-agede 15552000six mois correspond au seuil d'alerte documenté de Nextcloud. La politique est renouvelée lorsqu'un navigateur reçoit un nouvel en-tête HSTS valide. La raccourcir ou la supprimer ultérieurement nécessite une transmission max-age=0via HTTPS à chaque nom d'hôte concerné ; les navigateurs qui ne se reconnectent pas pendant la modification conserveront leur politique en cache jusqu'à son expiration.

includeSubDomainsCette politique s'applique à tous les sous-domaines du nom d'hôte. Utilisez-la uniquement si tous les sous-domaines actuels et futurs prennent en charge HTTPS avec des certificats valides. Un service distinct, tel que [nom du service], mail.example.compeut legacy.example.comdevenir inaccessible aux navigateurs s'il n'est pas opérationnel.

L' preloadajout d'un jeton est une décision distincte et importante. Les recommandations de Nextcloud concernant le renforcement de la sécurité expliquent comment ajouter un nom d'hôte aux listes de préchargement des navigateurs et précisent que la suppression peut prendre des mois avant d'être prise en compte par les navigateurs installés. N'utilisez pas ce jeton comme solution rapide pour faire disparaître une détection de scanner. Vérifiez d'abord toutes les conditions de préchargement requises et l'impact sur chaque sous-domaine ; suivez les recommandations officielles du service de préchargement HSTS si vous souhaitez demander son inclusion.

Si l'avertissement persiste

• L'en-tête est absent dans curl : vous avez peut-être modifié le mauvais hôte virtuel, proxy ou emplacement Nginx. Vérifiez la cible DNS publique et la configuration du serveur actif.
• L'en-tête n'apparaît que sur certaines pages : consultez les directives Nginx imbriquées add_header, la gestion des erreurs, les chemins d'accès aux ressources statiques et les règles de proxy.
• La réponse comporte plusieurs politiques : identifier les couches qui ajoutent le champ et les consolider en une seule valeur cohérente.
• L'en-tête est présent mais l'avertissement persiste : vérifiez que l'URL configurée en externe de Nextcloud pointe bien vers le même point de terminaison HTTPS, vérifiez la gestion du schéma de proxy, puis rechargez la vue d'ensemble de l'administration.
• Le protocole HTTPS ou le certificat n'est pas prêt : commencez par corriger le protocole TLS et le routage HTTP vers HTTPS. HSTS ne peut pas réparer un certificat défectueux ni activer HTTPS par lui-même.

La correction est terminée lorsque la réponse HTTPS publique contient systématiquement la valeur HSTS attendue, que Nextcloud peut accéder correctement à son URL HTTPS publique et que le navigateur peut charger l'instance sans erreur de certificat ni de redirection. HSTS améliore l'application des politiques de transport pour les navigateurs effectuant le retour ; il ne remplace pas la maintenance des certificats, la configuration d'un proxy sécurisé ni une procédure de récupération testée.