Performances du cms

Bonjour,

je viens vous voir pour discuter des performances du CMS Spip. Récemment j’ai été amenée à utiliser des simulateurs de vitesse et performance comme Dareboost.

Sur un Spip 3.1.8, j’ai des erreurs assez inquiétantes :

  • Site exposé aux « Click jacking » (je pensais qu’une mise à jour avait sécurisé ce type d’attaque)
  • le fichier robots.txt n’est pas défini (il est dans le squelette oui, mais je ne savais pas qu’il fallait le mettre manuellement)
  • Bloquer l’accès à la page entière lorsqu’une attaque XSS est suspectée ( ??? )
  • Désactiver la détection auto du type de ressource (je fais ça où ?)
  • il me dit que la politique de sécurité du site est manquante alors que cette page existe ! Comment faire pour améliorer ça ?

Il n’aime clairement pas non plus que l’appel JS se fasse dans le head. Pourquoi d’ailleurs c’est toujours dans le head alors qu’il est toujours conseillé de le mettre avant la fermeture de la balise body ?

Merci pour vos retours

TEENOO

Le 29/10/2018 à 11:25, Laetitia boiron a écrit :

Bonjour,

je viens vous voir pour discuter des performances du CMS Spip. Récemment j’ai été amenée à utiliser des simulateurs de vitesse et performance comme Dareboost.

Sur un Spip 3.1.8, j’ai des erreurs assez inquiétantes :
- Site exposé aux « Click jacking » (je pensais qu’une mise à jour avait sécurisé ce type d’attaque)
- le fichier robots.txt n’est pas défini (il est dans le squelette oui, mais je ne savais pas qu’il fallait le mettre manuellement)
- Bloquer l'accès à la page entière lorsqu'une attaque XSS est suspectée ( ??? )
- Désactiver la détection auto du type de ressource (je fais ça où ?)
- il me dit que la politique de sécurité du site est manquante alors que cette page existe ! Comment faire pour améliorer ça ?

Il n’aime clairement pas non plus que l’appel JS se fasse dans le head. Pourquoi d’ailleurs c’est toujours dans le head alors qu’il est toujours conseillé de le mettre avant la fermeture de la balise body ?

Merci pour vos retours

TEENOO

Le robots.txt est trouvé automatiquement si le .htaccess est activé.

Pour le rest je n'en sais rien, ne comprenant pas les messages.

Maïeul

Laetitia boiron <boiron.laetitia@gmail.com> writes:

Bonjour,

je viens vous voir pour discuter des performances du CMS Spip.
Récemment j’ai été amenée à utiliser des simulateurs de vitesse et
performance comme Dareboost.

Je viens de tester ce "Dareboost" sur mon site perso.
Premier constat, il ne fait que me renvoyer les mêmes informations que
Google.
S'en suis tout un tas de message plus alarmant les uns que les autres
que je vois plutôt comme des avertisement que comme de vrai problème.

- Site exposé aux « Click jacking » (je pensais qu’une mise à jour
avait sécurisé ce type d’attaque)

A moins que ton site ne publie automatiquement des content produit pas
les visiteurs, je pense que tu ne risque pas grand chose... Et même si
c'est le cas.

- Bloquer l'accès à la page entière lorsqu'une attaque XSS est
suspectée ( ??? )

Heu, c'est un peu méchant quand même...

- Désactiver la détection auto du type de ressource (je fais ça où ?)

Selon ce même site :

Une personne malveillante pourrait profiter d'un envoi de fichier sur
votre site par exemple pour injecter du code malveillant. Nous vous
conseillons de désactiver le MIME-Type sniffing pour limiter les effets
de l'envoi d'un tel fichier.

Est-ce que tu te trouve dans ce cas ?

- il me dit que la politique de sécurité du site est manquante alors
que cette page existe ! Comment faire pour améliorer ça ?

Il parle des Content-Security-Policy, aka CSP.
Je te laisse te renseigné sur ce vaste sujet. Sujet a débat car certain
pense que cela ne sert pas a grand chose...

Il n’aime clairement pas non plus que l’appel JS se fasse dans le
head. Pourquoi d’ailleurs c’est toujours dans le head alors qu’il est
toujours conseillé de le mettre avant la fermeture de la balise body ?

Un script placé dans le body doit être adapter a cet emplacement. Tout
ne fonctionne pas toujours s'il ce trouve dans le body.
Et ce n'est pas automatiquement parce que le développeur du script est
mauvais.
Quand aux performances, la gourmandise des applications javascript est
plus en tord que la position de la balise script...

Bref, les outils d'analyse automatique sont bien quand tu cherches des
indications pour savoir ce que tu devrait peut être améliorer. Mais
inutile de paniquer, il faut analyser les rapports avant.

Sur un Spip 3.1.8, j’ai des erreurs assez inquiétantes :
- Site exposé aux « Click jacking » (je pensais qu’une mise à jour avait sécurisé ce type d’attaque)
- le fichier robots.txt n’est pas défini (il est dans le squelette oui, mais je ne savais pas qu’il fallait le mettre manuellement)
- Bloquer l'accès à la page entière lorsqu'une attaque XSS est suspectée ( ??? )
- Désactiver la détection auto du type de ressource (je fais ça où ?)
- il me dit que la politique de sécurité du site est manquante alors que cette page existe ! Comment faire pour améliorer ça ?

Il n’aime clairement pas non plus que l’appel JS se fasse dans le head. Pourquoi d’ailleurs c’est toujours dans le head alors qu’il est toujours conseillé de le mettre avant la fermeture de la balise body ?

Merci pour vos retours

TEENOO

_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : https://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Le 29/10/2018 à 12:56, Debondt Didier a écrit :

Laetitia boiron <boiron.laetitia@gmail.com> writes:

Il n’aime clairement pas non plus que l’appel JS se fasse dans le
head. Pourquoi d’ailleurs c’est toujours dans le head alors qu’il est
toujours conseillé de le mettre avant la fermeture de la balise body ?

Un script placé dans le body doit être adapter a cet emplacement. Tout
ne fonctionne pas toujours s'il ce trouve dans le body.
Et ce n'est pas automatiquement parce que le développeur du script est
mauvais.

C'est le grand débat de positionner, ou non, ses scripts en fin de body.

Il y a une méthode qui permet d'améliorer ça en les laissant dans le head et donc profiter de la compression/concaténation (qui est sans doute plus importante). Il suffit de mettre /define('_JS_ASYNC_LOAD',true);/ dans mes_options.php (depuis 3.1). Mais attention, certains plugins ne fonctionnent pas avec jQl.

Si tu veux de la lecture, lire l'article de Cedric qui explique bien le problème (en anglais) : jQl an asynchronous jQuery Loader - yterium.net

             jean marie

Bonjour,

Il semble qu'ils aient besoin de conseils concernant la mise en place
des règles RGPD sur leurs services.
Analytics, se charge sans accord, contrôle ....

Il n’aime clairement pas non plus que l’appel JS se fasse dans le

head. Pourquoi d’ailleurs >c’est toujours dans le head alors qu’il est
toujours conseillé de le mettre avant la fermeture >de la balise body ?

C'est un problème d'ordre dans l’exécution des scripts :
- certains doivent être chargés rapidement et avant la construction de
la page dans le navigateur, pour différentes raisons ..,
- d'autres doivent attendre la fin de l’exécution des premiers (par
exemple pour les scripts chargés de suivre les clics ...

Defer JavaScript - c'est en anglais,
mais cela explique bien la problématique.

Un autre lien : https://developer.matomo.org/guides/tracking-javascrip
t-guide

Pour ce dernier exemple, bien qu'il soit conseillé d'inclure le script
dans le head, ou juste après le body. Dans certains cas, il faudra le
mettre juste avant la fermeture du </body> pour que le suivi puisse
s'effectuer correctement, page entièrement chargée et affichée.

Il n'y a pas de règles universelles.

Cordialement,

Eric

Bonjour,

Pour le clickjacking :

https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/X-Frame-Options

Eric