Risco de segurança e fraude: uma ameaça, duas equipes

O que é o risco de segurança e fraude?

O risco de segurança e fraude é a probabilidade de uma fraqueza no seu software permitir que um atacante cometa fraude contra você ou seus clientes. Ele une duas áreas que costumam trabalhar separadas: a segurança de aplicações, que encontra e corrige falhas de software, e a prevenção a fraudes, que detecta e interrompe o abuso financeiro.

A Association of Certified Fraud Examiners (ACFE) explica a fraude com o triângulo da fraude, um modelo do criminologista Donald Cressey. Ele tem três partes: uma "necessidade financeira que não pode ser compartilhada", uma "oportunidade percebida" e uma "racionalização". Cressey estudou pessoas que desviavam dinheiro que outros lhes confiavam para administrar, por isso o triângulo da fraude descreve primeiro a fraude interna.

A fraude externa é a cometida por pessoas de fora da empresa, como clientes, impostores ou grupos criminosos. Na fraude externa contra um negócio digital, o lado da oportunidade do triângulo da fraude costuma ser uma falha de software: uma redefinição de senha que não verifica a identidade, uma API que devolve os dados de outro cliente, um formulário de pagamento que aceita qualquer valor. A equipe de fraude não consegue eliminar essa oportunidade. Só quem escreve o código consegue. Esse é o risco de fraude cibernética em uma frase: o motivo é do atacante, mas a oportunidade é do seu software.

O triângulo da fraude visto a partir da aplicação. Elaboração própria.

Por que os programas antifraude deixam a engenharia de fora?

As orientações sobre fraude que revisamos pedem que várias equipes trabalhem juntas, mas nenhuma delas menciona a equipe que escreve o código. O Office of the Comptroller of the Currency (OCC) dos EUA afirma no Bulletin 2019-37 que "o risco de fraude é uma forma de risco operacional". Ele espera que os bancos tenham modelos, sistemas de monitoramento ou relatórios que detectem atividades fraudulentas "em todas as linhas de negócio e funções".

Os guias de gestão de risco de fraude fazem o mesmo pedido. O guia da Stripe sobre gestão de risco de fraude pede às empresas que "envolvam as partes interessadas de vários departamentos" durante a avaliação de risco de fraude, ou seja, a análise de onde e como a fraude pode acontecer em uma organização. O guia nunca menciona engenheiros nem segurança de aplicações.

Além disso, as duas equipes falam línguas diferentes. Em um artigo de outubro de 2025, a Mastercard escreveu que as equipes de cibersegurança e de fraude usam vocabulários diferentes, o que dificulta a comunicação. O artigo também cita uma pesquisa em que 60 % dos executivos de fraude e risco do mundo dizem que só descobrem violações cibernéticas depois que as perdas por fraude começam.

A detecção de fraude pode funcionar sem engenharia. Fechar a falha por onde a fraude passa, não: não exige engenharia, mas também não corrige nada.

Quais vulnerabilidades permitem a fraude?

Agrupamos a fraude que nasce em uma aplicação em quatro tipos: invasão de contas (account takeover), coleta de dados (data harvesting), fraude em pagamentos (payment fraud) e contas falsas (fake accounts). Cada um tem um nome do lado da equipe de fraude e outro do lado da engenharia. A tabela usa fraquezas da Fluid Attacks Database e casos públicos documentados por órgãos reguladores.

A fraude de card testing (teste de cartões) é um exemplo claro dessa lacuna. No card testing, os atacantes fazem muitos pagamentos pequenos para descobrir quais números de cartões roubados funcionam. A documentação da Stripe diz aos lojistas que não são desenvolvedores, ou que usam um plugin ou uma plataforma, que preveni-la "normalmente exige mudanças no código". Nosso post sobre sistemas de pagamento seguros aborda outras falhas nos fluxos de pagamento.

Fraqueza 417, Account Takeover, na Fluid Attacks Database.

Como é a invasão de contas na nossa pesquisa?

Nossos pesquisadores de segurança encontram caminhos de invasão de contas em aplicações reais e os publicam como advisories. No Bhima 1.27.0 (CVE-2023-0944), uma referência direta insegura a objetos (IDOR), ou seja, uma falha que permite a um usuário chegar aos dados de outro apenas trocando um ID, permitiu que um usuário comum alterasse as credenciais de outros usuários, inclusive as do administrador.

No VitalPBX 3.2.3-8 (CVE-2023-0486), uma falha de cross-site scripting (XSS) refletido permitia capturar o cookie de sessão do administrador por meio de um link malicioso. No CandidATS 3.0.0 (CVE-2022-42750), uma falha de XSS armazenado, causada por arquivos enviados que a aplicação não validava direito, permitia que um atacante remoto invadisse contas de usuários.

Nenhuma dessas falhas parece fraude no relatório de um scanner. Cada uma parece fraude no dia em que um atacante a usa.

Como o risco de fraude muda quando um negócio cresce?

O risco de fraude cresce mais rápido que o negócio, porque cada nova funcionalidade abre um caminho que os atacantes podem testar. Quando um negócio cresce, ele soma aplicativos, APIs, meios de pagamento e parceiros. Cada nova versão muda um código que a equipe de fraude nunca vê.

Os atacantes também automatizam. O Open Worldwide Application Security Project (OWASP) lista 21 ameaças automatizadas, como o credential stuffing (OAT-008), que define como "tentativas massivas de login para verificar a validade de pares roubados de usuário e senha". O Gartner prevê que, até 2027, os agentes de IA vão reduzir em 50 % o tempo necessário para explorar contas expostas.

As perdas são mensuráveis. O Internet Crime Complaint Center (IC3) do FBI registra, no 2025 IC3 Annual Report, cerca de 4.700 denúncias de invasão de contas, com perdas de US$ 359,7 milhões. Na América Latina e no Caribe, o resumo executivo do DBIR 2026 aponta a exploração de vulnerabilidades em 44 % das violações e o abuso de credenciais em 5 %. O risco de fraude cibernética, portanto, não é fixo. Ele muda a cada nova versão, à medida que o negócio cresce.

Credential stuffing (OAT-008). Fonte: OWASP, CC BY-SA 4.0

Vulnerabilidades que contam como risco de fraude

Nem toda vulnerabilidade é risco de fraude, e uma equipe de fraude não precisa de todo o seu backlog. Para avaliar o risco de fraude a partir das vulnerabilidades de segurança, usamos estas condições no nosso Fraud risk center. Uma vulnerabilidade só conta quando cumpre as cinco condições:

1. Corresponde a pelo menos um tipo de fraude: invasão de contas, coleta de dados, fraude em pagamentos ou contas falsas.

2. Está aberta e não está marcada como risco zero.

3. É acessível pela internet.

4. Afeta a confidencialidade ou a integridade.

5. Mostra evidência de exploração no mundo real: sua exploração foi observada, não apenas demonstrada como possível.

O resultado é uma lista curta do que um atacante poderia usar para cometer fraude. Depois, cada categoria de fraude assume o nível de exposição da sua vulnerabilidade aberta mais grave, em uma escala de Critical, High, Medium, Low e None. A categoria mais exposta aparece primeiro.

O filtro muda o que a equipe de fraude lê, não o que a engenharia corrige. Ele transforma o risco de segurança e fraude em uma lista que as duas equipes conseguem ler. As vulnerabilidades que não cumprem as cinco condições continuam reportadas e gerenciadas na plataforma como sempre. As quatro categorias aparecem sempre, mesmo sem exposição, porque para um diretor de segurança da informação (CISO) que presta contas ao conselho, "sem exposição" também é uma resposta. É assim que as organizações podem avaliar o risco de fraude com dados de segurança e reforçar as defesas onde a exposição é maior.

Categorias de fraude ordenadas por exposição no Fraud risk center.

Como uma equipe de fraude deve passar um risco para a engenharia?

Um bom repasse dá à engenharia contexto suficiente para agir sem precisar de uma reunião. Um analista de fraude que vê uma exposição High em invasão de contas precisa de uma única ação: pedir aos responsáveis pelo sistema afetado que o corrijam primeiro.

No Fraud risk center, essa ação se chama Escalate. O analista pode escalar um sistema ou todos os sistemas afetados de uma categoria e adicionar até 1.000 caracteres de contexto. Os contatos responsáveis pelo sistema recebem um e-mail com o nível de exposição, o número de vulnerabilidades, até 10 locais vulneráveis e um link para as vulnerabilidades na plataforma. Depois, o sistema mostra a etiqueta Requested, para que outros analistas saibam que a solicitação já está em andamento.

O escalonamento não muda a vulnerabilidade, e o analista de fraude não vê o código. Cada equipe mantém o próprio trabalho. A equipe de fraude decide o que é urgente do ponto de vista da fraude; a engenharia recebe a evidência para corrigir. Os detalhes estão na documentação do Fraud risk center.

Escalonamento de uma categoria de fraude para os responsáveis pelos sistemas. Elaboração própria.

Estratégias de prevenção a fraudes que precisam da engenharia

As estratégias de prevenção a fraudes baseadas em detecção se apoiam em pontuações, regras e análise de comportamento. Estes passos acrescentam o lado da engenharia, e uma equipe pode começar cada um deles neste trimestre.

1. Combinem um único vocabulário

Relacionem cada tipo de fraude às fraquezas que o permitem, como na tabela acima. Escrevam o mapa e compartilhem com as duas equipes. Quando a equipe de fraude diz "invasão de contas", a engenharia deve saber que isso significa falhas na autenticação, nas sessões e na redefinição de senhas. Quando a engenharia diz "vazamento de informações de negócio", a equipe de fraude deve saber que isso pode significar coleta de dados.

Mantenham o mapa curto: quatro tipos de fraude e as dez ou onze fraquezas que mais importam nas suas aplicações. Um glossário longo que ninguém lê não fecha a lacuna de vocabulário.

2. Incluam a engenharia na avaliação de risco de fraude

Chamem um engenheiro de segurança de aplicações e um tech lead para a próxima avaliação de risco de fraude. Perguntem quais sistemas lidam com logins, pagamentos, cadastros e dados de clientes, e quais deles são acessíveis pela internet. Essa lista é o ponto onde a fraude e as vulnerabilidades de segurança se encontram. Depois, perguntem à equipe de fraude quais desses sistemas já mostram sinais de abuso, como rajadas de card testing ou contas novas que nunca fazem transações. Um sistema que aparece nas duas listas vai para o topo do plano de remediação.

3. Meçam a exposição, não as contagens

Uma contagem de 35 vulnerabilidades altas abertas diz pouco a uma equipe de fraude. A severidade aberta mais alta de cada categoria de fraude diz mais, porque uma falha crítica em um fluxo de pagamento importa mais que dez falhas baixas em outro lugar. Reportem a exposição por categoria e revisem depois de cada nova versão. Para a liderança, a mesma visão responde a uma pergunta simples: a que tipo de fraude o nosso software está mais exposto hoje? É assim que o risco de segurança e fraude vira uma linha no relatório para o conselho, em vez de dois relatórios separados.

4. Transformem o escalonamento em rotina

Combinem quem recebe um escalonamento de fraude, que contexto ele leva e com que rapidez a engenharia responde. Meçam quanto tempo as vulnerabilidades escaladas ficam abertas e comparem com o tempo de outras vulnerabilidades da mesma severidade. Se as escaladas não forem fechadas mais rápido, a rotina não está funcionando. Revisem os números com as duas equipes uma vez por mês, na mesma reunião. Depois, testem de novo cada correção: um reataque confirma que a oportunidade foi fechada, não apenas que um ticket foi fechado.

Um risco, uma conversa

As equipes de fraude sabem para onde vai o dinheiro. A engenharia sabe onde o código falha. Nenhum dos silos vê a falha que conecta os dois. O risco de segurança e fraude cai quando as duas equipes olham para a mesma lista curta e agem sobre ela na mesma semana. Criamos o Fraud risk center para essa conversa: ele mostra às equipes de fraude quais falhas permitem a fraude e envia à engenharia a evidência para corrigi-las.

Perguntas frequentes

Qual é a diferença entre credential stuffing e invasão de contas?

O credential stuffing é uma das formas de invadir contas. Os atacantes testam em grande escala pares roubados de usuário e senha em uma página de login, e a OWASP o lista como a ameaça automatizada OAT-008. A invasão de contas é o resultado: o atacante controla a conta de um cliente real. Outros caminhos levam ao mesmo resultado, como o roubo de sessões ou uma redefinição de senha fraca. Nosso guia sobre credential stuffing explica o ataque em detalhes.

As ferramentas de detecção de fraude encontram vulnerabilidades nas aplicações?

Não. As ferramentas de detecção de fraude analisam transações, dispositivos e comportamento para interromper o abuso enquanto ele acontece. Elas não leem código-fonte nem testam se uma aplicação tem falhas. Os testes de segurança, como a análise estática, a análise dinâmica e os testes de invasão, encontram as vulnerabilidades. Os dois tipos de ferramenta respondem a perguntas diferentes, e por isso as equipes que os usam precisam de uma visão compartilhada.

O PCI DSS exige controles sobre os scripts das páginas de pagamento?

Sim. O PCI Security Standards Council explica que os requisitos 6.4.3 e 11.6.1 do Payment Card Industry Data Security Standard (PCI DSS) v4.x buscam garantir que os scripts das páginas de pagamento sejam "devidamente autorizados, verificados quanto à integridade e monitorados contra adulterações". O conselho também alerta que os scripts executados nos navegadores dos consumidores "são hoje um alvo importante para atacantes que buscam roubar dados de cartões de pagamento".

Toda fraude digital é causada por vulnerabilidades de software?

Não. Grande parte da fraude que as pessoas denunciam começa com engenharia social, como ligações falsas, phishing e golpes de investimento, sem nenhuma falha de software envolvida. No 2025 IC3 Annual Report, a fraude de investimento causou as maiores perdas reportadas. O risco de segurança e fraude cobre a parte da fraude que depende de uma fraqueza nas suas aplicações. Essa é a parte que a engenharia pode eliminar.