← Base de Conhecimento

UUID em Rastreamento de Brindes e Cashback: Sem Duplicidade, Sem Fraude

Cupons gerados sequencialmente são convites à fraude — qualquer pessoa com dois cupons legítimos consegue enumerar os demais. Veja como a migração para UUIDs v4 eliminou tentativas de resgate com cupons não emitidos em um programa de cashback de grande cooperativa de consumo.

Espaço Reservado · AdSense

Por Que IDs Sequenciais São Inseguros em Promoções

O problema com IDs sequenciais em contextos de promoção é matematicamente simples: se você recebeu o cupom 1.847 e seu amigo recebeu o cupom 1.892, qualquer pessoa com acesso a dois cupons consegue inferir que existem cupons entre 1.848 e 1.891 — e provavelmente antes de 1.847 e depois de 1.892. Em um sistema onde o resgate do cupom exige apenas o número, isso é uma vulnerabilidade de exploração trivial.

Em um programa de cashback para uma grande cooperativa de consumo com base de mais de 1,2 milhão de cooperados, os cupons eram gerados sequencialmente desde o lançamento do programa. O sistema de resgate aceitava qualquer número de cupom válido vinculado a uma compra qualificada. Durante uma análise de segurança rotineira, identificamos tentativas sistemáticas de resgate com números de cupom em sequências que não haviam sido emitidas — bots tentando números em ordem crescente e registrando os que retornavam sucesso.

Em um período de 30 dias analisado, foram identificadas 4.800 tentativas de resgate com cupons não emitidos, das quais 23 obtiveram sucesso por falhas de validação secundária. O impacto financeiro direto foi de R$ 3.400 em cashback indevido — pequeno no absoluto, mas com potencial de escala exponencial caso o método fosse descoberto por grupos maiores.

UUID v4: Criptograficamente Seguro por Design

Um UUID v4 (Universally Unique Identifier versão 4) é um identificador de 128 bits gerado com aleatoriedade criptográfica. O formato é: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx, onde o "4" indica a versão e o "y" indica a variante. Um exemplo:

a3f8c2d1-7e4b-4a9f-8c6d-2b1e5f3a9d7c

O espaço de possibilidades de um UUID v4 é 2^122 — aproximadamente 5,3 × 10^36 combinações distintas. Para ter uma perspectiva: se um bot tentasse um bilhão de UUIDs por segundo durante a idade do universo (13,8 bilhões de anos), ainda teria explorado uma fração ínfima do espaço total. A probabilidade de acertar um UUID válido por tentativa aleatória é, na prática, zero.

A geração segura no navegador usa a Web Crypto API:

// UUID v4 criptograficamente seguro via Web Crypto API
function generateUUID() {
    return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, c =>
        (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
    );
}

// Alternativa moderna (disponível em navegadores atuais e Node.js 14.17+)
const uuid = crypto.randomUUID();

A diferença entre crypto.randomUUID() e Math.random() para geração de identificadores é fundamental: Math.random() usa um gerador pseudoaleatório determinístico que não é adequado para contextos de segurança. crypto.getRandomValues() usa fonte de entropia do sistema operacional, adequada para criptografia.

UUID em Diferentes Formatos para Diferentes Usos

O formato padrão de UUID com hífens (a3f8c2d1-7e4b-4a9f-8c6d-2b1e5f3a9d7c) é o mais legível, mas nem sempre o mais adequado para cada contexto de varejo:

Com hífens (padrão): Ideal para exibição em cupons físicos e e-mails — o agrupamento visual facilita a leitura e digitação manual. Também é o formato padrão para armazenamento em bancos de dados que suportam o tipo UUID nativo (PostgreSQL, MySQL 8+).

Sem hífens: a3f8c2d17e4b4a9f8c6d2b1e5f3a9d7c — útil quando o UUID precisa ser parte de uma URL ou QR Code, onde os hífens adicionam caracteres sem valor visual no contexto de varredura.

Maiúsculo: A3F8C2D1-7E4B-4A9F-8C6D-2B1E5F3A9D7C — algumas organizações preferem a versão em maiúsculas para impressão em cupons físicos, pois reduz a ambiguidade de leitura (a letra "l" minúscula vs o número "1" é um exemplo clássico).

A escolha do formato deve ser consistente em todos os pontos do sistema — geração, armazenamento, validação e exibição — para evitar problemas de comparação de string em validações.

UUID em Cashback, Brindes e Cupons de Desconto

Os casos de uso no varejo são bem distintos e merecem considerações específicas:

Cashback: O UUID identifica a transação de cashback, não o cooperado. Isso é importante para auditoria — cada resgate tem um UUID próprio que pode ser rastreado end-to-end: geração → vinculação à compra → resgate. Com IDs sequenciais, a tentativa de resgate duplo é detectável apenas se o sistema verificar o status. Com UUIDs, mesmo sem verificação de status, a tentativa de gerar um UUID válido por força bruta é computacionalmente inviável.

Brindes com limite de quantidade: UUIDs permitem implementar o controle de limite de forma robusta. Cada cupom de brinde é um UUID único gerado no momento da qualificação e marcado como "emitido" no banco. O resgate verifica existência do UUID + status "não resgatado" + critérios adicionais (CPF do titular, loja válida, prazo).

Cupons de desconto em lote: Gerar 50.000 cupons únicos para uma campanha de e-mail é trivial com UUIDs — cada destinatário recebe um UUID diferente, o sistema registra qual UUID foi enviado para qual e-mail e o resgate verifica a correspondência.

Banco de Dados: UUID como PK vs BIGINT

A principal objeção técnica ao uso de UUIDs como chave primária em bancos de dados de alta transação é legítima: UUIDs são aleatórios, o que torna os índices B-tree menos eficientes que sequências numéricas para inserções em alta frequência (o índice precisa ser rebalanceado mais frequentemente).

Os tradeoffs para contextos de varejo:

  • BIGINT autoincremental: Inserções mais rápidas, índices mais eficientes, tamanho menor (8 bytes vs 16 bytes). Porém, é previsível — expõe volume de transações e permite enumeração.
  • UUID v4 como PK: Inserções levemente mais lentas em alta frequência, mas imprevisível por design. Para tabelas de cupons e cashback que raramente excedem milhões de registros (vs bilhões em tabelas de log), o impacto de performance é negligenciável.
  • UUID v7 (ordered): O padrão mais recente gera UUIDs com componente de timestamp no início, tornando-os ordenáveis cronologicamente. Combina a segurança do UUID com a eficiência de índice próxima ao BIGINT. É a melhor opção para novos projetos de varejo com MySQL 8 ou PostgreSQL 14+.
  • Solução híbrida: BIGINT como PK interna (não exposta) + UUID como identificador público (exposto em URLs, e-mails e QR Codes). Melhor performance interna + segurança externa.

Gere UUIDs com a Ferramenta

O Gerador de UUID da Toolbox Dev Design gera UUIDs v4 com criptografia segura diretamente no navegador, nos formatos padrão, sem hífens e em maiúsculas. Ideal para gerar lotes de identificadores para testes ou para validar o formato esperado pelo seu sistema antes de implementar a geração em produção.

Perguntas Frequentes

UUID v4 pode ter colisão? Dois UUIDs iguais podem ser gerados?

Teoricamente sim — matematicamente há 2^122 possibilidades, portanto colisão é possível. Na prática, a probabilidade de colisão ao gerar 1 bilhão de UUIDs é de aproximadamente 1 em 5,3 × 10^17 — menor que a probabilidade de ser atingido por raio duas vezes no mesmo dia. Para sistemas de varejo que geram milhões de cupons por ano, a colisão de UUID pode ser considerada impossível para fins práticos. Adicionalmente, uma constraint UNIQUE no banco de dados captura colisões caso ocorram.

UUID é adequado para QR Codes em cupons físicos?

Sim, e é o formato recomendado. Um UUID sem hífens tem 32 caracteres alfanuméricos — o QR Code resultante é compacto e lido rapidamente por scanners de loja. A vantagem sobre IDs sequenciais é que o QR Code não revela informações sobre o volume de cupons emitidos ou a posição na sequência, protegendo dados de negócio.

Como migrar um sistema de IDs sequenciais para UUIDs sem quebrar dados históricos?

A estratégia mais segura é manter os IDs sequenciais existentes e adicionar uma coluna UUID à tabela — sem torná-la a PK imediatamente. Preencha a coluna UUID para todos os registros existentes (geração em batch), atualize a camada de aplicação para usar o UUID em URLs e APIs externas, e mantenha o ID sequencial como PK interna por pelo menos um ciclo de auditoria completo antes de considerar a migração da PK. Nunca faça migração de PK em ambiente de produção sem testes extensivos e backup verificado.

UUID garante sozinho a segurança de um sistema de cupons?

Não — UUID é uma camada de segurança, não a segurança completa. Um sistema robusto de cupons combina UUID (imprevisibilidade do identificador) + validação de CPF/conta do titular + verificação de status do cupom + rate limiting para tentativas de resgate + logs de auditoria + prazo de validade com verificação server-side. UUID elimina a enumeração, mas não substitui as demais verificações de negócio.

Caso Real: NuAto no Varejo

O programa de cashback de uma grande cooperativa de consumo com 1,2 milhão de cooperados operava com cupons sequenciais desde o lançamento. Em uma auditoria de segurança de rotina, identificamos nos logs do sistema um padrão suspeito: tentativas de resgate com números de cupom em progressão aritmética, a partir de contas recém-criadas com dados mínimos. O padrão era inequivocamente automatizado — intervalos regulares de 200ms entre tentativas, sequência numérica crescente.

A análise revelou que 23 resgates indevidos haviam ocorrido no período de 30 dias analisado, totalizando R$ 3.400 em cashback não vinculado a compras reais. A vulnerabilidade era conhecida teoricamente, mas nunca havia sido priorizada por ser considerada de baixo impacto. A presença de atividade automatizada indicava que o método havia sido descoberto e estava sendo testado em escala crescente.

A migração para UUIDs v4 foi implementada em dois estágios: primeiro, todos os novos cupons passaram a ser gerados com UUID; segundo, os cupons históricos (sequenciais) foram bloqueados para resgate após prazo de transição de 60 dias com comunicação ativa para a base. O resultado foi imediato: as tentativas de enumeração cessaram completamente nas primeiras 72 horas após a migração — os bots não conseguiam gerar UUIDs válidos por tentativa. Nos 6 meses seguintes, zero resgates indevidos identificados por exploração de identificadores. A única mudança no sistema foi o tipo do identificador.

Carlos Zucolli

30 anos de experiência em varejo, marketing digital e desenvolvimento de soluções para o comércio brasileiro. Sócio da NuAto Comunicação e criador da Toolbox Dev Design. Já gerenciou campanhas para gigantes do Atacarejo, Home Center e Cooperativas de Consumo.

Ver perfil completo →
Espaço Reservado · AdSense
Espaço Publicitário