Ajoutez l'en-tête HSTS au point de terminaison HTTPS qui héberge Nextcloud.

L'avertissement « Strict-Transport-Security » de Nextcloud signifie que la vérification n'a pas détecté d'en-tête HSTS avec un délai max-aged'au moins 15552000180 jours (secondes) dans la réponse HTTPS publique. Ajoutez cet en-tête sur le serveur web ou le proxy inverse qui gère le HTTPS, puis testez cette URL publique. HSTS n'est pas une option de configuration de Nextcloud config.php, et une simple réponse HTTP ne permet pas d'établir une politique HSTS dans les navigateurs.

Que vérifier avant de modifier la configuration

• Vérifiez que le site Nextcloud se charge correctement via HTTPS et présente un certificat valide pour son nom d'hôte.
• Identifiez le service qui termine la connexion TLS : Apache, NGINX, un équilibreur de charge, un point d’entrée de conteneur ou un proxy externe.
• Vérifiez si ce service est déjà configuré Strict-Transport-Security. Envoyez une seule politique explicite depuis le point de terminaison TLS public ; les en-têtes dupliqués ou contradictoires rendent la vérification difficile.
• Avant d'ajouter des sous-domaines, assurez-vous qu'ils sont tous prêts pour HTTPS includeSubDomains. N'activez pas preloadcette option pour faire disparaître rapidement cet avertissement.

HSTS indique aux navigateurs que les futures connexions à un nom d'hôte doivent utiliser HTTPS. Cela empêche le passage à HTTP après la réception de cette politique par le navigateur. HSTS ne remplace pas TLS, ne corrige pas un certificat invalide et ne redirige pas la première visite HTTP ; il est donc nécessaire de configurer une redirection HTTP vers HTTPS distincte. Le manuel d'administration de Nextcloud 35 précise le délai minimal de 15 552 000 secondes et recommande de configurer l'en-tête sur le serveur web. Dans un déploiement de proxy, le point d'application effectif est le composant qui renvoie la réponse au visiteur.

Établir une politique de base

Une politique de départ prudente pour un nom d'hôte Nextcloud est :

Strict-Transport-Security: max-age=15552000

Cela permet de respecter la durée de vie minimale des documents Nextcloud sans appliquer automatiquement une politique à chaque sous-domaine. Une fois que vous avez confirmé que tous les sous-domaines concernés prennent en charge le protocole HTTPS en continu, vous pouvez envisager d'ajouter ; includeSubDomainscette directive. Un navigateur qui l'a intégrée exigera également le protocole HTTPS pour ces sous-domaines. Un tableau de bord interne, un serveur de messagerie ou un service existant qui dépend encore du protocole HTTP risque de devenir inaccessible dans ce navigateur jusqu'à sa migration ou l'expiration de la politique.

Apache

Pour un hôte virtuel Apache TLS, activez mod_headerset placez la directive à l'intérieur de l'hôte virtuel HTTPS, et non pas seulement dans l'hôte de redirection du port 80 :

<VirtualHost *:443>
    ServerName cloud.example.com
    # Keep the existing TLS and Nextcloud configuration here.
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>
</VirtualHost>

Remplacez le nom d'hôte d'exemple et conservez votre certificat et votre configuration de proxy ou PHP existants. L'exemple de renforcement de la sécurité d'Apache de Nextcloud utilise Header always setl'hôte virtuel HTTPS. Validez la configuration d'Apache avec la commande `config-test` prise en charge par votre distribution, puis rechargez Apache uniquement si le test réussit.

NGINX

Dans NGINX, ajoutez l'en-tête à l'intérieur du serverbloc qui écoute le protocole HTTPS sur le nom d'hôte public de Nextcloud :

server {
    listen 443 ssl;
    server_name cloud.example.com;
    # Keep your existing TLS and Nextcloud locations here.
    add_header Strict-Transport-Security "max-age=15552000" always;
}

Ne copiez pas ceci comme un remplacement complet de la configuration existante du serveur. L'héritage des en-têtes NGINX peut dépendre de la présence add_headerde directives propres à un emplacement imbriqué ; examinez la configuration effective et testez des réponses représentatives, incluant les ressources statiques et les points de terminaison DAV. L'exemple officiel NGINX de Nextcloud inclut un paramètre HSTS dans sa configuration HTTPS et met en garde les administrateurs contre l'activation du préchargement.

proxy inverse ou entrée

Si un équilibreur de charge, un serveur d'entrée ou un proxy hébergé termine le protocole HTTPS avant de transférer le trafic vers Nextcloud, configurez HSTS au niveau de cette couche TLS publique, sauf si votre architecture l'ajoute délibérément au niveau d'un serveur en amont de confiance. Un en-tête ajouté uniquement par le serveur d'arrière-plan peut être supprimé ou remplacé par le proxy. Inversement, le configurer aux deux niveaux peut générer des valeurs dupliquées. Vérifiez la configuration de l'en-tête de réponse du proxy et assurez-vous que c'est bien sa route HTTPS qui est testée. Veillez à ce que les paramètres de proxy de confiance et d'URL HTTPS de Nextcloud restent cohérents avec le déploiement existant, mais ne les considérez pas comme un substitut à l'émission de l'en-tête.

Valider la réponse du public

1. Utilisez le vérificateur de syntaxe de la plateforme pour la configuration modifiée du serveur Web ou du proxy.
2. Rechargez ou déployez la configuration validée.
3. Demandez l'adresse HTTPS publique et examinez les en-têtes de réponse : curl -sSI https://cloud.example.com/. Recherchez une Strict-Transport-Securityligne dont max-agela valeur est au moins égale à 15552000.
4. Dans les outils de développement de votre navigateur, examinez la réponse provenant du même nom d'hôte public. Cela peut révéler un proxy modifiant les en-têtes ou une route contournant l'hôte virtuel attendu.
5. Rechargez la page Administration → Vue d'ensemble de Nextcloud et laissez la vérification de sécurité se rafraîchir.

Si curll'en-tête HSTS est absent, vérifiez que le DNS pointe bien vers le point de terminaison modifié, que la requête utilise HTTPS et que le proxy ne supprime pas l'en-tête. Si l'en-tête apparaît sur la page d'accueil mais pas dans les autres réponses, examinez les directives de localisation NGINX ou les règles d'en-tête de réponse du proxy. Si la réponse publique est correcte mais que Nextcloud émet toujours un avertissement, vérifiez que la vérification d'administration utilise le même nom d'hôte et le même schéma visibles de l'extérieur, puis inspectez toute couche de cache ou de proxy entre le serveur et la vérification.

N'utilisez le préchargement qu'après une vérification à l'échelle du domaine

Le préchargement est une option distincte et à fort impact. La directive de préchargement n'enregistre pas de domaine ; les listes de préchargement des navigateurs ont leurs propres exigences de soumission. Les recommandations actuelles des navigateurs exigent une procédure d'inscription longue max-age. includeSubDomainsNextcloud prévient que la suppression d'un domaine d'une liste de préchargement peut prendre plusieurs mois avant d'être prise en compte par les navigateurs installés. Commencez par la politique de base, recensez tous les noms d'hôtes concernés, vérifiez que le protocole HTTPS fonctionne correctement sur l'ensemble du domaine et consultez les exigences officielles de préchargement avant d'appliquer la modification. La plupart des administrateurs Nextcloud peuvent résoudre ce problème sans activer le préchargement.

Références : Avertissements de sécurité de Nextcloud 35 , conseils de renforcement de Nextcloud , configuration NGINX de Nextcloud et référence d’en-tête HSTS de MDN .