location /blog/ {
proxy_pass http://127.0.0.1:8000/;
proxy_set_header X-Forwarded-For $remote_addr;
}
On teste sans service sur le port 8000.

Dans l’objectif de vérifier si notre redirection fonctionne, nous faisons tourner un serveur local python sur le port 8000. Cela nous assure d’être sûr que l’erreur vient de nous et pas du apache si erreur il y a.
server@INFRA01:~$ python3 -m http.server 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [05/May/2022 17:45:05] "GET / HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2022 17:45:10] "GET / HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2022 17:45:12] "GET / HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2022 17:45:14] "GET / HTTP/1.0" 200 -
127.0.0.1 - - [05/May/2022 17:45:20] "GET / HTTP/1.0" 200 -

Maintenant que cela fonctionne du côté nginx, voyons si ça marche avec apache.
Comme nous l’avons dit, notre paramètre Content-Security-Policy n’est pas correctement configuré et est beaucoup trop restrictif. Nous avons cependant pas réussi à faire mieux. Nous avons une solution qui consiste à utiliser le mot-clé unsafe-inline cependant l’anssi nous demande d’interdire ce mot. Dans l’objectif de démonstration nous allons vous montrer le résultat avec et sans ce paramètre.
Lorsqu’on met le parametre interdit, nous obtenons notre page, propre et bien sous tout rapport.

Lorsque nous ne mettons pas le paramètre interdit, nous obtenons notre page, qui semble plus proche du HTML des années 90 qu’à un wordpress…

On peut donc en conclure que les paramètres interdits, c’est bien, ça fait marcher nos sites…mais c’est interdit donc il ne faut pas les utiliser…