Seguridad por construcción

Chinaski no depende de que tú configures la seguridad, el comportamiento seguro viene incorporado, y el camino perezoso es el camino seguro. Esta página explica qué significa eso: protecciones que vienen activadas, salvaguardas que son estructurales en lugar de opcionales, y notas honestas sobre lo que aún requiere una elección consciente.

Protecciones que simplemente están activas

Cuatro defaults que la línea inicial de esta página nombra, obtienes los cuatro con configuración cero:

Scripts y estilos verificados, cada asset de admin self-hosted es verificado por hash (SRI) por el navegador antes de ejecutarse. Una librería adulterada es rechazada, no ejecutada.
Política de contenido estricta, cada respuesta del admin lleva un CSP basado en nonces: solo corren los scripts etiquetados por el servidor, nada es emmarcado por otros sitios, y una lista de features del navegador sin uso (cámara, micrófono, geolocalización y compañía) queda deshabilitada. Sin configuración; así es como se construyen las respuestas.
Sin confianza en IPs falsificadas, los rate limits y lockouts te cuentan por una IP de cliente que el servidor puede verificar de verdad. Las direcciones provistas por headers solo se creen desde un proxy confiable; quien se conecta directamente tiene su dirección verdadera.
Lockouts que persisten, los logins fallidos repetidos bloquean la IP de origen con ventanas crecientes (un minuto, luego cinco, luego treinta), y el conteo sobrevive a los reinicios, así que reiniciar no reinicia un ataque.

Salvaguardas que vienen de la forma del sistema

Algunas propiedades de seguridad no son settings en absoluto, son consecuencias de la arquitectura:

Tu site público nunca ejecuta el código del CMS. El site publicado son archivos simples servidos por tu servidor web; los logins, formularios y subidas ocurren en una superficie de admin separada. Una vulnerabilidad en una no pone automáticamente a los lectores en el radio de impacto.
Sin JavaScript en tiempo de ejecución en el site público, por construcción, no por promesa. No hay mecanismo para añadir un tracker, beacon o script de terceros a tus páginas; no hay nada que malconfigurar.
Los secretos nunca son legibles en texto plano. Las credenciales de correo, almacenamiento cloud e integraciones se cifran en la base de datos con una clave derivada del master secret de la instancia; incluso la API nunca los devuelve.
Las contraseñas usan un hash moderno y actualizable. El hashing sigue una librería administrada de modo que el esquema pueda reforzarse con el tiempo sin desloguear a nadie ni reescribir cuentas.
Los privilegios se aplican del lado del servidor. Los roles y las restricciones de contenido por usuario se verifican en el servidor para cada acción privilegiada; al navegador no se le puede hablar para pasarlos por alto.
El abuso se limita en todas partes donde puede ocurrir: sign-in, registro, recuperación de contraseña, envíos de formularios y uso de la API tienen todos límites por IP o por clave activos por defecto, con ralentizaciones deliberadas para peticiones abusivas y URLs honeypot que registran las sondas de los scanners.
El servidor corre encajonado. El sandboxing de systemd hace el sistema de archivos de solo lectura fuera del directorio propio de la aplicación, bloquea la escalada de privilegios y limita memoria/CPU; el instalador establece permisos de archivo restrictivos como parte de la configuración, no como un paso manual posterior.
El master secret empieza legible solo por su dueño. El archivo que lo contiene se crea sin acceso de grupo ni mundo antes del primer arranque del servidor.
Cada sign-in, fallo, lockout y sonda de scanner queda registrado en una forma estructurada y greppable, así que "qué pasó" es respondible a posteriori.

Defaults sensatos donde existe elección

Algunas protecciones son defaults en lugar de mandatos, y eso se declara con claridad:

La protección de spam en formularios públicos está activa para los formularios nuevos (widget de verificación), puedes apagarla por formulario, pero tienes que elegirlo.
El autorregistro está desactivado. La gente no puede crear sus propias cuentas a menos que lo actives.
Las cookies son Secure, HttpOnly y SameSite con una vida de 8 horas, los admins cierran sesión a diario por diseño.
El modo airgap apaga cada llamada saliente que el servidor pudiera hacer jamás si tu instalación debe poder testificar que no llama a casa.

Lo que el proyecto declara sobre sí mismo

Posicionamiento honesto y declarado (de la propia documentación del proyecto):

Está dirigido en parte a "security-focused organizations … where what you *don't* ship matters as much as what you do."
"No llama a casa": sin telemetría, sin validación de licencia, sin dependencias de CDN, sin fuentes tomadas de nadie más.
Su lista de dependencias pequeña, estable y empaquetada por el OS es en sí misma la postura de seguridad, menos partes, más añejas y de cambio más lento significa una superficie de ataque menor que la de ecosistemas que añaden paquetes de a cien.

El principio de la página es sencillo: la persona que *olvida* pensar en seguridad es la beneficiaria por defecto. Nada de esta lista es opt-in excepto lo que es deliberadamente opt-out-able (el chequeo de bots por formulario, el autorregistro, los toggles de airgap), y la documentación te dice cuál es cuál.