Pular para o conteúdo
Fernando Valler

10 vulnerabilidades que uma IA pode deixar passar em uma aplicação PHP

IA gera e revisa código, mas não enxerga contexto: IDOR, mass assignment, SSRF, race conditions e outras falhas que exigem revisão humana em aplicações PHP.

10 vulnerabilidades que uma IA pode deixar passar em uma aplicação PHP

A inteligência artificial já faz parte da rotina de muitos desenvolvedores.

Hoje é comum utilizar IA para gerar código PHP, criar endpoints, revisar funções, escrever testes, identificar possíveis SQL Injections ou sugerir melhorias de segurança.

E isso é extremamente útil.

O problema começa quando confiamos na IA como se ela fosse uma auditoria de segurança completa.

Uma IA consegue analisar muito bem padrões conhecidos no código. Porém, segurança de aplicações depende de algo que nem sempre está presente no código que enviamos para ela: contexto.

Quem tem permissão para executar determinada ação?

O que acontece quando uma requisição é repetida 100 vezes?

Esse ID pertence realmente ao usuário autenticado?

Esse arquivo pode ser acessado diretamente pelo navegador?

Essa API externa pode ser controlada pelo usuário?

Essa operação pode ser executada duas vezes simultaneamente?

Essas perguntas envolvem arquitetura, infraestrutura e principalmente regras de negócio.

A própria OWASP mantém o Broken Access Control como o risco número 1 do Top 10 de 2025, justamente porque muitas falhas não estão relacionadas a uma linha de código obviamente insegura, mas à forma como o sistema deveria controlar o que cada usuário pode fazer.

Neste artigo, vou mostrar 10 categorias de vulnerabilidades que uma IA pode deixar passar em uma aplicação PHP.

1. IDOR e falhas de autorização

Imagine uma API aparentemente simples:

php
#[Route('/api/clientes/{id}', methods: ['GET'])]
public function show(int $id): JsonResponse
{
    $cliente = $this->repository->find($id);

    return $this->json($cliente);
}

O código pode estar perfeitamente organizado.

A consulta pode estar usando parâmetros corretamente.

Não existe SQL Injection evidente.

Mesmo assim, pode existir uma vulnerabilidade grave.

Imagine que o usuário autenticado seja o cliente 10 e possa simplesmente fazer:

text
GET /api/clientes/11

Se a aplicação retornar os dados do cliente 11 sem verificar autorização, existe uma falha de controle de acesso.

Esse tipo de vulnerabilidade é conhecido como IDOR (Insecure Direct Object Reference) e está diretamente relacionado ao Broken Access Control da OWASP.

O problema é que a IA pode analisar o método e concluir:

“O endpoint está autenticado e o código está correto.”

A pergunta importante não é apenas “O usuário está autenticado?” — é “Esse usuário está autorizado a acessar esse recurso?”

Uma revisão adequada deveria verificar algo semelhante a:

php
if ($cliente->getUsuarioId() !== $usuario->getId()) {
    throw $this->createAccessDeniedException();
}

2. Mass Assignment

Outro problema que pode passar despercebido é a alteração de propriedades que o usuário nunca deveria controlar.

Considere:

php
$user->setData($request->toArray());

Ou, em uma abordagem baseada em atributos:

php
foreach ($request->toArray() as $field => $value) {
    $entity->{$field} = $value;
}

Imagine que a entidade tenha:

php
private bool $admin = false;

O desenvolvedor pode esperar receber:

json
{
    "name": "Fernando"
}

Mas um atacante pode tentar:

json
{
    "name": "Fernando",
    "admin": true
}

Se a aplicação aceitar propriedades que deveriam ser exclusivamente controladas pelo servidor, o usuário pode alterar informações privilegiadas.

Uma IA pode até identificar esse padrão, mas muitas vezes não sabe quais campos são realmente permitidos pela regra de negócio.

É por isso que DTOs e listas explícitas de campos permitidos são importantes.

Por exemplo:

php
final class UpdateUserDto
{
    public function __construct(
        public readonly string $name,
        public readonly string $email,
    ) {
    }
}

Nesse modelo, fica muito mais claro o que pode ser alterado pela requisição.

A OWASP 2025 também relaciona a modificação indevida de atributos controlados dinamicamente à categoria de falhas de integridade de software e dados.

3. SSRF

SSRF significa Server-Side Request Forgery.

É especialmente interessante porque o código pode parecer completamente legítimo.

Por exemplo:

php
$url = $request->get('url');

$response = file_get_contents($url);

À primeira vista, não parece haver um problema.

Mas quem controla url?

Um atacante poderia tentar fazer a aplicação acessar um endereço interno que não deveria estar exposto.

Por exemplo:

text
http://127.0.0.1

ou algum endpoint interno da infraestrutura.

O problema fica ainda mais importante em ambientes cloud, containers e arquiteturas com múltiplos serviços.

A OWASP 2025 incorporou o SSRF ao Broken Access Control, mostrando que esse tipo de vulnerabilidade está intimamente relacionado ao controle sobre quais recursos a aplicação pode acessar.

Uma IA olhando apenas a função pode entender que ela simplesmente “baixa uma URL”.

Um especialista precisa perguntar:

Quais URLs podem ser acessadas pelo servidor?

4. Upload de arquivos

Upload é outro exemplo clássico de funcionalidade aparentemente simples.

php
$file = $request->files->get('file');

$file->move('/var/www/uploads', $file->getClientOriginalName());

A IA pode sugerir melhorias como verificar extensão:

php
$allowed = ['jpg', 'png', 'pdf'];

Mas isso ainda não significa que o upload esteja seguro.

Existem várias outras perguntas:

O MIME type foi validado?

O conteúdo real foi analisado?

O nome do arquivo pode conter ../?

O arquivo será armazenado dentro do diretório público?

Um arquivo PHP pode ser executado pelo servidor?

Um atacante pode enviar um arquivo enorme?

Existe limite de quantidade de arquivos?

O arquivo pode sobrescrever outro?

O upload está sendo processado por alguma biblioteca vulnerável?

Aqui novamente aparece a diferença entre validar uma entrada e proteger uma funcionalidade inteira.

5. Path Traversal

Considere uma funcionalidade para download:

php
$file = $_GET['file'];

readfile('/var/www/uploads/' . $file);

Parece simples.

Porém, se o parâmetro não for corretamente controlado, o usuário pode tentar manipular o caminho.

O problema não é somente o ../ tradicional.

Também é necessário considerar:

  • normalização de caminhos;
  • links simbólicos;
  • arquivos fora do diretório permitido;
  • diferenças entre sistemas operacionais;
  • codificações;
  • nomes de arquivos manipulados pelo usuário.

Uma IA pode sugerir:

php
basename($file);

E isso pode ajudar em determinados cenários, mas não deve ser tratado como uma solução universal.

A pergunta correta é:

Como garantir que o caminho final resolvido permanece dentro do diretório autorizado?

Segurança não deve depender apenas de limpar uma string.

6. Race Conditions

Essa é uma das vulnerabilidades que mais facilmente passa despercebida em uma revisão automática.

Imagine uma aplicação que permite utilizar um cupom somente uma vez:

php
if (!$coupon->isUsed()) {
    $coupon->setUsed(true);
    $order->applyDiscount();
}

Parece correto.

Mas imagine duas requisições simultâneas:

text
Request A → verifica cupom → disponível
Request B → verifica cupom → disponível
Request A → utiliza cupom
Request B → utiliza cupom

O problema não está necessariamente em uma linha “insegura”.

Está na ausência de uma operação atômica ou de um mecanismo adequado de concorrência.

Outros exemplos:

  • duas solicitações de pagamento;
  • transferência de saldo;
  • geração de números sequenciais;
  • resgate de benefícios;
  • criação duplicada de registros;
  • utilização de estoque;
  • processamento de filas.

Uma IA pode revisar o método inteiro e não perceber o comportamento quando duas requisições são executadas ao mesmo tempo.

Esse é um excelente exemplo de vulnerabilidade que exige pensar no comportamento real do sistema.

7. Falta de rate limiting

Imagine um endpoint:

php
#[Route('/api/login', methods: ['POST'])]
public function login(): JsonResponse
{
    // autenticação
}

Do ponto de vista funcional, tudo pode estar funcionando perfeitamente.

Mas quantas tentativas podem ser realizadas?

1 por segundo?

10?

1000?

Não existe limite?

Rate limiting não é apenas uma questão de infraestrutura.

Ele também faz parte do desenho de segurança da aplicação.

O problema pode aparecer em:

  • login;
  • recuperação de senha;
  • envio de e-mail;
  • envio de SMS;
  • geração de códigos;
  • consultas caras;
  • upload;
  • exportação;
  • endpoints que consomem APIs pagas.

No contexto de APIs, a OWASP chama atenção para Unrestricted Resource Consumption, quando uma API não limita adequadamente o consumo de recursos e pode ser abusada para gerar indisponibilidade ou custos operacionais.

Uma IA pode gerar uma implementação funcional de um endpoint sem necessariamente entender quanto aquela operação custa para o sistema.

8. Desserialização insegura

PHP possui mecanismos de serialização e desserialização que podem se tornar perigosos quando dados controlados pelo usuário são tratados como confiáveis.

Um exemplo clássico:

php
$data = unserialize($_POST['data']);

O problema é que o conteúdo foi fornecido externamente.

Dependendo das classes disponíveis e do comportamento dos objetos, isso pode abrir possibilidades perigosas.

O mesmo conceito aparece em aplicações modernas quando objetos são reconstruídos automaticamente a partir de dados externos sem uma validação adequada.

É especialmente importante revisar:

php
unserialize()

bibliotecas de serialização, sistemas de cache, filas, sessões e mecanismos de hidratação automática.

A OWASP classifica a desserialização de dados não confiáveis dentro de Software or Data Integrity Failures.

9. Abuso de regras de negócio

Talvez seja a categoria mais difícil para uma IA detectar.

Imagine uma aplicação que permite:

text
Criar pedido
Cancelar pedido
Solicitar reembolso
Gerar crédito

Cada endpoint pode estar individualmente protegido.

Mas e se o usuário puder fazer:

text
1. Criar pedido
2. Receber crédito
3. Cancelar pedido
4. Manter o crédito

Não existe necessariamente um SQL Injection.

Não existe necessariamente um XSS.

Não existe necessariamente um erro de autenticação.

O problema está na sequência de operações permitidas pelo sistema.

A OWASP API Security Top 10 chama atenção para esse problema em Unrestricted Access to Sensitive Business Flows: algumas APIs podem expor fluxos de negócio que podem ser abusados automaticamente mesmo quando a implementação individual dos endpoints parece correta.

É exatamente o tipo de problema que exige conhecimento do negócio.

A IA pode analisar:

text
POST /pedido
POST /credito
DELETE /pedido

Mas dificilmente entenderá sozinha que a combinação dessas operações cria uma fraude.

10. Configuração insegura

Finalmente, existe uma categoria de problemas que nem sempre aparece no código PHP.

Por exemplo:

APP_ENV=dev
APP_DEBUG=true

Ou:

text
display_errors = On

Ou ainda:

text
DocumentRoot /var/www/projeto/public/..

Outros exemplos:

  • .env acessível publicamente;
  • diretórios de debug expostos;
  • banco de dados acessível pela internet;
  • CORS excessivamente permissivo;
  • cookies sem Secure;
  • cookies sem HttpOnly;
  • sessão mal configurada;
  • permissões de arquivos excessivas;
  • endpoints administrativos expostos;
  • versões antigas do PHP;
  • dependências vulneráveis.

A OWASP colocou Security Misconfiguration como A02 no Top 10 de 2025 e destaca que aplicações modernas dependem cada vez mais de configurações, tornando esse tipo de problema especialmente relevante.

Uma IA pode revisar:

text
src/
config/
templates/

e ainda assim não enxergar:

text
Apache
Nginx
PHP-FPM
Docker
Cloud
Firewall
DNS
TLS
Banco
Variáveis de ambiente
CI/CD

O que todos esses exemplos têm em comum?

Existe um padrão entre essas vulnerabilidades.

Elas dependem menos de:

text
"Essa linha de PHP está errada?"

e muito mais de:

text
"Esse comportamento é permitido neste contexto?"

Esse é um dos principais limites de utilizar IA para segurança.

A IA é excelente em identificar padrões.

Ela pode encontrar:

php
$sql = "SELECT * FROM users WHERE id = " . $_GET['id'];

e apontar uma SQL Injection.

Mas pode ter muito mais dificuldade para perceber:

php
$orderRepository->find($id);

quando o verdadeiro problema é:

O usuário autenticado pode acessar esse pedido?

O código pode estar tecnicamente correto.

A regra de negócio pode estar errada.

Como usar IA de forma mais segura

A solução não é deixar de utilizar IA.

Pelo contrário.

A IA pode ser uma excelente ferramenta para segurança, desde que seja usada como uma camada da revisão, e não como a revisão inteira.

Ao pedir uma análise de segurança, vale fornecer contexto.

Em vez de:

text
"Analise esse código em busca de vulnerabilidades."

experimente:

text
"Analise esse endpoint PHP considerando:

- usuário autenticado;
- regra de acesso por proprietário;
- possibilidade de concorrência;
- abuso por múltiplas requisições;
- validação das entradas;
- exposição de dados;
- regras de negócio;
- integração com serviços externos;
- configuração de produção.

Procure vulnerabilidades reais e explique como poderiam ser exploradas."

Isso muda completamente a qualidade da análise.

Também é importante combinar IA com outras ferramentas e processos:

text
IA
↓
Code Review
↓
Testes automatizados
↓
SAST
↓
Dependency Scanning
↓
DAST
↓
Pentest
↓
Monitoramento

Nenhuma dessas camadas substitui completamente as outras.

Checklist antes de colocar uma aplicação PHP em produção

Antes do deploy, vale fazer pelo menos estas perguntas:

Autorização

  • Cada endpoint verifica autorização além da autenticação?
  • Um usuário consegue acessar recursos de outro usuário alterando um ID?
  • Existem endpoints administrativos protegidos?

Entrada de dados

  • Os dados são validados?
  • Existe proteção contra SQL Injection?
  • Uploads são realmente seguros?
  • Caminhos de arquivos são controlados?
  • Dados externos são tratados como não confiáveis?

API

  • Existe rate limiting?
  • Existem limites de paginação?
  • Existe proteção contra requisições excessivamente caras?
  • Endpoints sensíveis possuem proteção contra automação?

Sessão e autenticação

  • Cookies possuem HttpOnly?
  • Cookies possuem Secure quando aplicável?
  • SameSite está configurado?
  • Recuperação de senha possui expiração e proteção contra abuso?

Infraestrutura

  • APP_DEBUG está desativado?
  • Erros internos estão ocultos do usuário?
  • .env está protegido?
  • Diretórios sensíveis não estão acessíveis?
  • PHP e dependências estão atualizados?

Negócio

  • É possível repetir operações que deveriam ser únicas?
  • Existe proteção contra concorrência?
  • O usuário pode combinar operações para burlar uma regra?
  • Valores financeiros são validados no servidor?

Conclusão

A inteligência artificial mudou a maneira como desenvolvemos software.

Hoje podemos gerar código, testes e até análises de segurança em poucos segundos.

Mas isso não significa que uma aplicação analisada por IA esteja automaticamente segura.

As vulnerabilidades mais interessantes normalmente aparecem justamente onde o código parece correto:

na autorização, na configuração, na concorrência, no abuso de recursos e nas regras de negócio.

Por isso, a melhor estratégia não é escolher entre desenvolvedor e IA.

É utilizar a IA como uma ferramenta adicional dentro de um processo de segurança maior.

Em aplicações PHP, principalmente aquelas que expõem APIs, lidam com dados sensíveis ou executam operações financeiras, a pergunta não deveria ser apenas:

“A IA encontrou alguma vulnerabilidade?”

A pergunta mais importante é:

“O que a IA não tinha contexto suficiente para perceber?”

É nessa segunda pergunta que muitas revisões de segurança começam de verdade.

Referências