Un Headless CMS es a su vez una evolución y una reducción de un CMS clásico: algunos componentes integrales del sistema son retirados para hacerlo compatible con las tareas más diversas. Esto es posible debido a que tanto el frontend como el backend no están vinculados de forma monolítica entre sí.

CMS: Content Management System. Se denomina así a toda herramienta de software orientada a la creación, administración y gestión de contenidos.

Ventajas de un Headless CMS frente a un CMS clásico

En un Headless CMS la tarea de mostrar el contenido gestionado con un CMS en diferentes medios queda relegada a la página web (la vista). Al CMS se le quita el encabezado, por así decirlo (de ahí su nombre). En su lugar se integra una API (Application Programming Interface) a la que pueden acceder las páginas web y las aplicaciones, de forma que los diferentes medios regulan individualmente la presentación del contenido: el backend y el frontendestán desacoplados.

Interfaz

Una API REST es una interfaz sencilla y flexible que emplea métodos HTTP de consulta como PUT, GET, POST y DELETE para comunicarse, por medio de los que un cliente puede acceder a los datos del servidor, solicitarlos o modificarlos. Por lo tanto, REST sigue fundamentalmente el estilo de arquitectura de la Web. Las API REST se construyen en base a estos criterios:

Los servidores facilitan los recursos: Una API REST también está disponible para aplicaciones externas a través de un servidor. Por lo tanto, el acceso no funciona solo de manera local.
Las direcciones identifican elementos: Los diferentes tipos de aplicaciones requieren diversos formatos de archivos. En REST, el URI/URL no toma como referencia a un recurso en un formato determinado, sino al elemento en sí. Mediante la negociación de contenido, los clientes pueden solicitar el elemento en el formato deseado.
Los mensajes son claros y evidentes: Cada mensaje dirigido al servidor es un mensaje cerrado en sí mismo que no hace referencia a uno anterior.
Vinculación de los recursos mediante enlaces: En REST, los objetos están conectados entre sí por medio de hiperenlaces, lo que resulta en una navegación sencilla.

Si se siguen estos principios estructurales, la comunicación entre servidor/API y los diferentes clientes tiene lugar sin problemas, de ahí que la arquitectura REST resulte perfecta para la API de un headless CMS.

Ventajas de la separación del backend y el frontend

La separación resulta útil desde dos perspectivas:

Desarrollo del backend: En este caso se debe a que se desea divulgar contenido en más de una edición, no importa la plataforma a través de la que se distribuyen los contenidos, pues la API REST solo proporciona los datos (JSON), los cuales pueden leerse desde cualquier tipo de frontend independientemente de la tecnología con las que se programen.
Desarrollo del frontend: Los diseñadores web ya no están ligados a las condiciones del gestor de contenidos al igual que el lenguaje de programación tampoco está definido. Esto permite la creación de aplicaciones móviles en diversidad de plataformas. Únicamente han de recibirse y editarse los datos en bruto, ofreciendo un margen más amplio de maniobra en su presentación que con los CMS clásicos.

Otra de las ventajas es la capacidad de realizar solicitudes dinámicas. En los CMS clásicos la consulta de nuevos contenidos en una página web suele hacer que la página se cargue de nuevo. Por el contrario, la API REST entrega datos dinámicos que se pueden integrar en cualquier momento en la estructura de la página sin necesidad de volver a cargar la página entera.

Por tanto, las ventajas se pueden resumir en:

Cantidad ilimitada de frontends.
Posibilidad de combinarse con diversos lenguajes de programación.
Diseño más flexible del frontend.
Continuidad mediante desacoplamiento.
Datos dinámicos.

Formas de asegurar un Headless CMS

En este apartado se muestran varias formas de aumentar la seguridad en un headless CMS:

Utilizar HTTPS para conexiones cifradas (Certificado SSL): HTTPS (Hyper Text Transfer Protocol Secure) es un mecanismo que permite que el navegador o aplicación web se conecte de forma segura a un sitio web. Algunas de las ventajas de usar HTTPS frente a HTTP son:
a) Seguridad.
b) Incremento del factor de posicionamiento en el SEO (Search Engine Optimization).
c) Confianza y credibilidad: Los clientes tendrán más tranquilidad al saber que sus datos están más seguros.
d) Datos de referencia: Los datos de referencia HTTPS a HTTP están bloqueados en Google Analytics. Si los datos pasan de HTTP a HTTPS, sí quedan reflejados.
e) Advertencias de navegadores web: La mayoría de los navegadores comenzaron a marcar todos los sitios que no son HTTPS como No seguros, independientemente de si recopilan datos o no.
f) Rendimiento: Gracias al protocolo HTTP/2, aquellos que ejecutan sitios correctamente optimizados a través de HTTPS pueden incluso ver mejoras en la velocidad. La mejora en el rendimiento se debe a que es capaz de admitir una mejor multiplexación, paralelismo, compresión HPACK con codificación Huffman y la extensión ALPN.
Deshabilitar XML-RPC: Hay algunos complementos que dependen de XML-RPC, pero la mayoría de usuarios no los necesitan y deshabilitar el acceso a XML-RPC aumenta la seguridad. Esto se debe a que los atacantes utilizan el método system.multicall() para ejecutar múltiples métodos dentro de una sola solicitud.
Agregar cabeceras de seguridad HTTP: Los encabezados de seguridad HTTP por lo general se configuran en el nivel del servidor web y le dicen al navegador cómo debe comportarse cuando maneja el contenido de un sitio web. A continuación se listan los más importantes:
a) Content-Security Policy: Content Security Policy (CSP) - HTTP | MDN
b) X-XSS-Protection: X-XSS-Protection - HTTP | MDN
c) Strict-Transport-Security: Strict-Transport-Security - HTTP | MDN
d) X-Frame-Options: X-Frame-Options - HTTP | MDN
e) Expect-CT: Expect-CT - HTTP | MDN
f) X-Content-Type: X-Content-Type-Options - HTTP | MDN
Evitar el uso de hotlinking: El concepto de hotlinking consiste en usar una imagen alojada en Internet poniendo directamente su URL en otro sitio web. Esta imagen se mostrará en el nuevo sitio web, pero se servirá desde la ubicación original. Esto se considera un robo, ya que se está utilizando el ancho de banda del sitio donde está alojada la imagen pudiendo generar muchos costes adicionales sin que pueda darse cuenta hasta que llegue la factura. Esto puede evitarse configurando el servidor que se utilice para que no permitan dichos tipos de enlaces. Por CDN también es posible pero la configuración es específica a cada proveedor.
Apache (.htaccess file) Expand source
El fragmento de código anterior utiliza HTTP, si ha agregado un certificado SSL a su sitio web, asegúrese de ajustar el código para usar HTTPS en su lugar. Este código hace que cualquier imagen enlazada mediante hotlinking no se cargue. Puede cambiar la última línea (http://www.example.com/hotlink.gif) para apuntar a cualquier imagen que desee, esta imagen debería explicar que el enlace mediante hotlinking está deshabilitado en su servidor.
Nginx (configuration file) Expand source
En ambos casos, se debe cambiar yourdomain.com por el dominio que corresponda.

Referencias

Elaboración propia.

Headless CMS: Headless CMS

WordPress REST API Handbook: Authentication – REST API Handbook | Developer.WordPress.org

WordPress Security Guides: Security – Documentation – WordPress.org