DEV Community: Lucien Risso Correia

Segurança na era da IA - como os ataques mudaram e como se defender

Lucien Risso Correia — Fri, 13 Nov 2026 17:26:08 +0000

Janeiro de 2024, escritório da Arup em Hong Kong. Um funcionário do financeiro recebe um e-mail do CFO, que fica em Londres, pedindo uma transação confidencial. Ele desconfia: parece phishing. Aí vem o convite para uma videochamada. Na tela estão o CFO e outros colegas que ele conhece, com rosto e voz de sempre. A dúvida some. Ele faz 15 transferências, cerca de US$ 25 milhões no total, para cinco contas.

Todo mundo naquela chamada, menos ele, era deepfake, montado a partir de vídeos e áudios públicos dos executivos. A fraude só apareceu quando ele falou com a matriz por outro canal.

Não teve malware nem exploit, e nenhum sistema da empresa foi comprometido. O ataque passou por um processo que dependia de "eu vi a pessoa, então é ela". Esse é o padrão da segurança com IA: ela quase não inventa ataque novo, mas deixa os antigos mais baratos, mais rápidos e mais convincentes, e cria uma superfície nova, que são os próprios sistemas de IA que você colocou em produção.

O que a IA mudou para quem ataca

Phishing, engenharia social, exploração de vulnerabilidade e movimentação lateral já existiam. O que mudou foi o custo de cada etapa:

Engenharia social sem erro: o e-mail de phishing com português quebrado acabou. O modelo escreve no tom da empresa, cita o projeto certo (achado no LinkedIn) e responde às perguntas da vítima em tempo real. Clonar uma voz pede poucos segundos de áudio.
Escala: o que antes precisava de um time de operadores agora roda em paralelo, contra dezenas de alvos, sem dormir.
Menos habilidade exigida: quem não sabe escrever um exploit pede para o modelo escrever e corrigir até funcionar.
Velocidade: o tempo entre a publicação de uma CVE e o primeiro exploit funcional encolhe, porque ler o diff do patch e montar a prova de conceito virou trabalho de máquina.

Para quem defende, a consequência prática é direta: qualquer controle que dependia do atacante ser lento, caro ou desleixado perdeu força.

Os ataques que já aconteceram

Vale separar o que é caso real do que é previsão de fornecedor. Os casos abaixo têm relatório público.

Operação conduzida por agente

Em novembro de 2025 a Anthropic publicou o relatório de uma campanha detectada em setembro daquele ano e atribuída a um grupo patrocinado pelo Estado chinês, que ela chamou de GTG-1002. O grupo usou o Claude Code como motor da operação contra cerca de 30 organizações, com um punhado de invasões confirmadas.

Os humanos escolhiam os alvos e aprovavam os passos críticos. O agente fazia o resto: reconhecimento, busca de vulnerabilidades, geração de exploit, coleta de credenciais, escalada de privilégio, movimentação lateral e extração de dados. Para contornar as proteções do modelo, os atacantes quebraram o trabalho em tarefas pequenas e aparentemente inocentes, e se apresentaram como uma empresa de segurança fazendo teste autorizado.

O mesmo relatório traz o limite: o modelo frequentemente exagerava resultados e às vezes inventava dados, como credenciais que não funcionavam. Pesquisadores de fora também questionaram o grau de autonomia alegado. Mesmo com o desconto, o recado fica: um operador com um agente faz o trabalho de uma equipe.

Malware que conversa com um LLM

Em novembro de 2025 o Google Threat Intelligence Group descreveu famílias de malware que chamam um modelo durante a execução:

PROMPTFLUX: um dropper em VBScript que pede ao Gemini, via API, para reescrever o próprio código e escapar de assinatura. Experimental, sem uso confirmado em campanha.
PROMPTSTEAL: usado pelo APT28 contra a Ucrânia. Em vez de trazer os comandos embutidos, pede a um LLM os comandos para coletar dados da máquina. Esse é o caso com uso real confirmado.
PROMPTLOCK: ransomware que gera os scripts em tempo de execução. Chegou a ser noticiado como ameaça ativa, mas era uma prova de conceito de pesquisadores da NYU.

Hoje essas amostras são fracas. O ponto é a direção: malware que não tem o comportamento fixo no binário fica muito mais difícil de pegar por assinatura.

A cadeia de suprimentos mirando ferramentas de IA

Em agosto de 2025, versões maliciosas do Nx, um build system com milhões de downloads semanais no npm, foram publicadas no registro. O ataque ficou conhecido como s1ngularity. O script de instalação procurava CLIs de IA instaladas na máquina (Claude Code, Gemini CLI, Amazon Q) e as chamava com flags que desligam as confirmações, como --dangerously-skip-permissions e --yolo, pedindo para varrer o disco atrás de carteiras, chaves e arquivos .env. O resultado era publicado num repositório no GitHub da própria vítima, usando o gh já autenticado.

Foi o primeiro caso conhecido de um atacante usando o agente de IA do desenvolvedor como ferramenta de reconhecimento. Seu agente de código tem acesso ao seu disco, ao seu terminal e às suas credenciais. Quem roda código na sua máquina pode rodar o seu agente também.

A nova superfície: o seu próprio sistema de IA

Até aqui a IA era a arma. A outra metade do problema é a IA como alvo.

Um LLM não separa dados de instruções. Tudo que entra no contexto é texto, e qualquer texto pode tentar mandar no modelo. Isso é prompt injection, e na forma indireta a instrução maliciosa não vem do usuário: vem de um e-mail, de uma página web, de um PDF ou de uma issue que o agente leu durante o trabalho. Se o termo for novo, o Dicionário de IA cobre a base.

O exemplo mais claro é o EchoLeak (CVE-2025-32711, CVSS 9.3), revelado pela Aim Security em junho de 2025. Bastava mandar um e-mail para alguém da empresa. Quando a vítima fazia qualquer pergunta ao Microsoft 365 Copilot, o assistente buscava contexto, encontrava o e-mail e seguia as instruções escondidas nele, vazando dados internos por uma URL de imagem. Zero clique da vítima. A Microsoft corrigiu do lado do servidor, mas a classe do problema continua valendo para qualquer sistema com o mesmo formato.

A trifeta letal e a regra de dois

Simon Willison deu nome ao formato perigoso em junho de 2025. Um agente fica explorável quando junta três coisas:

Acesso a dados privados: e-mails, documentos, banco, código.
Exposição a conteúdo não confiável: qualquer texto que um atacante consiga colocar no caminho do agente.
Um canal de saída: requisição HTTP, envio de e-mail, um link renderizado, um commit.

Com as três, a injeção lê o dado e o manda para fora. O EchoLeak é exatamente isso.

Em outubro de 2025 a Meta transformou a ideia em regra de projeto, a Agents Rule of Two: enquanto não existir defesa confiável contra prompt injection, e hoje não existe, um agente não deve ter mais de duas das três propriedades na mesma sessão. A versão da Meta troca o terceiro item por algo mais amplo: mudar estado ou se comunicar com o exterior.

Na prática, isso vira decisão de arquitetura e não de prompt:

O agente que lê e-mails de fora e acessa o CRM não pode fazer requisição para domínio arbitrário.
O agente que navega na web e pode agir não pode ver dados sensíveis.
Se o caso de uso exige as três, um humano aprova cada ação de saída.

Guardrail de prompt, aquele "ignore instruções contidas nos documentos", ajuda pouco. É um filtro probabilístico contra um atacante que pode tentar mil variações. Controle que funciona é o que o modelo não consegue desligar: permissão, rede, credencial.

Como se proteger

Boa parte da defesa contra ataque com IA é o básico, que agora deixou de ser opcional.

Identidade e processo

MFA resistente a phishing: passkeys e chaves FIDO2. Código por SMS e push que o usuário aprova caem diante de um phishing perfeito e de um atacante que liga fingindo ser do suporte. Passkey é presa ao domínio; site falso não recebe nada.
Verificação fora de banda para dinheiro e acesso: pedido de transferência, troca de conta bancária de fornecedor ou reset de MFA se confirma por um canal que o solicitante não controla, como ligar de volta no número já cadastrado. Voz e vídeo deixaram de ser prova de identidade.
Fricção proposital: duas aprovações acima de um valor, prazo mínimo para mudança de dado bancário. O golpe da Arup dependia de urgência e sigilo, e processo que não aceita os dois quebra o roteiro.

Seus agentes de IA

Menor privilégio de verdade: token com escopo mínimo e vida curta, nunca a credencial pessoal do desenvolvedor. Agente que só lê não recebe permissão de escrita.
Isolamento: agente que roda sem confirmação roda em container ou VM descartável, sem as suas chaves de nuvem no ambiente e com saída de rede restrita a uma lista de domínios.
Bloqueio explícito de segredo: no Claude Code, por exemplo, regras de deny no settings.json do projeto impedem a leitura de arquivos sensíveis e o uso de comandos de rede, independente do que o modelo decidir:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}

Humano no circuito para o irreversível: deploy, envio para fora, exclusão, pagamento. O agente propõe, a pessoa confirma.
Log de toda chamada de ferramenta: com argumentos, fora do alcance do agente. Sem isso não existe investigação depois.

Cadeia de suprimentos e patch

Lockfile e instalação reprodutível: npm ci no CI, versões fixas, e ignore-scripts onde o projeto aguentar, já que o s1ngularity rodou no script de instalação.
Publicação com proveniência: pacotes internos publicados pelo CI com token de curta duração (trusted publishing), não com token pessoal guardado num .npmrc.
Janela de patch curta: se o exploit sai em horas, o ciclo mensal de atualização ficou largo demais para o que é exposto à internet. Comece pelo perímetro.

IA como defesa contínua

O mesmo ganho de escala vale para o lado de cá. A diferença é usar a IA onde ela amplia o time sem ganhar poder demais.

Achar a falha antes do atacante

Em julho de 2025 o Google anunciou que o Big Sleep, agente do Project Zero com o DeepMind, encontrou a CVE-2025-6965 no SQLite, uma corrupção de memória corrigida na 3.50.2. A inteligência de ameaças do Google tinha sinais de que alguém preparava um zero-day mas não sabia qual era a falha. O agente localizou o bug, e o patch saiu antes da exploração. Segundo o Google, foi a primeira vez que um agente ajudou a frustrar um exploit em campo.

Você não precisa de um Big Sleep para aplicar a ideia no seu código:

Revisão de segurança em todo pull request: um agente lê o diff procurando injeção, autorização faltando, segredo commitado, desserialização insegura. O Claude Code já traz o /security-review, e dá para rodar o mesmo no CI. Ele não substitui o SAST: o SAST acha o padrão conhecido com precisão, e o LLM lê intenção e contexto, achando o endpoint que esqueceu de checar se o pedido é do usuário logado.
Triagem do que o scanner já acha: o problema da maioria dos times não é falta de alerta, é excesso. Usar o modelo para explicar se a CVE da dependência é alcançável pelo seu código corta o ruído de forma relevante.
Red team contínuo do seu próprio agente: uma suíte de prompt injection (documentos, e-mails e páginas com instruções escondidas) rodando no CI a cada mudança de prompt, ferramenta ou modelo. Ferramentas como o promptfoo fazem isso. Trate como teste de regressão: o ataque que passou uma vez vira caso fixo.

Detectar comportamento, não assinatura

A Anthropic não pegou a GTG-1002 por assinatura. Pegou por padrão de uso: sequência de chamadas de ferramenta, ritmo das requisições, persistência da operação entre sessões sem relação. É o mesmo princípio que vale contra malware que se reescreve: se o artefato muda toda hora, o que você monitora é o comportamento.

No seu ambiente, isso significa ter linha de base e alertar no desvio. Uma conta de serviço que nunca listou buckets e de repente lista todos. Um agente de atendimento que passa a gerar URLs para domínios externos. Um desenvolvedor cujo token do GitHub cria repositório às três da manhã.

O SOC com agentes

A divisão de trabalho que funciona hoje:

A IA faz: triagem do alerta, enriquecimento (quem é o usuário, o que o IP já fez, o que mudou no host), correlação entre fontes, resumo do incidente, rascunho do relatório.
O humano faz: decide contenção, isola máquina, desativa conta, fala com o cliente.

O agente do SOC lê log, que é conteúdo controlado pelo atacante. Ele tem acesso a dado sensível. Se também puder agir sozinho, você montou a trifeta letal dentro da sua defesa. Dê ao agente de defesa duas das três propriedades, e a terceira fica com uma pessoa.

Onde colocar o esforço primeiro

Se o orçamento só dá para começar por um lado, a ordem que mais reduz risco é:

Primeiro, identidade e processo: passkeys e verificação fora de banda. Custam pouco, e é por onde a maior parte dos ataques com IA entra, porque engenharia social foi o que mais barateou.
Segundo, os seus agentes: inventário de onde há IA com acesso a dados e ferramentas, e aplicação da regra de dois em cada um. É a superfície que cresce mais rápido e a que menos gente audita.
Terceiro, IA na defesa: revisão de PR e triagem de alerta primeiro, porque devolvem tempo do time sem dar poder de ação ao modelo. Automação de resposta fica por último, quando você já tem log e linha de base para saber o que é normal.

O critério para qualquer decisão no meio do caminho é o mesmo dos dois lados: a IA é ótima para ler, resumir e sugerir, e perigosa quando tem acesso, entrada não confiável e capacidade de agir ao mesmo tempo. Isso vale para o agente que te ataca, para o que você coloca em produção e para o que você usa para se defender.

Modernizando Java legado com IA - o que funciona e o que dá errado

Lucien Risso Correia — Fri, 30 Oct 2026 21:20:09 +0000

Você herdou um sistema. Java 8, Spring 4 com metade da configuração em XML, Hibernate com hbm.xml, um pom.xml com dependências que não recebem atualização desde 2017 e um scanner de segurança apontando dezenas de CVEs. Ninguém do time original está mais na empresa. Não tem teste, ou tem uns vinte que ninguém roda porque metade quebra.

A tentação em 2026 é abrir um agente de IA, apontar para o repositório e pedir "migra isso para Java 21 e Spring Boot 3". Dá para fazer. O resultado compila, às vezes até sobe. E aí, três semanas depois, o financeiro reclama que um relatório está arredondando centavos diferente.

Esse post é sobre como usar IA nesse trabalho sem cair nisso: onde ela rende muito, onde ferramenta determinística é melhor, e o que precisa existir antes de qualquer linha mudar.

O problema real não é o código

Sistema legado não é sinônimo de código feio. Código feio que tem teste e documentação se refatora numa tarde. O que torna um sistema legado difícil é outra coisa:

Conhecimento perdido: regras de negócio que só existem no código, às vezes num if dentro de um service de três mil linhas, sem comentário nem ticket.
Nenhuma rede de segurança: sem teste, qualquer mudança é aposta.
Dependências mortas: bibliotecas abandonadas, versões fora de suporte, APIs do JDK que deixaram de existir.
Medo: ninguém mexe porque ninguém sabe o que quebra, então o sistema envelhece mais rápido.

Repara que digitar código não aparece na lista. O gargalo de uma modernização é entender o sistema, não escrever o código novo. E é justamente aí que a IA mais ajuda, muito mais do que na geração de código em si.

Fase 1: arqueologia

Antes de mudar qualquer coisa, use a IA para ler. Um modelo com janela de contexto grande, rodando como agente dentro do repositório (Claude Code, Cursor, Copilot no modo agente, o que seu time usar), consegue fazer em uma hora o que levaria uma semana de leitura manual.

Coisas que valem pedir, uma por vez:

Mapa de módulos: quais pacotes existem, quem depende de quem, onde estão os pontos de entrada (servlets, controllers, jobs agendados, listeners de fila).
Fluxos de ponta a ponta: "siga o que acontece quando um pedido é cancelado, do endpoint até o banco, e liste cada efeito colateral". Esse tipo de pergunta revela as regras escondidas.
Tradução de configuração: XML do Spring, mapeamentos do Hibernate, web.xml, filtros. A IA explica o que cada bean faz e de onde vem cada injeção.
SQL e stored procedures: muita regra de negócio de sistema antigo mora no banco. Peça a explicação de cada procedure e quais tabelas ela altera.

O resultado dessa fase é documentação: um arquivo por módulo, diagramas em Mermaid, uma lista de regras de negócio encontradas. Revise tudo. A IA vai errar em alguns pontos, principalmente onde o código usa reflexão, configuração externa ou convenção que não aparece no fonte. Mas corrigir um documento errado é muito mais rápido que escrever do zero, e o ato de revisar já te ensina o sistema.

Guarde o que for confirmado num arquivo de contexto do projeto (CLAUDE.md, AGENTS.md ou equivalente). Toda sessão futura do agente começa sabendo o que você já descobriu, em vez de redescobrir e errar de novo.

Fase 2: travar o comportamento atual

Essa é a fase que todo mundo quer pular e a mais importante do post.

Você não vai migrar um sistema sem teste. Mas também não vai escrever testes unitários bonitos para código que você ainda não entende. O que você precisa é de testes de caracterização: testes que registram o que o sistema faz hoje, certo ou errado, e quebram se esse comportamento mudar.

A técnica também é chamada de golden master. Você roda o código atual com um conjunto de entradas, salva a saída, e o teste compara execuções futuras com essa saída salva:

class CalculoFreteCaracterizacaoTest {

    // Entradas reais, anonimizadas, tiradas de produção.
    static Stream<Pedido> pedidos() {
        return CarregadorFixture.ler("fixtures/pedidos.json");
    }

    @ParameterizedTest
    @MethodSource("pedidos")
    void freteContinuaIgual(Pedido pedido) {
        BigDecimal frete = new CalculoFreteService().calcular(pedido);

        // Compara com o valor gravado na primeira execução, contra o código antigo.
        assertEquals(Golden.valor("frete", pedido.getId()), frete.toPlainString());
    }
}

Repara no toPlainString(). Comparar BigDecimal com equals considera a escala (1.0 é diferente de 1.00), e é exatamente esse tipo de diferença que você quer pegar.

A IA é ótima para gerar esses testes em volume. Peça para ela identificar os caminhos de cada método crítico, montar entradas que cubram cada ramo e escrever o teste. Dois cuidados:

O teste trava o comportamento atual, inclusive os bugs. Se o agente "corrigir" algo enquanto escreve o teste, o teste deixa de servir. Deixe isso explícito no pedido.
Rode contra o código antigo primeiro. Todo teste de caracterização tem que passar antes de qualquer migração. Se não passa, ele está errado, não o sistema.

Com isso no lugar, você tem algo que não tinha antes: um jeito de saber se quebrou.

Fase 3: migração mecânica com ferramenta determinística

Agora sim, mudar código. E aqui vai a regra que mais economiza dor de cabeça: o que é mecânico vai para ferramenta determinística, e a IA fica com o que exige julgamento.

Trocar javax.persistence por jakarta.persistence em quatrocentos arquivos não exige inteligência. Exige consistência. Um LLM fazendo isso arquivo por arquivo vai acertar 98% e errar 2% de forma diferente a cada vez. Uma ferramenta de refatoração baseada em AST acerta 100%, ou falha de um jeito previsível.

A ferramenta padrão para isso no mundo Java é o OpenRewrite. Ele trabalha sobre a árvore sintática com tipos resolvidos, não sobre texto, e vem com receitas prontas para os saltos mais comuns:

<plugin>
    <groupId>org.openrewrite.maven</groupId>
    <artifactId>rewrite-maven-plugin</artifactId>
    <version><!-- versão atual no Maven Central --></version>
    <configuration>
        <activeRecipes>
            <recipe>org.openrewrite.java.migrate.UpgradeToJava21</recipe>
            <recipe>org.openrewrite.java.migrate.jakarta.JavaxToJakarta</recipe>
        </activeRecipes>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-migrate-java</artifactId>
            <version><!-- versão atual --></version>
        </dependency>
    </dependencies>
</plugin>

mvn rewrite:dryRun   # gera um patch em target/rewrite/ sem tocar no código
mvn rewrite:run      # aplica

Para Spring Boot existe a família de receitas UpgradeSpringBoot_3_x no módulo rewrite-spring. Confira com mvn rewrite:discover quais estão disponíveis na versão que você instalou, porque a lista cresce a cada release.

Outra opção, se você está na AWS, é o Amazon Q Developer, que faz o salto de Java 8, 11 ou 17 para 17 ou 21 combinando receitas determinísticas com IA. A limitação prática é que o projeto precisa buildar com Maven, então projeto em Ant ou Gradle fica de fora.

Rode a migração em passos pequenos, um salto por vez, com os testes de caracterização entre cada um. Java 8 para 11 é um salto com problemas próprios (os módulos de JAXB, JAX-WS e CORBA saíram do JDK no 11). De 11 para 17 o encapsulamento forte das APIs internas do JDK quebra bibliotecas que usavam reflexão. De 17 para 21 costuma ser tranquilo. Fazer tudo de uma vez transforma três problemas conhecidos em um problema misterioso.

Fase 4: a IA no que sobra

As receitas cobrem talvez 70 a 80% do trabalho. O resto é onde a IA brilha:

Bibliotecas abandonadas: aquela lib de geração de PDF que parou em 2016 e não tem versão compatível. A IA sugere substitutos e reescreve as chamadas.
APIs removidas sem substituto direto: Nashorn saiu no Java 15, o SecurityManager foi depreciado no 17 e desativado de vez no 24. Código que dependia disso precisa ser repensado, não traduzido.
Erros de compilação e de runtime pós-migração: cole o stack trace, deixe o agente investigar. Ele lê o código ao redor, o changelog da dependência, e propõe a correção.
Código reflexivo e configuração por convenção: onde o OpenRewrite não enxerga porque a referência está numa string.

O fluxo que funciona com agente é sempre o mesmo loop curto:

Uma tarefa pequena e bem definida ("faça o módulo de faturamento compilar no Java 17").
O agente edita.
Build e testes de caracterização rodam, de preferência pelo próprio agente.
Você revisa o diff antes de aceitar.
Commit. Próxima tarefa.

PRs pequenos não são preciosismo, são a única forma de a revisão humana continuar funcionando. Um diff de três mil linhas gerado por IA não é revisado, é aprovado. E aprovar sem revisar é como os bugs silenciosos chegam em produção.

Fase 5: modernizar de verdade

Compilar no Java 21 não é modernizar, é só sair da zona de risco. Depois que o sistema está estável na versão nova, vem a parte que melhora o código.

Um exemplo típico: um DAO com JDBC cru, do jeito que se escrevia em 2012.

public List<Cliente> buscarAtivos() {
    List<Cliente> lista = new ArrayList<Cliente>();
    Connection conn = null;
    PreparedStatement ps = null;
    ResultSet rs = null;
    try {
        conn = dataSource.getConnection();
        ps = conn.prepareStatement("SELECT id, nome, email FROM cliente WHERE ativo = 1");
        rs = ps.executeQuery();
        while (rs.next()) {
            Cliente c = new Cliente();
            c.setId(rs.getLong("id"));
            c.setNome(rs.getString("nome"));
            c.setEmail(rs.getString("email"));
            lista.add(c);
        }
    } catch (SQLException e) {
        throw new RuntimeException(e);
    } finally {
        // três blocos try/catch fechando rs, ps e conn
    }
    return lista;
}

Com um record e o JdbcClient do Spring 6.1:

public record Cliente(Long id, String nome, String email) {}

public List<Cliente> buscarAtivos() {
    return jdbcClient.sql("SELECT id, nome, email FROM cliente WHERE ativo = 1")
            .query(Cliente.class)
            .list();
}

Esse tipo de reescrita a IA faz muito bem, e o teste de caracterização garante que a lista devolvida continua igual. Mas tenha critério: record é imutável, então se algum lugar do sistema chama setNome no objeto devolvido, a troca quebra. É o tipo de coisa que você pede para o agente verificar antes, com uma busca por todos os usos.

Vale o mesmo para os outros recursos novos. Pattern matching e sealed ajudam onde existe hierarquia de tipos com instanceof espalhado. Virtual threads ajudam em código que bloqueia muito em I/O. Nenhum deles precisa estar em todo lugar só porque existe.

Para extrair partes do monólito, o padrão continua sendo o strangler fig: um módulo novo assume uma fatia do comportamento, o tráfego migra aos poucos, o código antigo morre por último. A IA ajuda a sugerir onde cortar, mapeando quais classes conversam entre si e quais tabelas cada fluxo toca. A decisão de onde fica a fronteira é sua, porque depende de coisas que não estão no código: time, deploy, quem é dono de qual regra.

Onde dá errado

Os problemas que aparecem quase sempre:

API alucinada: o modelo usa um método que existe em outra versão da biblioteca, ou que nunca existiu. O compilador pega a maioria. Os que passam costumam estar em código chamado por reflexão ou em configuração.
Mudança silenciosa de comportamento: o código compila, os testes unitários passam, e o resultado mudou. Os suspeitos clássicos são BigDecimal com escala diferente, equals e hashCode reescritos, fuso horário na troca de Date para java.time, e charset. Desde o Java 18 o charset padrão é UTF-8 em qualquer sistema operacional, então um new String(bytes) que rodava em Windows com Cp1252 passa a ler diferente. É exatamente para isso que existe a fase 2.
Ordem de iteração: código que dependia, sem saber, da ordem de um HashMap ou HashSet. A ordem nunca foi garantida, mas o código funcionava por coincidência e para de funcionar quando a implementação muda.
Diffs gigantes: já falei, mas repito porque é o erro mais comum. Agente com tarefa grande produz diff grande, e diff grande não é revisado.
Código proprietário saindo da empresa: mandar o código-fonte para uma API externa é decisão de compliance, não de desenvolvedor. Verifique o contrato do provedor (retenção de dados, uso para treino), e se o sistema processa dados pessoais, a LGPD entra na conversa. Muitas empresas resolvem com planos corporativos ou modelos rodando em nuvem própria.

Por onde começar amanhã

Rode um agente em modo só leitura e gere a documentação dos módulos. Revise e guarde no arquivo de contexto do projeto.
Escolha os cinco fluxos que mais doem se quebrarem e escreva testes de caracterização para eles.
Confirme que esses testes passam no código atual.
Configure o OpenRewrite e rode rewrite:dryRun só para ver o tamanho do patch.
Migre um salto de versão por vez, com os testes entre cada um.
Use a IA no que sobrar das receitas, sempre em tarefas pequenas, com build e teste no loop.
Revise todo diff. Se está grande demais para revisar, a tarefa estava grande demais.
Só depois de estável na versão nova, modernize o código de verdade.

O trade-off no fim é simples. A IA reduz drasticamente o custo de entender e de reescrever, mas não reduz em nada o custo de errar em produção. Se você não tem como saber que algo quebrou, a velocidade da IA só te leva mais rápido para o problema. Invista o tempo economizado na rede de segurança, e a migração que antes levava um ano de medo cabe em alguns meses de trabalho controlado.

CSRF - Cross-Site Request Forgery

Lucien Risso Correia — Mon, 03 Aug 2026 14:07:06 +0000

Se você já criou um formulário no Laravel, com certeza esbarrou naquela diretiva @csrf que a gente coloca sem nem pensar muito. Mas você já parou pra pensar o que ela realmente faz e por que, se você esquecer dela, o Laravel te devolve um belo de um erro 419 Page Expired? Pois é, tudo isso gira em torno de um ataque chamado CSRF, e é sobre ele que vamos falar.

O que é CSRF?

CSRF significa Cross-Site Request Forgery, ou "falsificação de requisição entre sites". A ideia do ataque é simples e por isso mesmo perigosa: fazer o navegador da vítima enviar uma requisição para um site no qual ela já está autenticada, sem que ela perceba.

O ponto central que torna esse ataque possível é o comportamento dos cookies no navegador. Quando você faz login em banco.com, o servidor te devolve um cookie de sessão. A partir daí, toda requisição que o seu navegador fizer para banco.com vai levar esse cookie junto, automaticamente. E aqui está o pulo do gato: o navegador não liga de onde a requisição partiu. Se um site totalmente diferente disparar uma requisição para banco.com, o cookie de sessão vai junto do mesmo jeito.

Como o ataque funciona na prática

Imagina que o seu banco tem um endpoint de transferência que funciona assim:

<form action="https://banco.com/transferir" method="POST">
    <input type="text" name="valor">
    <input type="text" name="destino">
    <button>Transferir</button>
</form>

Você está logado no seu banco em uma aba. Em outra aba, você abre um site qualquer que recebeu de um e-mail suspeito. O que você não sabe é que esse site malicioso tem escondido nele algo assim:

<form action="https://banco.com/transferir" method="POST" id="ataque">
    <input type="hidden" name="valor" value="10000">
    <input type="hidden" name="destino" value="conta-do-atacante">
</form>

<script>
    document.getElementById('ataque').submit();
</script>

Quando a página carrega, o JavaScript envia o formulário sozinho. O navegador faz a requisição para banco.com, e como é uma requisição para o domínio do banco, ele anexa o seu cookie de sessão automaticamente. Do ponto de vista do servidor do banco, é uma requisição perfeitamente autenticada, vinda de um usuário logado. E lá se vão os seus dez mil.

O nome "falsificação de requisição entre sites" faz todo sentido: um site (o malicioso) forja uma requisição que parece ter vindo de você para outro site (o banco).

Qual o objetivo de se proteger contra isso?

O objetivo da proteção CSRF é garantir que uma requisição que altera estado (um POST, PUT, PATCH ou DELETE) tenha realmente partido da sua aplicação, e não de um terceiro se aproveitando da sessão ativa do usuário.

Repara que o problema não é autenticação. A vítima está autenticada de verdade, o cookie é legítimo. O problema é a intenção: como o servidor prova que foi o usuário quem, de fato, quis fazer aquela ação, e não um site externo agindo por baixo dos panos? É exatamente esse buraco que o token CSRF fecha.

Como o Laravel resolve isso

A estratégia usada pelo Laravel (e pela maioria dos frameworks) é o padrão do token sincronizador. A lógica é a seguinte: para cada sessão de usuário, o Laravel gera um token secreto e aleatório. Esse token fica guardado na sessão, no lado do servidor.

Toda vez que você gera um formulário, precisa embutir esse mesmo token dentro dele. É aí que entra a diretiva @csrf:

<form method="POST" action="/perfil">
    @csrf
    <input type="text" name="nome">
    <button>Salvar</button>
</form>

Essa diretiva simplesmente expande para um campo escondido com o token:

<input type="hidden" name="_token" value="a-string-aleatoria-e-secreta-da-sessao">

Quando o formulário é enviado, o middleware VerifyCsrfToken entra em ação. Ele compara o _token que veio no corpo da requisição com o token guardado na sessão. Se os dois baterem, a requisição segue. Se não baterem, ou se o token não vier, o Laravel barra tudo com aquela resposta 419.

E por que isso funciona? Porque o site malicioso não tem como saber qual é o seu token. Ele está guardado na sua sessão e só é entregue nas páginas que o próprio banco renderiza pra você. Por conta da Same-Origin Policy, o site do atacante não consegue ler o conteúdo das páginas de banco.com para roubar o token. Sem o token correto, a requisição forjada morre no middleware.

Onde o token é verificado

No Laravel moderno, o middleware VerifyCsrfToken já vem ativado por padrão no grupo web. Você não precisa configurar nada pra ele funcionar, ele simplesmente está lá protegendo suas rotas.

Vale reforçar: a verificação só acontece em métodos que alteram estado (POST, PUT, PATCH, DELETE). Requisições GET não são verificadas, e nem deveriam ser, já que por convenção GET não muda nada no servidor. Essa é justamente a razão de nunca colocarmos ações destrutivas atrás de um simples link GET.

E quando é uma requisição via JavaScript?

Nem sempre a gente usa formulário tradicional. Quando você faz uma chamada AJAX ou usa Axios, não tem um @csrf no HTML. Nesses casos, o Laravel também disponibiliza o token de outras formas.

Uma opção clássica é colocar o token em uma meta tag no <head>:

<meta name="csrf-token" content="{{ csrf_token() }}">

E então mandar ele no cabeçalho da requisição:

const token = document.querySelector('meta[name="csrf-token"]').content;

fetch('/perfil', {
    method: 'POST',
    headers: {
        'X-CSRF-TOKEN': token,
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({ nome: 'Lucien' }),
});

O middleware sabe procurar o token tanto no campo _token do corpo quanto no cabeçalho X-CSRF-TOKEN. Se você usa Axios com o starter kit do Laravel, boa parte disso já vem configurada automaticamente, inclusive a leitura do cookie XSRF-TOKEN que o framework envia.

E as APIs? Precisam de token CSRF?

Essa é uma dúvida comum. APIs stateless, autenticadas por token (tipo Sanctum com tokens de acesso ou JWT), não precisam de proteção CSRF. E o motivo é direto: CSRF só é um problema quando a autenticação depende de algo que o navegador envia sozinho, como o cookie de sessão.

Quando a autenticação é feita por um header Authorization: Bearer <token>, o navegador não anexa esse cabeçalho automaticamente. O site malicioso teria que conhecer o token e adicioná-lo na mão, e se ele já tem o token, o CSRF é o menor dos seus problemas. Por isso as rotas do arquivo de API do Laravel ficam fora do middleware web e não passam pela verificação de token.

O cuidado com CSRF vale principalmente para aplicações que usam sessão baseada em cookie, que é o caso da maioria das aplicações web tradicionais com Blade.

Resumindo

CSRF é um ataque que abusa do fato de o navegador enviar seus cookies de sessão automaticamente, permitindo que um site malicioso forje requisições autenticadas em seu nome. A defesa é o token sincronizador: um segredo que só a sua aplicação conhece e que precisa acompanhar toda requisição que altera estado.

No Laravel isso é praticamente transparente pra gente. Basta lembrar do @csrf nos formulários e mandar o token nos cabeçalhos das requisições via JavaScript, que o middleware VerifyCsrfToken cuida do resto. Da próxima vez que aparecer aquele 419 Page Expired, você já sabe: alguém esqueceu de mandar o token.

Property Hooks no PHP 8.4

Lucien Risso Correia — Tue, 08 Oct 2024 19:55:12 +0000

O PHP 8.4, lançado em 21 de novembro de 2024, trouxe um recurso muito aguardado pela comunidade: os property hooks! Inspirado por outras linguagens como C#, Swift e Kotlin esse novo recurso tira a gambiarra dos métodos mágicos __set() e __get().

Vou mostrar um exemplo de como faz atualmente para termos getter e setters sem precisar criar a propriedade como privativa e criar dois novos métodos com nomes diferentes da propriedades.


class Foo
{
    private String $bar;

    public function __set($name, $value)
    {
        $this->$name = $value . "!!!"; 
    }

    public function __get($name)
    {
         return "!!!" . $this->$name;
    }
}

Usando o __get() e __set() consigo deixar o $bar público quando defino valor e quando busco o valor, porém com implementação diferente e sem ter que criar métodos com nomes distintos da propriedade. Em exemplo visual ficaria assim o uso:


$foo = new Foo();

$foo->bar = "new release";
// aqui o valor que ficará salvo seria "new release!!!"

echo $foo->bar; // aqui retornaria "!!!new release!!!"

Agora imagine como ficaria o __get() e __set() com outras propriedades, uma confusão total. Outra maneira de fazer isso seria criando um método getBar() e um outro setBar(), mas isso considerando apenas uma propriedade e no uso ficaria diferente do anterior:

class Foo
{
    private String $bar;

    public function setBar($value)
    {
        $this->bar = $value . "!!!"; 
    }

    public function getBar()
    {
         return "!!!" . $this->bar;
    }
}

$foo = new Foo();

$foo->setBar('new release');
// aqui o valor que ficará salvo seria "new release!!!"

echo $foo->getBar(); // aqui retornaria "!!!new release!!!"

Eu particularmente acho meio chato criar novos métodos para esse caso de uso, prefiro muito usar a chamada direta da propriedade tanto para pegar quando definir seu valor. Esse novo recurso chega para resolver essa bagunça e permitir definir o get e set individualmente junto com a declaração na classe.


class Foo
{
    public string $bar {
        set(string $value) => $value . "!!!";
        get => "!!!" . $this->bar;
    }
}

Esse novo código faz a mesma coisa, só que direto na propriedade, sem criar novos métodos nem usar __get() e __set(), que precisam de tratamento para cada propriedade da classe. Na forma curta do set, o valor da expressão é o que fica gravado na propriedade.

Para ver todos os detalhes, como hooks em interfaces e propriedades virtuais, leia a documentação oficial de property hooks.

Laravel 11

Lucien Risso Correia — Tue, 12 Mar 2024 12:22:45 +0000

Laravel 11 chegou com algumas mudanças que posso dizer "finalmente" e umas outras "pra que isso?".

Controller simplificado

O controller base foi simplificado e não estende mais o Controller interno do Laravel, sendo assim quando precisar do AuthorizesRequests ou do ValidatesRequests precisará adicionar a cada controller que for utilizar.

Rate limit em segundos

Agora é possível definir rate limits em segundos em vez de minutos, utilizando o Limit::perSecond().

Novos comandos de criação do artisan

Agora temos comando para criação de class, enum, interface e trait:

php artisan make:class
php artisan make:enum
php artisan make:interface
php artisan make:trait

Helper once

Agora você pode cachear um retorno de função e sempre ter o mesmo retorno nas chamadas subsequentes:

function random(): int
{
    return once(function () {
        return random_int(1, 1000);
    });
}

random(); // 123
random(); // 123 (cached result)
random(); // 123 (cached result)

Menos arquivos padrões

Se olhar a pasta app/Http vai ver somente o controller agora, sem o Kernel.php e a pasta Middlewares.

Campo 'password' pode ser com outro nome agora

Finalmente, depois de anos de espera os Devs BRs que caíram num projeto que o banco é em português poderão utilizar o nome da coluna senha na tabela de usuario como 'senha' em vez de 'password'. O método getAuthPasswordName() foi adicionado ao Authenticatable permitindo alterar o nome da propriedade da senha.

Migrations de alterações ficaram mais chatinhas

Agora toda vez que alterar uma coluna pela migration precisará reescrever todas as alterações anteriores novamente para não voltar ao padrão. Digamos que na criação foi adicionado um comentário na coluna, e em uma migration posterior você altera para ter um valor padrão, para não perder o comentário terá que chamar o método novamente ou irá voltar para o padrão que é sem comentário. Particularmente achei isso ruim.

MariaDB

Agora o Laravel possui um driver específico pro MariaDB, em vez de utilizar o driver do MySQL agora pode utilizar o mariadb nas configurações do banco. O que isso muda por enquanto é em relação ao uuid, mas futuramente deverá ter mais coisas específicas pro banco.

Carbon 3

Agora o Laravel suporta tanto o Carbon 2 quanto o Carbon 3, é só atualizar nas dependências do composer e fazer os ajustes conforme a documentação do Carbon no que precisar.

Registro de Providers

Agora o registro de providers foi movido para o arquivo bootstrap/providers.php e retirado do config/app.php. Para packages que criavam arquivos nessa pasta agora é preciso atualizar o método para o ServiceProvider::addProviderToBootstrapFile().

Essas são as mudanças que achei interessante comentar, pra saber de todas é só ler o release notes e o upgrade guide na documentação do Laravel.

Gerência de Estado no Flutter

Lucien Risso Correia — Mon, 05 Feb 2024 20:09:48 +0000

O ano era 2021 e a comunidade Flutter estava agitada demais com algumas tretas envolvendo o time do Flutter e desenvolvedores da comunidade, nessa mesma época o tal state management estava no hype de assuntos da comunidade. Na época escrevi um texto tirando sarro dessas polêmicas e satirizando os principais packages de gerenciamento de estado do Flutter.

Em projetos futuros a esse texto ainda continuou a discussão sobre qual package utilizar para isso, e a treta sempre foi grande. Chegamos em 2024 e sinto que isso deixou de ser uma rixa e finalmente os devs Flutter entenderam que no final tudo é Streams ou Observers, ou talvez não...

Observer

O Observer Pattern, também conhecido como Publish/Subscribe, é um padrão de design que define um mecanismo de comunicação entre objetos. Nesse padrão, um objeto, chamado Subject, mantém uma lista de objetos Observers que dependem dele. Quando o estado do Subject muda, ele notifica todos os Observers, que podem então atualizar suas próprias interfaces.

No Flutter esse padrão é implementado no ChangeNotifier, onde se pode criar uma classe com as propriedades desejadas pro estado que quer gerenciar e métodos que manipulam e notificam a mudança de estado pros Observers. Veja um exemplo de uso básico de gerenciamento de estado com Observer em Flutter:

class MyState extends ChangeNotifier {
  int count = 0;

  void incrementCount() {
    count++;
    notifyListeners();
  }
}

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  MyState state = MyState();

  @override
  void initState() {
    super.initState();
    state.addListener(() {
      setState(() {});
    });
  }

  @override
  Widget build(BuildContext context) {
    return Text('Count: ${state.count}');
  }
}

Nesse exemplo, a classe MyState é um Subject. Ela define uma interface para registrar e remover Observers (o método addListener()) e notifica os Observers quando seu estado muda (o método notifyListeners()).

A classe MyWidget é um Observer. Ela se registra como um Observer da classe MyState no método initState(). Quando o estado da classe MyState muda, o método update() da classe MyWidget é chamado, o que faz com que o widget seja reconstruído.

Com o Provider podemos simplificar a parte de widget e retirar a parte de implementação do trecho do initState, já que o próprio widget dele já faz essa reconstrução quando recebe notificação que o estado mudou. Com isso temos pequenas mudanças no código de widget e ele ficaria assim:

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider(
      create: (_) => MyState(),
      child: Consumer<MyState>(
        builder: (context, state, child) {
          return Column(
            children: [
              Text('Count: ${state.count}'),
              ElevatedButton(
                onPressed: state.incrementCount,
                child: Text('Incrementar'),
              ),
            ],
          );
        },
      ),
    );
  }
}

Lembre-se: o Provider tem como foco ser uma biblioteca para injeção de dependência utilizando a arvore de widgets, a classe Consumer auxilia no uso das dependências injetadas no contexto de Widget, o foco do Provider não é gerenciar estado.

Stream

Stream é uma sequência assíncrona de eventos. Ela pode ser usada para representar dados que mudam ao longo do tempo, como a localização do usuário, a entrada do teclado ou a saída de um sensor.

Um exemplo de uso se Stream para gerenciar estado no Flutter com um contador progressivo que incrementa o valor a cada segundo:

class MyState {
  int count = 0;

  Stream<int> get countStream =>
      Stream.periodic(const Duration(seconds: 1), (_) => count++);
}

class MyWidget extends StatelessWidget {
  final MyState state = MyState();

  @override
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: state.countStream,
      builder: (context, snapshot) {
        if (snapshot.hasData) {
          return Text('Count: ${snapshot.data}');
        } else {
          return Text('Aguardando...');
        }
      },
    );
  }
}

Nesse exemplo usamos o StremBuilder para poder atualizar o widget a cada troca de valor, mas também podemos fazer sem ele com o famoso setState escutando os eventos da Stream com o listen:

class MyWidget extends StatefulWidget {
  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {
  final MyState state = MyState();

  @override
  void initState() {
    super.initState();
    state.countStream.listen((count) {
      setState(() {});
    });
  }

  @override
  Widget build(BuildContext context) {
    return Text('Count: ${state.count}');
  }
}

E é sobre isso que venho lembrar e ajudar a fixar na cabecinha dos devs iniciantes em Flutter: quem gerencia o estado é você e não o package. O que quero lembrar é que independente de está usando BLoC ou MobX, Riverpod ou Solidart, GetX ou setState, o resultado final dependerá de como você escreveu a solução. E se não gostou de nenhuma implementação de Observer dos packages, crie sua própria, no final ou é feito em cima de Stream ou em cima de Observer.

Vou listar qual usa o quê pra exemplificar:

Packages que utilizam Stream:

BLoC
RxDart
GetX

Packages que utilizam Observer:

MobX
ChangeNotifier
Flutter Hooks

Por trás dos panos eles utilizam basicamente a mesma lógica, porém com implementações diferentes que mudam como será escrito o código. Mas igualmente, quem faz o gerenciamento é quem escreve a aplicação em si. Além disso o que ocorre muito é confundirem state managment com dependencie injection, no caso de GetX ou Provider por exemplo, que possuem essa implementação a mais para compor o package e tornar mais completo. São coisas que costumam serem necessitas juntamente porém já não são mais em si state managment.

Bom códigos e best reguards!

Kubernetes: criando seu primeiro Pod

Lucien Risso Correia — Wed, 10 Jan 2024 19:21:21 +0000

Segundo a documentação do Kubernetes um Pod é a menor unidade computacional que você pode criar e gerenciar no Kubernetes. É um encapsulamento de um ou mais containers que utilizam recursos de hardware e rede compartilhados entre si, como se essas aplicações estivessem rodando em uma mesma máquina em servidores VPS por exemplo.

Vamos subir um Pod simples com o nginx primeiramente:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Para aplicar as alterações vamos salvar esse código em um arquivo pod.yaml e rodar o comando do kubectl: kubectl apply -f pod.yaml

Para verificar se terminou certinho podemos rodar kubectl get pods e o resultado deve ser algo parecido com:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          20s

Agora temos um Pod rodando um container que utiliza a imagem do nginx, ou seja, se entrar dentro dele e fizermos uma requisição pro localhost deve retornar a página default do nginx. Para facilitar a visualização vamos permitir o acesso do pod externamente pela porta 8080 com o comando kubectl port-forward pod/nginx 8080:80. O port-forward funciona igual no minikube, sem nenhum comando extra. Com isso podemos ver a página default do nginx acessando localhost:8080