Alguns projetos web são potencialmente alvo dos mais variados tipos de ataques.
Uma camada adicional de segurança é sempre requerida em projetos sensíveis a essa temática.
Simplesmente por sua composição, projetos em WordPress Headless tem sido uma camada adicional.
Como o front-end está desacoplado do CMS, temos a parte mais frágil com menor risco.
Trabalhando somente com arquivos estáticos (HTML, CSS e JavaScript) o atacante tem poucas possibilidades para explorar.
Questões como SQL Injection, Full Path Disclosure, upload de arquivos maliciosos, backdoors e vários outros são reduzidas a quase zero.
Isso se deve ao fato de não termos uma linguagem dinâmica, como o PHP, sendo processada no servidor web e conexão direta ao banco de dados.
A simples separação do front do back, não exime tratativas necessárias de segurança.
Para considerar o Headless como uma camada adicional de segurança, é preciso pensar no todo. Isto é, não usar o WP simplesmente na interação com o usuário final, não nos deixa 100% seguros.
Temos outros usuários que trazem riscos para a aplicação, que talvez estejam em sua própria empresa. Acredite.
Você precisa direcionar atenção e esforços para três áreas da aplicação:
Os Endpoints da API são o único caminho para obter informações do CMS. Logo, é uma porta de entrada potencialmente atacada.
Os cuidados devem direcionados às rotas e as tratativas dos parâmetros aceitos.
Considerar uma camada de cache para os resultados às consultas, além de um tremendo ganho de performance também contribui para a segurança. Uma vez que o resultado cacheado não será processado novamente até sua expiração.
O login do WP, assim como de qualquer outra aplicação, é alvo constante de ataques clássicos como o de força bruta.
É um tipo de ação em que o ataque realiza milhares de combinação para tentar decifrar a combinação do login e senha dos usuários.
Quando a combinação é descoberta o acesso a área administrativa é garantido pela porta da frente.
Ações clássicas nos ajudam a blindar o mecanismo de login do WordPress:
Mas é preciso garantir e, principalmente, educar os usuários para fazerem uso de senhas fortes. Caso contrário, nossos esforços serão praticamente em vão.
O WP-Admin em projetos Headless é o WP em si. Temos algumas importantes tratativas a serem consideradas.
Primeiramente a instalação fica em um endereço diferente do endereço público. Mas a descoberta é facilmente feita através da análise às consultas aos Endpoints da API.
No WP-Admin estarão os clássicos plugins do WordPress. Como sabemos, nem todos seguem padrões seguros.
Portanto, é necessário blindar e aplicar as regras de segurança.
É importante ficar claro que as tratativas de segurança a serem aplicadas ao servidor web devem ser seguidas.
Aplicações totalmente construídas com front-end também são passíveis de brechas.
Não é o fato de adotarmos o conceito de WordPress Headless (e não termos o CMS no front) que nos exime de se preocupar com a segurança nessa camada de interação.
O ponto focal maior precisa ser quanto ao Cross-Site Scripting, conhecido como XSS.
XSS é um tipo de injeção de códigos, em que scripts maliciosos são injetados em uma página arbitrariamente.
Projetos que adotam e aplicam o conceito de Headless agregam uma camada adicional de segurança.
Mas como percebemos, nossos esforços de monitoramento e proteção ainda são necessários.
Nesse tipo de projeto é importante pensar que ganhamos um aliado a segurança, mas não uma solução definitiva.
Seu projeto em WordPress está seguro? Pense nisso!
Rodrigo Vieira da Silva 
Leandro Vieira Pinho Rodrigo Vieira da Silva 
