← Devlog

23 Janvier 2026 - Security

Il est important d'avoir les mesures de bases en matières de sécurité. Sans aller vers un Fail2Ban version php, ce sera pour plus tard.

Il faut dans un premier temps modifier la configuration afin de rendre possible les tests.

La première brique Auth à déjà était implémenté, tout comme la Session et le CSRF. Ici on va s'intéresser au Rate_limiter et à la gestion des Headers.

Configuration de l'environnement

Ici, je dev sous Docker avec un pipeline Woodpecker, mais le framework doit pouvoir aussi s'utiliser en environnement mutualisé.

Je vais donc créer une classe Env afin de respecter le principe 12-Factor App.

HTTPS

Jusqu'à présent j'était resté en http en local, ici on va devoir tester HSTS (HTTP Strict Transport Security) qui oblige le navigateur à utiliser https. Pour faire ça en local, je vais utiliser un outils que j'utilise déjà depuis un moment mkcert.

Je vais devoir modifier l'implémentation du Request afin que ce soit compatible Reverse proxy (nginx, Traefik, Cloudflare).

Por gérer le cas des serveurs mutualisés, je dois prévoir un fallback et forcer https coté php. Puisque je dispose de Env, je vais passer par le fichier de conf.php.

Vu que la structure du fichier de config à évoluée, j'en profite pour renommer la constante URL en URL afin d'être dans les standard.

URL et DEBUG sont "placée" dans "app"

La sécurité

L'environnement configuré, je viens ajouter de la sécurité dans les headers, que ce soit de base (X-frame-Option, CSP, HSTS) ou le CORS (Cross-Origin Resource Sharing) pour les API. Aussi, j'ajoute la feature de rate limiting qui vise à limité le nombre de requête d'un utilisateur.

Les headers

De base on ajoute certains directives au niveau des headers:

  • X-Frame-Options: protection anti-Clickjacking (interdit l'affichage du site dans une iframe)
  • X-Content-Type-Options: protection anti-MIME Sniffing. Ex: Cacher du JS dans un fichier avatar.jpg.
  • X-XSS-Protection: protection contre le XSS (Cross-Site Scripting - injection de js), obsolète remplacer par le CSP, utile pour les vieux navigateur.
  • Referrer-Policy: gestion de la confidentialité, contrôle du Referer
  • Strict-Transport-Security - HSTS: On force HTTPS - hstspreload.org
  • Content-Security-Policy - CSP: protection contre le XSS

CORS

Cette brique est surtout utile aux API. Je ne vais pas m'en servir tout de suite, mais c'est un indispensable.

Le CORS (Cross-Origin Resource Sharing) est une sécurité du navigateur.

Implémenté via un Middleware, ici on implémente les "Preflight" (requêtes OPTIONS), les headers Access-Control-Allow-* et le Vary: origin (pour le cache).

Preflight?

Les headers Access-Control-Allow-*?

Ces headers sont envoyés par le serveur pour indiquer au navigateurquelles origines, méthodes HTTP et en-têtes sont autorisées pour accéder à la ressource.

  • Access-Control-Allow-Origin: Spécifie quelles origines (ex: https://domain.tld) sont autorisées à accéder à la ressource.
  • Access-Control-Allow-Method: Liste les méthodes HTTP autorisées (ex: GET, POST, OPTIONS)
  • Access-Control-Allow-Headers: Indique quels en-têtes HTTP peuvent être utilisés dans la requête (ex: Authorization, Content-Type).
  • Access-Control-Allow-Credentials: Autorise l’envoi de cookies/credentials avec la requête (nécessite true et une origine explicite, pas *).

Header Vary: Origin ?

Ce header est crucial pour le cache, Il indique au cache (CDN, proxy, navigateur) que la réponse peut varier selon l’origine de la requête (le header Origin).

Sans Vary: Origin, un cache pourrait renvoyer une réponse CORS valide pour domain.tld à un autre site (otherdomain.tld), créant une faille de sécurité.

Rate limiting

Le principe est assez simple: "Une même personne ne peut pas entrer plus de X fois par minute.". Il protège contre le Brute Force, le DDoS. c'est complémentaire au Fail2ban que j'ai l'habitude d'implémenter. Ici, Claude me permet d'avoir cette brique très tôt dans le projet.

Sanitizer

Utile (contre XSS, validation de type et nettoyage de fichier) pour le nettoyage des entrées. Il faut veiller à bien l'utiliser.

Les tests

Les tests unitaires sont ajoutés au fur et à mesure, mais c'est important de réaliser les tests fonctionnels.

Les headers de bases sont-ils présent:

Testons la configuration CORS:

Testons la configuration CORS Preflight:

Gestion de HTTPS:

Fonctionnement du rate limiter:

Le Sanitizer:

Ici beaucoup de configuration dans le fichier de config, ce n'est parfois pas simple suivant ce que l'on veux faire. Je pense qu'il est important d'ajouter très tôt les briques de sécurité, rien n'est imparable, mais si le Framework peut proposer ces options c'est précieux!

Bien je me rapproche de la release v0.1.0-poc, je vais pouvoir m'orienter vers un Admin panel pré-codé afin de faire un CMS!