Como o Headless em WordPress tem sido uma camada adicional de segurança

Projetos que adotam e aplicam o conceito de Headless agregam uma camada adicional de segurança. Estamos imunes aos ataques agora?

Seus amigos merecem saber desse conteúdo?

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.

Segurança em WordPress Headless

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.

Os pontos de atenção para blindar o WP

Tela de login do WordPress

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

  1. Endpoints da API;
  2. Mecanismo de login e
  3. 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 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.

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çã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:

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

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.

Sobre o WP-Admin

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.

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

É 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.

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.

Seu projeto em WordPress está seguro? Pense nisso!