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 sensível aos ataques com menor risco.

Trabalhando somente com arquivos estáticos (HTML, CSS, 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.

Segurança em WordPress Headless

A simples separação do front ao back não exime tratativas necessárias de segurança. Considerar o Headless como uma camada adicional de segurança é preciso pensar no todo. Isto é, simplesmente não usar o WP na interação com o usuário final não nos deixa 100% seguros. Temos outros usuários que trazem riscos a aplicação, os usuários da sua própria empresa; acredite.

Os pontos de atenção para blindar o WP

Você precisa direcionar atenção e esforços a três áreas da aplicação.

• Endpoints da API;
• Mecanismo de login;
• WP-Admin como um todo.

Sobre os Endpoints da API

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 ser direcionados às rotas e 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.

Sobre o mecanismo de login

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ções para tentar decifrar a combinação do login e senha dos usuários. Quando a combinação é descoberta, o acesso à área administrativa é garantido pela porta da frente.

Ações clássicas nos ajudam a blindar o mecanismo de login do WordPress:

• Implementar a autenticação HTTP;
• Implementar a autenticação de dois fatores;
• Implementar reCaptcha;
• Bloquear o acesso para determinados números de IPs;
• Fechar o acesso e liberá-lo somente através de VPN.

Mas é preciso garantir, e principalmente educar, os usuários a fazerem uso de senhas fortes. Caso contrário, nossos esforços serão praticamente em vão.

Sobre o WP-Admin

O WP-Admin em projetos Headless é o WP em si, e temos algumas tratativas importantes 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 dos Endpoints da API.

No WP-Admin estarão os clássicos plugins do WordPress. E como sabemos, nem todos seguem padrões de segurança, portanto, é necessário blindar e aplicar as regras de segurança para garantir uma maior segurança.

Os pontos de atenção além do WP

É importante que fique 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 nos preocuparmos com a segurança nessa camada de interação.

O maior ponto focal precisa ser quanto ao Cross-Site Scripting, conhecido como XSS, um tipo de injeção de códigos, em que scripts maliciosos são injetados em uma página arbitrariamente.

A camada adicional de segurança

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.