OWASP Top 10:2025 explicado para WordPress

O OWASP Top 10 é a lista mais conhecida de riscos de segurança para aplicações web, e a edição de 2025 substitui a lista de 2021. No WordPress, lê-se como um mapa das formas reais de invadir um site: verificações de permissões em falta nos plugins, configurações descuidadas e componentes desatualizados ou abandonados.

Este guia traduz cada um dos dez riscos para a realidade do WordPress e mostra quais deles os donos de sites podem verificar hoje mesmo e quais só os programadores conseguem corrigir no código.

O que é o OWASP Top 10, e o que não é

A lista é publicada pela OWASP Foundation, uma comunidade sem fins lucrativos dedicada à segurança de software. A OWASP descreve-a como «a standard awareness document for developers and web application security» (um documento de referência para sensibilizar os programadores e para a segurança das aplicações web): uma classificação das categorias de risco mais críticas, construída a partir de dados sobre vulnerabilidades e de um inquérito à comunidade.

Não é uma certificação, e nenhum site é «conforme com a OWASP». Serve para decidir por onde começar a procurar. Quem precisar de uma lista detalhada de requisitos que se possam testar encontra-a no Application Security Verification Standard (ASVS), que a OWASP publica para esse fim.

O que mudou em 2025

Em comparação com 2021, o OWASP Top 10:2025 traz duas categorias novas e algumas mudanças de posição:

• A03 Software Supply Chain Failures é nova (falhas na cadeia de abastecimento de software). Alarga a antiga «Vulnerable and Outdated Components» a tudo o que se usa para construir e atualizar o software.
• A10 Mishandling of Exceptional Conditions também é nova (tratamento incorreto de situações excecionais): má gestão de erros, erros de lógica e sistemas que, quando falham, deixam passar («fail open»).
• O server-side request forgery (SSRF) deixou de ser uma categoria própria e passou a fazer parte da A01 Broken Access Control.
• A Security Misconfiguration (configuração de segurança incorreta) subiu do quinto para o segundo lugar.
• A categoria A09 chama-se agora Security Logging and Alerting Failures, um lembrete de que registos que ninguém lê não servem de nada.

Os dez riscos traduzidos para WordPress

Também no WordPress o controlo de acessos deficiente (Broken Access Control) está no topo: o relatório da Patchstack State of WordPress Security in 2026 aponta-o como a categoria de vulnerabilidades mais explorada em 2025. A Patchstack é uma empresa de segurança, por isso convém tratar este dado como vindo de uma fonte bem informada, mas apenas uma.

Cinco riscos que os donos de sites podem verificar hoje

Para estes não é preciso ler código. Cada verificação leva poucos minutos no painel ou com o WP-CLI.

A03: conhecer e atualizar os componentes

A maioria das vulnerabilidades do WordPress está nos plugins e nos temas, não no núcleo. Mantenha um inventário, instale depressa as versões de segurança e apague o que não usa. Este comando lista os plugins com uma atualização à espera:

wp plugin list --update=available --fields=name,version,update_version

O nosso guia sobre plugins WordPress vulneráveis trata em pormenor os plugins abandonados e «nulled».

A02 e A10: esconder os erros dos visitantes

Um site em produção nunca deve mostrar erros nem avisos de PHP, porque revelam caminhos de ficheiros e, por vezes, pormenores da base de dados. No wp-config.php, mantenha a depuração desligada em produção:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Confirme também que o servidor não lista o conteúdo dos diretórios e que não há ficheiros de cópia de segurança nem de exportação acessíveis dentro da raiz web.

A07: proteger todos os inícios de sessão

Ative a autenticação de dois fatores para todos os administradores e editores e limite as tentativas de login falhadas. O nosso guia de autenticação de dois fatores para WordPress explica as opções, das aplicações de autenticação às passkeys.

A08: verificar se os ficheiros são originais

O WP-CLI compara os seus ficheiros com os checksums oficiais do WordPress.org:

wp core verify-checksums
wp plugin verify-checksums --all

Qualquer ficheiro alterado ou desconhecido no núcleo merece uma vista de olhos. Os plugins que não vêm do WordPress.org não podem ser verificados desta forma; compare-os com uma cópia acabada de descarregar do site do fornecedor.

A09: guardar registos e receber alertas

Registe os inícios de sessão, os novos utilizadores, as mudanças de função, as instalações de plugins e as alterações de ficheiros, e garanta que alguém recebe os alertas. Sem estes registos, não consegue saber o que aconteceu depois de um incidente nem cumprir o prazo de notificação de 72 horas do RGPD, descrito no nosso guia sobre violações de dados.

Três riscos que só os programadores podem corrigir

Para quem desenvolve plugins ou temas, A01, A05 e A10 resumem-se sobretudo a algumas funções do WordPress usadas de forma consistente.

• Controlo de acessos (A01): confirme as permissões com current_user_can() antes de qualquer ação privilegiada, valide os nonces com check_ajax_referer() ou wp_verify_nonce() e dê a cada rota REST um permission_callback. Desde o WordPress 5.5, uma rota sem ele gera um aviso (notice); para as rotas que são públicas de propósito, o WordPress recomenda __return_true.
• SSRF (agora parte da A01): quando for buscar um URL indicado por um utilizador, use wp_safe_remote_get(). Esta função valida o endereço e cada redirecionamento e, por omissão, rejeita redes locais e privadas.
• Injeção (A05): construa as consultas com $wpdb->prepare(), sanitize os dados logo à entrada (sanitize_text_field(), absint()) e faça o escape da saída o mais tarde possível (esc_html(), esc_attr(), esc_url()).
• Situações excecionais (A10): verifique is_wp_error() em todas as chamadas que possam falhar e faça com que as verificações de segurança falhem em modo fechado («fail closed»): se uma verificação de permissões ou de licença não puder ser concluída, recuse a ação.

Uma rota REST que segue estas regras tem este aspeto:

register_rest_route( 'myplugin/v1', '/report', array(
    'methods'             => 'POST',
    'callback'            => 'myplugin_save_report',
    'permission_callback' => function () {
        return current_user_can( 'manage_options' );
    },
) );

O capítulo sobre segurança do manual para programadores do WordPress explica cada função com exemplos.

OWASP, RGPD e NIS2

O OWASP Top 10 não é uma lei, mas é uma referência comum para as «técnicas mais avançadas» em segurança web. O art. 32.º do RGPD exige medidas técnicas adequadas e um processo para testar, apreciar e avaliar regularmente a sua eficácia. Testar um site WordPress à luz das dez categorias é uma forma prática de demonstrar esse processo.

Para as organizações abrangidas pela NIS2, o art. 21.º, n.º 2, inclui entre as medidas mínimas a segurança na aquisição, no desenvolvimento e na manutenção, incluindo o tratamento de vulnerabilidades. As categorias A03 e A05 correspondem diretamente a esse dever.

O nosso plugin Security Audit & Compliance associa cada resultado a uma categoria do OWASP Top 10:2025, a par do art. 32.º do RGPD e do art. 21.º da NIS2, para que o relatório mostre a que risco pertence cada problema. O plugin deteta e comunica os problemas; corrigi-los continua a ser uma decisão sua. Veja o que verifica.

Perguntas frequentes

O OWASP Top 10 é uma obrigação legal?

Não. É um documento de sensibilização. Leis como o RGPD exigem uma segurança adequada, e o Top 10 ajuda a perceber o que isso significa para um site.

Tenho de refazer a revisão de segurança por causa da edição de 2025?

Não de raiz. A maioria dos riscos manteve-se; atualize as suas notas com as novas categorias A03 e A10 e com a nova numeração.

O próprio núcleo do WordPress é um grande risco OWASP?

Raramente. A Patchstack contabilizou seis vulnerabilidades no núcleo em 2025, todas de baixa prioridade, contra milhares em plugins e temas. É na sua lista de plugins que está o risco.

Este artigo contém informação geral e não constitui aconselhamento jurídico.