Segurança de aplicações

Proteção de dados pessoais

Princípios de proteção de dados

• Minimização, coletar e armazenar apenas os dados estritamente necessários.
• Limitação de uso, usar dados apenas para a finalidade declarada.
• Retenção limitada, excluir dados quando não forem mais necessários.
• Segurança, proteger dados com medidas técnicas adequadas.

Dados sensíveis do Mercado Livre:

Esses dados são classificados como informações de identificação pessoal (PII) e devem ser criptografados em repouso, mascarados em logs e de acesso restrito; os seguintes são alguns exemplos desse tipo de dados:

• E-mails
• Telefones
• Endereço de envio
• Documento de identidade
• Qualquer outro dado de uso exclusivo do usuário.

Práticas requeridas:

• Criptografar dados PII em repouso, usar AES-256 ou equivalente.
• Mascarar logs, não registrar e-mails, telefones e documentos de identidade completos.
• Apenas usuários com as funções e/ou permissões adequadas podem acessar esses dados.
• Registro de acesso que permita identificar quem acessou dados sensíveis e o que fez com eles.
• Estabelecer uma política de retenção de dados.
• Direito de exclusão, capacidade de excluir dados se o usuário solicitar.

Vejamos como é o tratamento inseguro versus seguro de dados pessoais:

No banco de dados:

SEGURANÇA DE DADOS PESSOAIS: ARMAZENAMENTO

❌ INCORRETO: SEM CRIPTOGRAFIA

+--------------+------------------+------------------+
| comprador_id | email            | telefono         |
+--------------+------------------+------------------+
| 12345        | juan@email.com   | 1155551234       |
+--------------+------------------+------------------+
⚠️ RISCO CRÍTICO: Se hackarem o BD, todos os dados pessoais ficam expostos.

✅ CORRETO: COM CRIPTOGRAFIA (ENCRIPTADO)

+--------------+------------------+------------------+
| comprador_id | email_encrypted  | phone_encrypted  |
+--------------+------------------+------------------+
| 12345        | gAAAAABl2K8...   | gAAAAABl2K9...   |
|              | [criptografado]  | [criptografado]  |
+--------------+------------------+------------------+
✅ SEGURANÇA ROBUSTA: Mesmo que hackeem o BD, os dados estão protegidos e ilegíveis.

Nos logs:

❌ INCORRETO:

[2026-01-15] Pedido criado para: juan@email.com, tel: +5491155551234

⚠️ Qualquer pessoa com acesso aos logs vê os dados pessoais

✅ CORRETO:

[2026-01-15] Pedido criado para: j***@***.com, tel: ***1234

Ou melhor:
[2026-01-15] Pedido 12345 criado para comprador_id: 67890

✅ Os dados pessoais estão ofuscados ou substituídos
por IDs, protegendo a privacidade.

Referências

• OWASP Data Protection: Melhores práticas de proteção de dados.
• PCI DSS: Padrão de segurança para dados de cartões.
• CWE-359: Exposure of Private Personal Information: Documentação técnica sobre exposição de informações pessoais privadas.
• OWASP Top 10 - A02:2021 Sensitive Data Exposure: Documentação sobre exposição de dados sensíveis, inclui PII.

Glossário

Termo	Significado
PII	Personally Identifiable Information - Dados que identificam uma pessoa (nome, e-mail, telefone, documento).
Criptografia em repouso	Criptografar dados quando estão armazenados no banco de dados (não apenas em trânsito).
Mascaramento	Ocultar parte de um dado sensível (ex: mostrar j***@***.com em vez do e-mail completo).
Minimização	Princípio de armazenar apenas os dados estritamente necessários.
Retenção	Por quanto tempo os dados são armazenados antes de serem excluídos.

Validação de dados

Princípios de validação

• Validar tanto no frontend quanto no backend, nunca confiar apenas nas validações do lado do cliente.
• Usar allowlist e não blocklist, definir o que é permitido e não o que é proibido.
• Validar tipo e formato, verificar que os dados são do tipo esperado.
• Validar intervalos, aceitar apenas a quantidade de caracteres necessários estabelecendo limites lógicos.
• Rejeitar o inválido sem tentar "corrigir" dados malformados e gerenciando o tratamento de erros para evitar entregar informações técnicas extras nas respostas.

Validações por tipo:

• Strings: comprimento máximo, caracteres permitidos, encoding.
• Números: Tipo (inteiro/decimal), intervalo, sinal.
• E-mails: formato válido, comprimento.
• URLs: protocolo permitido (HTTPS), domínio válido.
• IDs: validar formato esperado, existência.
• Datas: formato ISO, intervalo lógico.

Um campo sem validação pode ser a porta de entrada para SQL injection, XSS ou execução de comandos. Veja estes exemplos:

Validar no backend (não apenas no frontend):

❌ INCORRETO: APENAS FRONTEND

JavaScript (navegador)
  if (email.includes("@")) { submit(); }

⚠️ Problema: O atacante pode ignorar o JavaScript com ferramentas externas.

✅ CORRETO: FRONTEND + BACKEND

Navegador (JavaScript)
  if (email.includes("@")) { submit(); }

Servidor (Python)
  if not is_valid_email(email):
      return error("E-mail inválido")

✅ Dupla camada de segurança: O servidor sempre valida a integridade dos dados.

Allowlist vs Blocklist:

❌ INCORRETO: BLOCKLIST (o que é proibido)

# Proibir caracteres perigosos
if "<script>" in input or "DROP TABLE" in input:
    reject()

⚠️ Problema: Os atacantes sempre encontram formas de contornar a lista negra.

✅ CORRETO: ALLOWLIST (o que é permitido)

# Permitir apenas o que esperamos
if not re.match(r"^[a-zA-Z0-9_]{3,20}$", username):
    reject()

✅ Se não corresponder exatamente ao permitido, rejeitar.

Validar tipo e formato:

❌ INCORRETO: SEM VALIDAÇÃO DE TIPO

# Aceitar qualquer coisa
order_id = request.get("order_id")
order = get_order(order_id)

⚠️ Problema: O que acontece se order_id = "abc" ou
   "1; DROP TABLE orders"?

✅ CORRETO: COM VALIDAÇÃO

order_id = request.get("order_id")

# Validar que é um número
if not order_id.isdigit():
    return error("ID de pedido inválido")

order = get_order(int(order_id))

✅ Ao forçar o tipo de dado, evita injeções e
   erros de execução inesperados.

Referências

• OWASP Input Validation: Guia completo de validação de entrada.
• OWASP SQL Injection Prevention: Como prevenir SQL injection.
• OWASP XSS Prevention: Como prevenir Cross-Site Scripting.
• OWASP Command injection: Como prevenir injeção de comandos.
• CWE-20 (Input Validation): Documentação sobre validação incorreta e definição do seu risco.

Glossário

Termo	Significado
Validação	Verificar que os dados recebidos têm o formato e os valores esperados.
Sanitização	Limpar dados de entrada, removendo caracteres perigosos.
SQL Injection	Ataque onde se injeta código SQL malicioso por meio de campos de entrada.
XSS	Cross-Site Scripting - Ataque onde se injeta JavaScript malicioso em páginas web.
Command Injection	Ataque onde se injetam comandos do sistema operacional.
Allowlist (Lista branca)	Definir O QUE é permitido (mais seguro).
Blocklist (Lista negra)	Definir O QUE é proibido (menos seguro, sempre pode ser contornado).
Regex	Regular Expression - Padrão para validar formato de texto.

Tratamento de erros

• As mensagens devem ser genéricas para o usuário, não se deve expor detalhes técnicos.
• Os detalhes apenas nos logs, erros do tipo stack traces e técnicos vão para os logs internos.
• É boa prática usar códigos de erro que permitam investigar sem expor detalhes.
• Consistência usando as mesmas mensagens para erros similares.

Informações a NÃO expor

• Stack traces ou exceções.
• Caminhos de arquivos do sistema.
• Consultas SQL ou erros de banco de dados.
• Nomes de tabelas ou colunas.
• Versões de software ou frameworks.
• IPs internos ou nomes de servidores.
• Se um usuário existe ou não (no login).

Uma mensagem de erro detalhada é ouro para um atacante: revela caminhos, tecnologias e lógica interna. Compare estes cenários:

Referências

• OWASP Input Validation: Guia completo de validação de entrada.
• OWASP SQL Injection Prevention: Como prevenir SQL injection.
• OWASP XSS Prevention: Como prevenir Cross-Site Scripting.
• OWASP Command injection: Como prevenir injeção de comandos.
• CWE-20 (Input Validation): Documentação sobre validação incorreta e definição do seu risco.

Glossário

Termo	Significado
Stack Trace	Detalhe técnico do erro que mostra linhas de código, caminhos de arquivos, etc.
Information Disclosure	Vazamento de informações - Revelar dados internos do sistema em mensagens de erro.
Erro genérico	Mensagem de erro que não revela detalhes técnicos (ex: "Ocorreu um erro").
Logging	Salvar registro de eventos e erros internamente (não mostrar ao usuário).

Segurança em notificações (WebHooks)

Sem a proteção adequada desse endpoint, um atacante poderia:

• Enviar notificações falsas.
• Enviar e processar dados fraudulentos.
• Realizar uma negação de serviço DoS.

É por isso que recomendamos implementar os seguintes requisitos:

Usar HTTPS obrigatoriamente

❌ INCORRETO:

http://tuapp.com/webhooks/meli

Problema: As notificações trafegam sem criptografia. Um atacante pode interceptar e ler os dados.

✅ CORRETO:

https://tuapp.com/webhooks/meli

As notificações trafegam criptografadas. Ninguém pode ler o conteúdo em trânsito.

Quando você configura sua aplicação no gerenciador de aplicações, a URL de callback deve usar HTTPS.

Validar que a notificação vem do Mercado Livre

O Mercado Livre envia notificações a partir desses IPs:

• 54.88.218.97
• 18.215.140.160
• 18.213.114.129
• 18.206.34.84
• 35.236.253.169
• 35.245.91.34
• 35.245.20.104
• 35.186.182.146

O fluxo com a validação deveria ser assim:

[Placeholder: diagrama-validacion-ips-webhook.png]

Importante: Os IPs podem mudar. Consulte sempre a documentação para obter a lista atualizada.

Outra opção de validação é consultando o recurso; a forma mais segura de validar uma notificação é não confiar nos dados do webhook, mas usar a notificação como um "aviso" e então consultar diretamente a API do Mercado Livre, seria algo assim:

FLUXO SEGURO:
                            |
  1. Recebe notificação:   |  {
                            |    "resource": "/orders/123",
                            v    "user_id": 789 ...
                               }

  2. Responder HTTP 200 imediatamente
     (confirmar recebimento)
                           |
                           v
  3. Enfileirar para processamento async
                           |
                           v
  4. Consultar diretamente a API do MELI:
     GET https://api.mercadolibre.com/orders/123
     com SEU access_token
                           |
                           v
  5. Usar os dados da resposta da API
     ⚠️ (NÃO os dados do webhook)

Responder rapidamente

O Mercado Livre espera uma resposta HTTP 200 em menos de 500 milissegundos:

❌ SE NÃO RESPONDER A TEMPO:

Tentativa 1 --> Seu servidor (timeout) --> MELI tenta novamente
Tentativa 2 --> Seu servidor (timeout) --> MELI tenta novamente
...
Tentativa 8 --> Seu servidor (timeout) --> MELI desativa suas
                                           notificações

Resultado: Você perde notificações e deve reativar
           manualmente.

✅ PADRÃO CORRETO:

1. Receber webhook
2. Salvar na fila (Redis, RabbitMQ, banco de dados)
3. Responder HTTP 200 imediatamente
4. Processar a fila de forma assíncrona

    Webhook --> +-----------------+
                | Receber         | --> HTTP 200 (imediato)
                | e enfileirar    |
                +--------+--------+
                         |
                         v
                +-----------------+
                | Fila            |
                | (async)         |
                +--------+--------+
                         |
                         v
                +-----------------+
                | Processar       | --> Consultar API MELI
                | (worker)        | --> Atualizar seu BD
                +-----------------+

Proteger contra abuso ou consumos excessivos

❌ SEM PROTEÇÃO:

  Atacante envia 10.000 requests/segundo
                   |
                   v
          Seu servidor fica sobrecarregado
                   |
                   v
    Você não consegue processar webhooks reais do MELI

✅ COM PROTEÇÃO: Implemente Rate Limiting

+------------------------+------------------------+
| Medida                 | Configuração sugerida  |
+------------------------+------------------------+
| Rate limit por IP      | 100 req/minuto máximo  |
| Timeout de conexão     | 30 segundos máximo     |
| Tamanho máx. de payload| 1 MB máximo            |
| Bloqueio de IPs        | Após 10 req. inválidos |
+------------------------+------------------------+

✅ Ao limitar o tráfego, você garante que os recursos do seu
   servidor estejam sempre disponíveis para o Mercado Livre.

Referências

• MELI - Notificações: documentação oficial de notificações no MercadoLivre.
• Webhook security: Riscos associados a webhooks.

Glossário

Termo	Significado
Webhook	Notificação automática que o MELI envia ao seu servidor quando algo muda (novo pedido, pagamento, etc.).
Payload	Neste contexto são os dados que vêm dentro da notificação (o conteúdo JSON).
IP Whitelist	Lista de IPs permitidos - aceitar apenas conexões desses IPs específicos.
Rate Limiting	Limitar quantas solicitações por minuto seu servidor pode receber.
Async / Assíncrono	Processar algo em segundo plano, sem fazer esperar quem enviou a solicitação.
DoS	Denial of Service - Ataque que sobrecarrega seu servidor com muitas solicitações.

Proteção contra abuso

Rate limiting na aplicação que se integra (sugestão)

• Para o início de sessão 5 tentativas / 15 min.
• Registro de novas contas 3 tentativas / hora / IP.
• APIs / endpoints sensíveis 30 - 60 solicitações / min (a considerar conforme necessidade do negócio).
• APIs / endpoints gerais 100 - 200 solicitações / min.

❌ SEM RATE LIMITING:

Atacante faz 10.000 requests por minuto
Seu servidor fica sobrecarregado
Ou: Sua conta do Mercado Livre é bloqueada por exceder os limites

✅ COM RATE LIMITING:

+----------------------------+--------------------+
|     RATE LIMITS RECOMENDADOS                    |
+----------------------------+--------------------+
| Endpoint                   | Limite             |
+----------------------------+--------------------+
| Login                      | 5 tent./15 min     |
| Registro de contas         | 3 tent./hora/IP    |
| APIs sensíveis             | 30-60 req/min      |
| APIs gerais                | 100-200 req/min    |
+----------------------------+--------------------+

Solicitação 101 em 1 minuto:
   -> HTTP 429 Too Many Requests
   -> Header: Retry-After: 30

Proteção adicional

• Implementar sistema de CAPTCHA que seja ativado especialmente após N tentativas falhas ou ao detectar comportamento suspeito.
• Bloqueio temporário de IP ou de conta em caso de abusos.
• Detecção de bots por meio da análise de padrões de comportamento.

Referências

• OWASP Blocking Brute Force: Como prevenir ataques de força bruta.
• OWASP Denial of Service: Guia de proteção contra DoS.
• Rate Limiting Best Practices: Melhores práticas de rate limiting.

Glossário

Termo	Significado
Rate Limiting	Limitar quantas solicitações um usuário/IP pode fazer por minuto.
Brute Force	Ataque que testa muitas combinações até encontrar a correta (ex: senhas).
CAPTCHA	Teste para verificar que o usuário é humano e não um bot.
DoS / DDoS	(Distributed) Denial of Service - Ataque que sobrecarrega o servidor com solicitações.
Scraping	Extração automatizada de dados de um site.
BOT	Programa automatizado que faz solicitações sem intervenção humana.
HTTP 429	Código de resposta que significa "Muitas solicitações" (Too Many Requests).
Throttling	Reduzir a velocidade de resposta quando há muitas solicitações.

Segurança em Dependências

Recomenda-se:

• Realizar varreduras regulares para verificar vulnerabilidades conhecidas pelo menos semanalmente; existem diferentes soluções no mercado que podem ajudar nesse processo: Snyk, Owasp dependency-check, npm audit, renovate, entre outros.
• Aplicar as atualizações de segurança identificadas o mais rápido possível.
• Recomenda-se usar versões específicas e não intervalos abertos.
• É importante avaliar uma dependência no nível de segurança e manutenção antes de usá-la; isso pode ser feito por meio das ferramentas mencionadas anteriormente.
• Também é útil estar atento a notícias relacionadas com dependências comuns; as empresas por trás desses softwares de análise de dependências costumam permitir a inscrição em seus boletins informativos (newsletters).

Como podemos verificá-lo? Vejamos alguns exemplos em linguagens comuns:

Linguagem	Ferramenta	Comando
Python	Safety, pip-audit	safety check ou pip-audit
Node.js	Npm audit	npm audit
Java	OWASP dependency-check	Plugin maven/gradle
Outras linguagens	Snyk	snyk test

Exemplo de resultado:

$ npm audit
found 3 vulnerabilities (1 low, 1 moderate, 1 high)

+---------------+---------------------------------------+
| high          | Prototype Pollution in lodash         |
+---------------+---------------------------------------+
| Package       | lodash                                |
+---------------+---------------------------------------+
| Patched in    | >=4.17.21                             |
+---------------+---------------------------------------+
| Dependency of | your-app                              |
+---------------+---------------------------------------+
| Path          | your-app > lodash                     |
+---------------+---------------------------------------+

Referências

• OWASP Dependency Check: Ferramenta para detectar vulnerabilidades em dependências.
• Snyk: Plataforma de segurança para dependências.
• npm audit: Documentação de auditoria do npm.
• Pip-audit: Ferramenta de auditoria para Python.
• CWE-1104 (Unmaintained Components): Documentação sobre componentes sem manutenção.

Glossário

Termo	Significado
Dependência	Biblioteca ou pacote de terceiros que você usa no seu projeto (ex: requests, lodash, axios).
Vulnerabilidade	Falha de segurança no código que pode ser explorada.
CVE	Common Vulnerabilities and Exposures - Identificador único para vulnerabilidades conhecidas.
npm audit	Comando do Node.js para detectar vulnerabilidades em dependências.
pip-audit / safety	Ferramentas do Python para detectar vulnerabilidades em dependências.
Patch	Atualização que corrige uma vulnerabilidade.

Próximo: Monitoramento.