Melhores práticas e soluções de segurança do Laravel para desenvolvedores (2026)

Principais conclusões

• Um ataque ao Packagist ocorrido em maio de 2026 demonstrou que o número da versão, por si só, não é suficiente para garantir que uma instalação do Composer esteja livre de problemas.
• O Laravel 13 tem suporte total, o Laravel 12 recebe apenas correções de segurança e todas as versões anteriores estão no fim do ciclo de vida.
• A vulnerabilidade CVE-2026-48019 afeta todas as versões do Laravel anteriores à 12.60.0, além das versões do Laravel 13 anteriores à 13.10.0.
• A maior parte dos riscos do Laravel está nas opções de exclusão, nas consultas em bruto e nas dependências que ninguém atualizou.

A segurança do Laravel tem menos a ver com o framework e mais com o que acontece depois que você o instala. Uma configuração padrão desativada, uma consulta não filtrada ou uma dependência que ninguém atualizou geralmente já é o suficiente para abrir uma brecha de segurança.

Este guia aborda as ameaças que ainda afetam os ambientes de produção, as práticas para eliminá-las, como proteger suas APIs e o que fazer caso você ainda esteja utilizando uma versão fora de suporte.

Por que a segurança é importante nas aplicações Laravel

Uma única violação pode destruir anos de confiança dos clientes, acarretar responsabilidade legal e entregar aos invasores as credenciais do servidor que dão acesso a todos os outros sistemas que você opera. E a forma de invasão mudou. O Relatório DBIR 2026 da Verizon revelou que a exploração de uma vulnerabilidade é agora o vetor de acesso inicial mais comum para violações, aparecendo em 31% delas, contra 20% no ano anterior, enquanto o uso indevido de credenciais caiu para 13%.

O Laravel, por padrão, já elimina inteiras categorias de problemas. O Eloquent parametriza os valores das consultas, o Blade faz o escape da saída por padrão e o middleware de falsificação de solicitações (request forgery) já vem incluído no grupo “web” sem que ninguém precise solicitá-lo. Nada disso sobrevive se um desenvolvedor decidir desativá-lo, e nada disso abrange autorização, configurações incorretas, falsificação de solicitações no lado do servidor, lógica de negócios ou uma dependência vulnerável. Essas questões continuam sendo de sua responsabilidade, para sempre.

Ameaças comuns à segurança do Laravel

Cross-Site Scripting por meio de saída do Blade sem escape

Blade’s {{ }} sintaxe do Blade faz o escape automático da saída. O {!! !!} não faz isso, e é a que as pessoas costumam usar quando precisam renderizar HTML armazenado em um campo de CMS ou em um editor de texto rico.

Se esse HTML armazenado incluir uma tag de script, ela será executada no navegador de todos que carregarem a página. Limpe-o primeiro no lado do servidor, com uma biblioteca como o HTMLPurifier, antes mesmo que ele chegue a {!! !!}.

Injeção de SQL por meio de expressões não processadas

O Eloquent e o construtor de consultas parametrizam os valores das consultas, de modo que a injeção de código não é uma preocupação para consultas comuns. O problema surge assim que a entrada do usuário é concatenada ao DB::raw(), onde Raw(), havingRaw(), ou orderByRaw().

Os nomes de colunas e de direções costumam ser os mais esquecidos, já que não podem ser passados como parâmetros. Em vez disso, inclua-os na lista de permissões usando uma matriz fixa. Isso também não é algo específico do Laravel. É o mesmo erro que os desenvolvedores de PHP vêm cometendo há vinte anos ao construir consultas SQL com strings.

Falhas na autenticação e no gerenciamento de sessões

A estrutura de autenticação do Laravel é sólida. As falhas ocorrem em torno dela: falta de limitação de taxa no login, tokens de redefinição que nunca expiram, sessões que não são regeneradas após uma alteração de privilégios e fluxos personalizados de alteração de senha que ignoram o `setRememberToken`, deixando as sessões do tipo “lembrar-me” válidas após a alteração da senha. 

Verifique a autorização separadamente da autenticação. Um login funcional que permita que qualquer usuário autenticado acesse /admin é uma vulnerabilidade de autorização, não um bug no formulário de login.

Melhores práticas de segurança do Laravel

1. Mantenha o Laravel e suas dependências atualizados

Executar o composer em modo “outdated” a cada uma ou duas semanas para verificar quais pacotes têm versões mais recentes e, em seguida, execute o `composer update` para baixá-los de acordo com as restrições que você definiu no composer.json. Fique de olho nas notas de lançamento do Laravel e alertas de segurança do GitHub também, pois é lá que uma vulnerabilidade recém-divulgada no framework aparece primeiro.

A política atual do Laravel prevê, para cada versão, 18 meses de correções de bugs e dois anos de correções de segurança a partir da data de lançamento. Também não existe mais o nível LTS. O Laravel 6 foi o último, e os prazos variaram durante a transição das versões menores a cada seis meses para as versões principais anuais; é por isso que as linhas mais antigas abaixo não seguem todas o mesmo padrão.

CVE-2026-48019 ilustra o custo de ficar para trás. Trata-se de uma injeção de CRLF na regra padrão de validação de e-mail do Laravel que, combinada com a forma como o Symfony Mailer e o Symfony Mime tratam certas sequências de caracteres, permite que um invasor não autenticado adultere e-mails enviados, inserindo um cabeçalho Bcc, alterando o conteúdo da mensagem ou transformando o aplicativo em um relé. O comunicado indica que todas as versões anteriores à 12.60.0 estão afetadas, assim como o Laravel 13 até a versão 13.9.0, e as correções foram implementadas nas versões 12.60.0 e 13.10.0. A janela de segurança do Laravel 11 já havia se encerrado em março de 2026; portanto, a versão 11 e todos os ramos anteriores a ela estão dentro desse intervalo sem nenhuma versão corrigida fornecida pelo desenvolvedor original.

Se uma grande atualização não for viável no momento, o Suporte de Ciclo de Vida Ilimitado da TuxCare para Laravel aplica correções de segurança por meio do Composer a versões de referência específicas, atualmente da 5.4.36 à 12.58.0, com outras versões disponíveis mediante solicitação.

2. Trate cada recusa de proteção como uma etapa de revisão de código

Every Laravel security default ships with an escape hatch, and each one deserves a second pair of eyes before it goes out. {!! !!} in Blade turns off output escaping. DB::raw() and whereRaw() accept raw SQL, so any untrusted input has to arrive as a binding rather than concatenated into the string. Model::unguard(), $guarded = [],and Laravel 13’s #[Unguarded] attribute all open mass assignment on every column. 

A proteção contra falsificação de solicitações tem sua própria “saída de emergência”, e a API mudou de lugar. No Laravel 13, você exclui rotas com preventRequestForgery(except: […]) em bootstrap/app.php; nas versões 11 e 12, o mesmo método é chamado como validateCsrfTokens(), e em versões anteriores é usado o propriedade $except na classe de middleware CSRF. Uma rota também pode desativar essa funcionalidade passando a classe de middleware de proteção contra falsificação de solicitação relevante para withoutMiddleware().

Inclua tudo isso em uma verificação de CI baseada no grep e faça com que o autor de qualquer pull request que introduza um desses elementos explique, na descrição, por que ele está lá.

3. Validar no lado do servidor e autorizar separadamente

A validação verifica se os dados estão corretamente formatados. A autorização verifica se esse usuário tem permissão para agir sobre eles. A aprovação em uma não implica nada em relação à outra.

Utilize classes de solicitação de formulário para que as regras de validação fiquem em um local que possa ser revisado, e use Políticas ou Gates para cada ação do modelo. A validação do lado do cliente melhora a experiência do usuário, mas não contribui de forma alguma para a segurança.

4. Proteger a configuração e os segredos

Definir APP_DEBUG=false no ambiente de produção, sem exceção. A própria documentação do Laravel é bem clara quanto ao risco de deixar o modo de depuração ativado: valores de configuração confidenciais podem ser expostos aos usuários finais, e a página de erro de depuração exibe rastreamentos detalhados da pilha para quem quer que tenha causado o erro.

Mantenha .env fora do controle de versão e confirme se a raiz do seu site aponta para /publice atualize a APP_KEY , caso ela já tenha sido enviada ao controle de versão. Todos os valores criptografados e cookies assinados no aplicativo dependem dessa chave; portanto, liste a chave antiga em APP_PREVIOUS_KEYS ao fazer a rotação. Sem ela, os dados criptografados anteriormente não poderão mais ser descriptografados, e todas as sessões autenticadas serão encerradas. 

5. Realizar auditorias de dependências de acordo com um cronograma, e não somente após a ocorrência de incidentes

Executar auditoria do Composer na CI para que um pacote com vulnerabilidades conhecidas falhe na compilação, em vez de aparecer em um relatório trimestral.

composer audit –format=summary

Os pacotes oficiais do Laravel também recebem CVEs. CVE-2026-39976 foi uma falha de contorno de autenticação no laravel/passport, corrigida na versão 13.7.1, na qual um client_credentials pudesse ser mapeado para uma conta de usuário real. Isso só causa problemas se os IDs de cliente UUID estiverem desativados, que é exatamente o tipo de detalhe que se perde quando um scanner apenas informa que um pacote foi sinalizado. Combine a varredura programada com auditorias de segurança e um processo documentado para correção de vulnerabilidades.

Atenção: Nos dias 22 e 23 de maio de 2026, um invasor republicou código malicioso sob tags de lançamento históricas de quatro pacotes Laravel-Lang no Packagist. Todas as tags existentes foram redirecionadas para um novo commit, de modo que o número da versão no seu arquivo composer.json não indicava nada sobre o que realmente havia sido instalado. Para descobrir se você foi afetado, era preciso verificar o commit resolvido no arquivo composer.lock, quando suas compilações eram executadas, e os indicadores de comprometimento publicados na época.

Protegendo as APIs do Laravel

A maioria das APIs é sem estado e baseada em tokens, o que altera o modelo de segurança, em vez de simplesmente enfraquecê-lo. Um token de portador não é anexado automaticamente pelo navegador da mesma forma que um cookie de sessão, de modo que a proteção contra CSRF deixa de ser o controle que realmente importa. O que passa a ter maior importância, em vez disso, é a autenticação, a autorização em cada ação, uma política CORS que alguém realmente tenha configurado, a limitação de taxa e o ciclo de vida do token. Configurações com estado, como o modo SPA do Sanctum, são a exceção, já que utilizam cookies de sessão e precisam de proteção contra CSRF.

No entanto, há realmente uma coisa faltando. Ninguém fica de olho na resposta, então uma enumeração lenta realizada em uma API pode continuar por dias a fio antes que alguém perceba.

Escolha deliberadamente entre o Sanctum e o Passport

O Sanctum lida com a autenticação por token e SPA com configuração mínima e se adapta à maioria das aplicações. O Passport implementa o OAuth2 na íntegra e só faz sentido quando você realmente precisa de fluxos de autorização de terceiros.

A maior área de cobertura do Passport acarreta mais riscos. Seja qual for a sua escolha, defina os tokens com escopo restrito e estabeleça prazos de validade. Um token sem prazo de validade permanece válido até que alguém se lembre de revogá-lo, o que torna muito difícil conter um vazamento.

Limitar a taxa de cada endpoint público

O middleware de limitação de acesso do Laravel tem apenas uma linha de código, e é fácil esquecer de incluí-lo em uma rota da API. Sem ele, os ataques de preenchimento de credenciais e de enumeração ocorrem na velocidade que o servidor permitir.

Limite de taxas por usuário e por IP, com limites mais restritos para login, redefinição de senha e qualquer ação que envie e-mail ou SMS. Retorne um código 429 em vez de apresentar uma falha silenciosa.

Reforce a camada abaixo do seu aplicativo

A segurança de uma API depende inteiramente da segurança do servidor que a hospeda. Implemente o TLS, desative a exibição de diretórios e aplique as atualizações no sistema operacional e no ambiente de execução do PHP independentemente do ciclo de lançamento do Laravel.

A segurança no nível do aplicativo não resiste a um servidor comprometido. Não importa o que você faça na base de código do Laravel, o servidor subjacente precisa ser fortalecido e receber correções de acordo com suas próprias necessidades.

Observação: O Laravel 13 formalizou a proteção contra falsificação de solicitações como PreventRequestForgery, que adiciona uma verificação de origem no cabeçalho Sec-Fetch-Site do navegador, além da validação habitual do token. Uma solicitação da mesma origem é permitida sem um token, e qualquer solicitação que não passe na verificação de origem passa para a validação do token. A documentação do Laravel observa que o cabeçalho só é enviado por HTTPS, portanto, o HTTP simples ainda depende inteiramente do token. Leia o que o middleware realmente verifica antes de isentar qualquer coisa dele.

Fornecedores e soluções de segurança para Laravel

Suporte de ciclo de vida ilimitado da TuxCare

O ELS incorpora correções de segurança em versões do Laravel que a equipe principal já não mantém, disponibilizadas por meio do Composer, de modo que o fluxo de trabalho de dependências não sofre alterações. A TuxCare também oferece suporte a ambientes de execução do PHP em fim de vida (EOL) também, o que é importante quando um aplicativo Laravel mais antigo também está rodando em uma versão do PHP para a qual o desenvolvedor original deixou de fornecer correções.

O ELS não substitui a atualização futura. Trata-se de um suporte de segurança de longo prazo para ramificações cujo desenvolvimento original já não recebe mais correções; assim, você continua recebendo correções de vulnerabilidades (CVEs) para uma ramificação em fim de vida útil (EOL) e pode planejar a migração de acordo com seu próprio cronograma, em vez de seguir o cronograma de terceiros.

Atualmente, oferecemos suporte às seguintes versões do Laravel: 5.4.36, 5.5.50, 5.6.40, 5.7.29, 5.8.38, 6.20.45, 7.30.7, 8.12.0, 8.12.1, 8.12.2, 8.12.3, 8.83.29, 9.52.21, 10, 11, 12.58.0.

Análise de dependências

Comece com composer audit, pois é gratuito e já está instalado. Ele faz a auditoria dos pacotes instalados, portanto, as dependências transitivas também estão incluídas, e o `composer audit –locked` verifica o arquivo de bloqueio quando o diretório `vendor` não está presente. O Snyk, o GitHub Dependabot e o Aikido oferecem, além disso, monitoramento contínuo, alertas e pull requests de atualização automatizadas, o que vale a pena ter quando ninguém está acompanhando a CI de perto. Para uma equipe menor, o Dependabot é uma base razoável. O que nenhum deles resolve é o caso de um pacote em fim de vida (EOL), em que não há uma versão fixa para a qual se possa atualizar.

Proteção e monitoramento em tempo de execução

Um firewall de aplicativos web apenas ganha tempo entre a divulgação da vulnerabilidade e a aplicação do patch, nada mais. O Cloudflare, o AWS WAF e o ModSecurity, quando utilizam um conjunto de regras atualizado, como o OWASP Core Rule Set, podem bloquear muitas cargas de injeção e XSS comuns antes que elas cheguem ao PHP, embora a cobertura dependa inteiramente das regras que você ativar. Combine o firewall com o monitoramento de logs para que uma tentativa de exploração se diferencie de uma solicitação inválida comum.

Proteja aplicativos Laravel com a TuxCare

Manter um aplicativo Laravel dentro de sua janela de suporte é onde as equipes ficam para trás. Atualizações importantes trazem mudanças que quebram a compatibilidade, e elas competem com o lançamento de funcionalidades no mesmo sprint. Se a sua versão já passou do EOL e a migração não vai ocorrer neste trimestre, o Suporte de Ciclo de Vida Ilimitado da TuxCare para Laravel mantém o aplicativo atualizado com os patches até que você esteja pronto para migrar.

Resumo

Nome do artigo

Melhores práticas e soluções de segurança do Laravel para desenvolvedores (2026)

Descrição

Aprenda as melhores práticas de segurança do Laravel para proteger aplicativos contra XSS, CSRF, injeção de SQL e outras ameaças. Um guia prático para desenvolvedores em 2026.

Autor

Claudia Cejas

Nome da editora

TuxCare

Logotipo da editora