Durcir MonCMS: retour d'experience concret

Publié le 2026-04-13

Pourquoi ce durcissement

Un CMS auto-heberge reste simple a operer, mais la simplicite ne doit pas ouvrir des portes inutiles.

L’objectif de ce chantier etait clair: conserver le flux de publication Markdown tout en reduisant le risque de compromission et d’abus.

1) Suppression de l’acces Docker depuis l’API

Le changement le plus important a consiste a retirer le socket Docker du service API, ainsi que les binaires Docker dans l’image FastAPI.

Concretement:

• plus de montage /var/run/docker.sock dans le conteneur API
• plus de docker/docker-compose installes dans l’image API

Benefice:

• une faille applicative n’offre plus un pont direct vers le moteur Docker de l’hote
• la surface d’escalade de privilege baisse fortement

2) Token de publication rendu strictement obligatoire

Le endpoint POST /publish fonctionnait deja avec un token, mais le durcissement impose maintenant des regles explicites:

• le token est obligatoire au demarrage
• les valeurs faibles connues sont rejetees
• une longueur minimale est imposee

Benefice:

• moins de risque de publication non autorisee par erreur de configuration

3) Garde-fous d’entree sur /publish

Le canal HTTP de publication a ete aligne sur une hygiene minimale de production:

• limite de taille du body (MAX_PUBLISH_BYTES)
• rejet explicite du HTML
• journalisation des rejets et succes (token invalide, payload trop gros, body vide, etc.)

Benefice:

• reduction des risques de saturation (DoS simple)
• politique de contenu plus coherente avec le canal e-mail

4) Protection des routes /notes

Les routes notes restent disponibles pour les usages applicatifs, mais ne sont plus exposees par defaut:

• NOTES_ENABLED=false par defaut
• activation explicite necessaire
• token dedie X-Notes-Token exige quand active

Benefice:

• evite l’exposition accidentelle d’endpoints secondaires

5) Ce que ce durcissement ne fait pas (encore)

Ce lot n’est pas une securite absolue.

Restent utiles a court terme:

• limitation de debit (rate limiting)
• supervision centralisee des logs de securite
• tests automatiques de non-regression securite sur les endpoints de publication

Conclusion

Le point cle est la discipline d’architecture: separer le service expose (API) des capacites d’administration de l’hote.

Avec ces changements, MonCMS garde son ADN (Markdown, simplicite, auto-hebergement) tout en gagnant une base plus saine pour une exploitation durable.