[Problème] SecurityReport Summary

[phelibre]

Bonjour,

Je suis bénévole à Artisans du Monde La Rochelle et j'essaye de maintenir le site www.admlarochelle.com en version 3.9.27

Suite à la lecture d'un post de betterweb, je suis arrivé sur la page de securityheaders.com et je me retrouve avec 5 pavés rouges sur 6, moi qui pensait respecter les préconisations

Que faire pour repasser les : Strict-Transport-Security Content-Security-Policy X-Frame-Options X-Content-Type-Options Referrer-Policy au vert ?
Je ne vois pas vraiment ou l'on peut modifier dans l'IHM Admin !!! Il faut éditer des fichiers PHP et autres je suppose ?

Merci

[phelibre]

Excusez, je n'avais pas vu qu'une file a été créé en 2017 !

Donc pour le peu que je comprends je peux ajouter dans mon .htaccess :

-1 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

-2 Content-Security-Policy: default-src * data: ; script-src * 'unsafe-inline' 'unsafe-eval' ; style-src * 'unsafe-inline' data: ; frame-ancestors 'none' ; base-uri 'self' ;

-3 Header set X-Frame-Options "DENY"

-4 <IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>

-5 Referrer-Policy: "no-referrer"

les - et chiffres seront retirés bien-sur

Vous en pensez quoi ?

[pmleconte]

Bonsoir,

Nous avons eu une longue discussion à propos du plugin http headers https://forum.joomla.fr/forum/joomla...gin-httpheader

Il sera intégré dans Joomla 4.

Pascal

[jfque]

En attendant, vous pouvez effectivement avoir :

1) <IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS
</IfModule>

2) La CSP par défaut ne sert pas à grand chose puisque dans le fond vous autorisez tout ! Il vaut mieux commencer par quelque chose de strict et de vérifier dans la console du navigateur s'il y a des erreurs.
A titre d'info, ma CSP est la suivante :

Header set Content-Security-Policy: "base-uri 'self'; default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' d1sn4l25wts1t9.cloudfront.net *.google-analytics.com *.googletagmanager.com *.googletagservices.com cdn.ampproject.org *.facebook.net *.linkedin.com *.googleapis.com *.google.com *.google.fr *.googlesyndication.com *.doubleclick.net *.ipify.org *.iubenda.com *.acyba.com *.youtube.com *.ytimg.com *.gstatic.com *.jquery.com *.cloudflare.com *.jsdelivr.net; style-src 'self' 'unsafe-inline' d1sn4l25wts1t9.cloudfront.net *.googleapis.com maxcdn.boo *.bootstrapcdn.com *.google.com *.jsdelivr.net; img-src 'self' *.betterweb.fr data: d1sn4l25wts1t9.cloudfront.net *.google-analytics.com *.googletagmanager.com stats.g.doubleclick.net *.acyba.com *.facebook.com static.licdn.com *.linkedin.com traffic.alexa.com *.semrush.com csi.gstatic.com *.google.com *.google.fr zxing.org *.googleapis.com *.norrnext.com *.licdn.com *.joomla.org *.unsplash.com pixabay.com *.pexels.com *.tassos.gr *.iubenda.com api.ecologi.com; child-src 'self' *.facebook.com *.facebook.net *.youtube.com *.youtube-nocookie.com *.googletagmanager.com *.acyba.com *.linkedin.com *.iubenda.com *.gstatic.com *.google.com *.doubleclick.net *.joomunited.com; font-src 'self' data: fonts.gstatic.com d1sn4l25wts1t9.cloudfront.net fonts.googleapis.com *.bootstrapcdn.com *.jsdelivr.net; connect-src 'self' api.ipify.org *.google-analytics.com *.doubleclick.net *.ampproject.net *.googletagmanager.com *.google.com *.google.fr *.appspot.com *.youtube.com *.linkedin.com *.iubenda.com *.cdnjs.com *.facebook.com yootheme.com; media-src 'self' *.amazonaws.com *.googlesyndication.com; upgrade-insecure-requests; report-uri https://betterweb.report-uri.com/r/d/csp/enforce;"

<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif|htc|ic[os]|jpe?g|m?js|json(ld)?|m4[av]|manifest|map|markdown|md|mp4|oex|og[agv]|opus|otf|pdf|png|rdf|rss|safariextz|svgz?|swf|top ojson|tt[cf]|txt|vcard|vcf|vtt|webapp|web[mp]|webmanifest|woff2?|xloc|xml|xpi)$">
Header unset Content-Security-Policy
</FilesMatch>

3) "DENY" est probablement trop strict :

<IfModule mod_headers.c>

Header always append X-Frame-Options SAMEORIGIN

# The `X-Frame-Options` response header should be send only for
# HTML documents and not for the other resources.

<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif|htc|ico|jpe?g|js|json(ld)?|m4[av]|manifest|map|mp4|oex|og[agv]|opus|otf|pdf|png|rdf|rss|safariextz|svgz?|swf|top ojson|tt[cf]|txt|vcard|vcf|vtt|webapp|web[mp]|woff2?|xloc|xml|xpi)$">
Header unset X-Frame-Options
</FilesMatch>

4)<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>

5) No referrer est trop limitatif :

<IfModule mod_headers.c>
Header always set Referrer-Policy "no-referrer-when-downgrade"
</IfModule>

[phelibre]

Merci de votre aide jfque, dès que je peux je vais mettre à jour mon .htaccess

Cordialement

[phelibre]

Voilà j'ai ajouté les lignes dans mon fichier .htaccess mais toujours les mêmes alertes !! Je suis en hébergement mutualisé chez online et pas d'administration du serveur nginx, je ne sais pas si il y a un rapport ?

Merci,

[jfque]

Si votre serveur est nginx, je pense que les fichiers .htaccess ne fonctionnent pas. Il y a un autre type de fichier à utiliser (mais je n'ai jamais exploré).

[phelibre]

Il semblerait que Oui d'après la online, enfin je viens de mettre le htaccess natif Joomla, cela mais une erreur ! je remets celui que j'utilisais et ça redevient bon ... Finalement le site de test securityheaders.com se trompe, en regardant sous Joomla Info site j'ai Apache/2.4.10 (Ubuntu)

Voilà mon fichier qui fonctionne htaccess.txt

Encore merci

[jfque]

Le site securityheaders se contente de lire les en-têtes envoyées par le serveur et vous pouvez voir toutes ces données vous-mêmes via les outils pour développeurs de votre navigateur (dans l'onglet "Réseau"). Vous verrez que le serveur qui est signalé est bien nginx.
Cela peut vouloir dire que le serveur du site est Apache mais que l'hébergeur passe par un serveur proxy nginx qui sert d'accélérateur et c'est lui qui est "vu" par le réseau.
Dans ce cas, est-ce que les directives du .htaccess sont prises en charge ? Je n'en sais rien mais vous devriez pouvoir le tester, par exemple via la CSP : vous enlever un service qui devrait y être (par exemple si vous afficher des boutons de partage Facebook, vous enlever *.facebook.com de la section "script") et vous voyez si le bouton s'affiche toujours ou pas. Si oui, votre .htaccess ne fait rien, si non, ça fonctionne, même si le test dit le contraire.

[phelibre]

Bonjour,

Oui online m'a répondu dans votre sens :

Nous avons 2 load balancers qui tournent nginx , et qui forward des requêtes vers nos PF. Dans les PF ce sont des containers apache qui tournent pour chaque site. Nos PF sont donc bien sous Apache à ce niveau là.

Si je comprends Apache tourne dans un container par entité dans le serveur mutualisé mais côté internet c'est nginx qui est visible ... Si .htaccess n'est conforme j'ai une erreur, il est donc bien pris en compte. Il est peut-être possible que securityheaders.com prend en compte nginx comme serveur à la place d'apache et donc une source d'erreurs ...

Merci,