openMairie.org | Démonstration | Documentation | Forum

Prop0074 - Proposer une configuration des header HTTP

Porteur principal : Laurent Groleau

Porteur secondaire : Stéphane Vicedo

Résumé

Mettre en place par défaut une configuration applicative des header HTTP correspondant aux bonnes pratiques, non dé-verrouillable par paramétrage pour conserver un haut niveau de sécurité.

Motivation

Obtenir un meilleur score sur https://observatory.mozilla.org

Pré-requis

aucun

Proposition et implémentation

Branche faite depuis OM 4.9.2 : .../openmairie_exemple/branches/prop0074-configuration_header_http/

Branche avec un seul fichier modifié : R4523

Risques

Blocage de fonctionnalités des applications: Javascript, … Testé manuellement sur une application implémentant le module SIG (JS et CSS en ligne).

1 J'aime

Modification de la proposition: Le header HTTPS ne semble pas bloquer la communication quand on est en HTTP, il n’est donc pas utile de mettre en place un paramètre de commutation HTTP/HTTPS pour le développement, …

Risques:
L’appel du code par la méthode d’affichage ne couvre pas les situations où on n’affiche pas le « fond » openMairie : script PHP spécifique, fichier CSV ou PDF, …

Après exécution des tests de non-régression, la proposition sera prête à intégrer

1 J'aime

MISE A JOUR:

Proposition et implémentation

Branche faite depuis OM 4.10.0-dev : .../openmairie_exemple/branches/prop0074-configuration_header_http/

Branche avec un seul fichier modifié : core/om_application.class.php

Commit significatif, corrigeant le premier dev 4564

Voir les résultats détaillés dans le fichier : om_prop0074_resultats.odt (285,9 Ko)

Risques

Après recodage, le positionnement des headers s’effectue dans le constructeur d’om_application, donc PDF, exports CSV et scripts PHP spécifiques sont désormais inclus.

Sur certaines applications, suivant les ressources externes utilisées, il pourrait subsister des blocages Content-Security-Policy. En ce cas, le blocage est visible dans la console JavaScript du navigateur ou en utilisant la fonctionnalité « report-uri » du header CSP : la navigateur POSTe l’alerte au serveur au format JSON.
En cas de doute, on peut d’ailleurs activer le header CSP en mode « report only » pour auditer les éventuels blocages sur une période de production normale, avant de les activer. Il suffit de renommer le header, comme indiqué sur le site de Mozilla.

Bonjour,

En pièce jointe le résultat de l’exécution des tests sur notre plateforme.
Résultat : 54/57
3 fails explicables :

15:55:15 Synchronisation des utilisateurs avec un annuaire LDAP :: On teste… | FAIL |
15:57:31 Page should have contained text ‹ Il y a 4 utilisateur(s) présent(s) dans l’annuaire et non présent(s) dans la base => 4 ajout(s) › but did not.
15:57:31 ------------------------------------------------------------------------------
=> Notre plateforme n’accède pas au web

16:03:59 Pagination en formulaire :: Vérifie la pagination sur un formulaire. | FAIL |
16:04:02 NoSuchElementException: Message: Cannot locate option with value: 15
16:04:02 ------------------------------------------------------------------------------
=> Fail de la branche OM4.10-dev

16:04:02 Pagination en sous-formulaire :: Vérifie la pagination sur un sous… | FAIL |
16:04:09 NoSuchElementException: Message: Cannot locate option with value: 15
16:04:09 ------------------------------------------------------------------------------
=> Idem

PROP74 Résultat test.txt (20,7 Ko)
Ici l’exécution témoin de la 4.10.0-dev : 4.10.0-dev Résultat test.txt (16,1 Ko)

1 J'aime