Sécurité par construction

Chinaski ne repose pas sur vous pour configurer la sécurité : le comportement sûr est intégré, et le chemin paresseux est le chemin sécurisé. Cette page explique ce que cela signifie : des protections livrées activées, des garde-fous structurels plutôt qu'optionnels, et des notes honnêtes sur ce qui demande quand même un choix conscient.

Des protections qui sont simplement actives

Quatre valeurs par défaut que la ligne d'amorce de cette page nomme : vous obtenez les quatre sans aucune configuration :

Scripts et styles vérifiés: chaque asset d'admin auto-hébergé est contrôlé par hachage (SRI) par le navigateur avant exécution. Une bibliothèque falsifiée est refusée, pas exécutée.
Politique de contenu stricte: chaque réponse d'admin porte une CSP à base de nonce : seuls les scripts marqués par le serveur s'exécutent, rien n'est encadré par d'autres sites, et une liste de fonctionnalités du navigateur non utilisées (caméra, microphone, géolocalisation et compagnie) est désactivée. Aucune configuration ; c'est simplement ainsi que les réponses sont construites.
Aucune confiance dans les IP falsifiées: les limites de débit et les verrouillages vous comptent par une IP client que le serveur peut réellement vérifier. Les adresses fournies par en-têtes ne sont crues que d'un proxy de confiance ; quiconque se connecte directement se voit attribuer sa vraie adresse.
Des verrouillages qui persistent: des connexions échouées répétées verrouillent l'IP source pour des fenêtres croissantes (une minute, puis cinq, puis trente), et le compteur survit aux redémarrages, si bien que redémarrer ne réinitialise pas une attaque.

Des garde-fous qui viennent de la forme du système

Certaines propriétés de sécurité ne sont pas du tout des réglages ; ce sont des conséquences de l'architecture :

Votre site public n'exécute jamais le code du CMS. Le site publié est de simples fichiers servis par votre serveur web ; les connexions, les formulaires et les téléversements se passent sur une surface d'admin séparée. Une vulnérabilité dans l'un ne place pas automatiquement les lecteurs dans le rayon d'explosion.
Pas de JavaScript à l'exécution sur le site public: par construction, pas par promesse. Il n'existe aucun mécanisme pour ajouter un traceur, un beacon ou un script tiers à vos pages ; il n'y a rien à mal configurer.
Les secrets ne sont jamais lisibles en clair. Les identifiants pour l'e-mail, le stockage cloud et les intégrations sont chiffrés dans la base de données avec une clé dérivée du secret maître de l'instance ; même l'API ne les retourne jamais.
Les mots de passe utilisent un hachage moderne et actualisable. Le hachage suit une bibliothèque gérée pour que le schéma puisse être renforcé au fil du temps sans déconnecter personne ni réécrire des comptes.
Les privilèges sont appliqués côté serveur. Les rôles et les restrictions de contenu par utilisateur sont vérifiés sur le serveur pour chaque action privilégiée ; on ne peut pas convaincre le navigateur de les contourner.
Les abus sont bridés partout où ils peuvent se produire : connexion, inscription, récupération de mot de passe, soumissions de formulaires et usage de l'API ont tous des limites par IP ou par clé actives par défaut, avec des ralentissements délibérés pour les requêtes abusives et des URL pot de miel qui consignent les sondes des scanners.
Le serveur tourne en boîte. Le sandboxing systemd rend le système de fichiers en lecture seule hors du répertoire propre de l'application, bloque l'escalade de privilèges et plafonne la mémoire/CPU ; l'installateur définit des permissions de fichiers restrictives dans le cadre de l'installation, pas comme une étape manuelle supplémentaire.
Le secret maître démarre lisible du propriétaire seul. Le fichier qui le contient est créé sans accès groupe ni monde avant que le serveur ne tourne pour la première fois.
Chaque connexion, échec, verrouillage et sonde de scanner est consigné sous une forme structurée et greppable, si bien que « que s'est-il passé » reste répondable après coup.

Des défauts sensibles là où un choix existe

Certaines protections sont des défauts plutôt que des mandats, et cela est énoncé clairement :

La protection antispam des formulaires publics est active pour les nouveaux formulaires (widget de vérification) ; vous pouvez la désactiver par formulaire, mais il faut le choisir.
L'auto-inscription est désactivée. Les gens ne peuvent pas créer leurs propres comptes tant que vous ne l'activez pas.
Les cookies sont Secure, HttpOnly et SameSite avec une durée de vie de 8 heures: les admins sont déconnectés chaque jour par conception.
Le mode Airgap coupe chaque appel sortant que le serveur pourrait jamais faire si votre installation doit pouvoir attester qu'elle ne téléphone à la maison.

Ce que le projet déclare à son sujet

Un positionnement honnête et énoncé (tiré de la documentation propre du projet) :

Il vise en partie les « organisations sensibles à la sécurité … où ce que vous *ne* livrez *pas* compte autant que ce que vous livrez ».
Il « ne téléphone pas à la maison » : pas de télémétrie, pas de validation de licence, pas de dépendances CDN, pas de polices récupérées chez qui que ce soit.
Sa liste de dépendances réduite, stable et empaquetée par l'OS est elle-même la posture de sécurité : moins de parties, plus anciennes et plus lentes à changer signifie une surface d'attaque plus petite que celle d'écosystèmes qui ajoutent des paquets à la centaine.

Le principe de la page est limpide : la personne qui *oublie* de penser à la sécurité est la bénéficiaire par défaut. Rien dans cette liste n'est opt-in, sauf ce qui est délibérément désactivable (le contrôle de bot par formulaire, l'auto-inscription, les commutateurs airgap), et la documentation vous dit lequel est lequel.