Documentação do Mercado Livre

Confira todas as informações necessárias sobre as APIs Mercado Livre.
circulos azuis em degrade

Documentação do

Última atualização em 06/04/2026

Autenticação segura

A aplicação que se integra pode ter seus próprios usuários (operadores, administradores, sub-contas) que acessam dados de múltiplos sellers do Mercado Livre. Uma autenticação fraca significa:

  • Acesso não autorizado.
  • Usurpação de identidade.
  • Roubo de credenciais.
  • Acesso a dados de usuários do Mercado Livre.

É por isso que recomendamos as seguintes práticas a serem consideradas para que seu sistema de autenticação seja seguro e robusto:

Política de senhas seguras

  • Complexidade: maiúsculas, minúsculas, números e símbolos.
  • Comprimento: mínimo de 12 caracteres.
  • Verificação contra listas (Denylist): rejeitar senhas comuns conhecidas ou que sigam padrões relacionados ao usuário.
  • O armazenamento seguro é fundamental: usar HASH com Argon2 ou bcrypt (nunca texto simples nem MD5/SHA1).

Uma senha fraca é a porta de entrada mais fácil para um atacante. Compare estes exemplos para avaliar sua política atual:

Exemplo de senhas:

❌ SENHAS FRACAS (não permitir):

123456          -> Muito simples
password        -> Palavra comum
admin123        -> Padrão previsível
empresa2026     -> Relacionada ao contexto
qwerty          -> Padrão de teclado

✅ SENHAS FORTES (exigir):

Mínimo 12 caracteres
+ Maiúsculas: A-Z
+ Minúsculas: a-z
+ Números: 0-9
+ Símbolos: !@#$%^&*
Exemplo válido: "K9#mPx$vL2@nQ4"

Armazenamento de senhas

❌ INCORRETO:

Texto simples:
  password = "MiContraseña123"

MD5 (quebrado):
  password = "5f4dcc3b5aa765d61d8327deb882cf99"
  -> Decifrado em segundos com tabelas rainbow

SHA1 (fraco):
  password = "cbfdac6008f9cab4083784cbd1874f76618d2a97"
  -> Também vulnerável a tabelas rainbow

✅ CORRETO:

bcrypt:
  password = "$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/X4.oUy..."
  -> Inclui salt automático
  -> Projetado para ser lento (resistente a força bruta)

Argon2 (recomendado):
  password = "$argon2id$v=19$m=65536,t=3,p=4$..."
  -> Resistente a ataques com GPU

Fluxo de recuperação de senha

O processo de "Forgot Password" é um vetor comum de ataque quando não é implementado com controles adequados. É necessário validar a segurança do fluxo de recuperação de senhas, verificando aspectos como:

  • Links de uso único e expiração curta.
  • Impossibilidade de reutilização de tokens.
  • Proteção contra força bruta.
  • Integração com segundo fator de autenticação (2FA) para validação de identidade do usuário.

Como verificar?

  1. Revise o código da sua aplicação na funcionalidade de cadastro e troca de senha.
  2. Busque a função de hash utilizada.

Se encontrar:

Resultado Avaliação
bcrypt.hash() ou argon2.hash() ✅ Seguro
hashlib.md5() ou hashlib.sha1() ❌ Inseguro, alterar o mais rápido possível.
Senha armazenada sem hash ❌ Crítico, alterar imediatamente

Autenticação multifator (MFA)

Usar MFA é crucial porque adiciona uma camada de defesa que neutraliza muito bem os ataques a contas, mesmo que a senha tenha sido roubada ou vazada. Ao exigir uma segunda prova de identidade que apenas o usuário possui (TOTP, chaves de segurança, notificações push ou biometria), evita o sequestro de contas por phishing ou força bruta, protegendo assim a integridade dos dados sensíveis e a confiança dos usuários na aplicação.

Recomenda-se que os seguintes tipos de usuários tenham MFA:

  • Administradores (obrigatório).
  • Operadores com acesso a funcionalidades sensíveis (altamente recomendado).
  • Usuários regulares (recomendado para ações importantes).

As seguintes operações são consideradas críticas e devem ser protegidas com MFA:

Acesso administrativo e gestão de contas:

  • Login inicial, especialmente em painéis de controle (backoffice) do integrador.
  • Troca de credenciais.
  • Gestão de funções e permissões.
  • Operações sobre vendas que gerem uma mudança importante.
  • Gestão de dados sensíveis ou informações de identificação pessoal (PII).
  • Mudanças críticas no negócio (gestão de publicações, alterações de preços, estoque).

Por que é crucial? Veja um exemplo:

FLUXO DE AUTENTICACAO: SEGURANÇA COM E SEM MFA

SEM MFA (INSEGURO)

1. Atacante obtém a senha --> 2. Faz login
--> 3. ACESSO COMPLETO ❌
   (Risco crítico - Conta comprometida)

---------------------------------------------------

COM MFA (RECOMENDADO)

1. Atacante obtém a senha --> 2. Tenta fazer login
--> 3. Sistema solicita Código MFA --> 4. ACESSO NEGADO ✅
   (Atacante NÃO tem o               (Ataque bloqueado)
   dispositivo/app)

Proteção contra ataques de força bruta

Um vetor de ataque comum é quando o atacante testa milhares de combinações de usuário/senha por segundo usando ferramentas automatizadas. Sem um mecanismo de proteção adequado, é apenas uma questão de tempo até que adivinhe credenciais válidas.

É por isso que ter os seguintes controles pode prevenir que isso aconteça:

  • Limites de tentativas: máximo de 5 tentativas falhas por conta.
  • Política de bloqueio temporário: 15 - 30 minutos após exceder as tentativas.
  • CAPTCHA: exibir desde o início e após 3 tentativas falhas.
  • Notificação via e-mail alertando o usuário sobre tentativas de login falhas e bem-sucedidas, com a localização de onde foram feitas as tentativas, com horário e dispositivo.

Veja como se comporta um sistema vulnerável vs. um protegido frente a ataques de força bruta:

❌ SEM PROTEÇÃO:

Atacante:
Tentativa 1:  admin / 123456    --> ❌ Incorreto
Tentativa 2:  admin / password  --> ❌ Incorreto
Tentativa 3:  admin / admin123  --> ❌ Incorreto
... (continua automaticamente)
Tentativa 10.000: admin / @Dm1n2026! --> ✅ Correto!

---------------------------------------------------

Tempo total: ~5 minutos com ferramenta automatizada
☹️ Resultado: Atacante tem acesso

✅ COM PROTEÇÃO:

Atacante:
Tentativa 1: admin / 123456   --> Incorreto
Tentativa 2: admin / password --> Incorreto
Tentativa 3: admin / admin123 --> Incorreto + CAPTCHA aparece
Tentativa 4: admin / qwerty   --> Incorreto + CAPTCHA
Tentativa 5: admin / letmein  --> Incorreto

⛔ CONTA BLOQUEADA POR 30 MINUTOS
[mail] E-mail enviado ao usuário: "Detectamos tentativas..."

---------------------------------------------------

⏳ Tempo para 10.000 tentativas: ~1000 horas
✅ Resultado: Atacante não pode continuar + Usuário alertado

Como verificar se estamos protegidos?

Nota:
O ideal é que seja usado um ambiente de desenvolvimento que simule o ambiente produtivo em todas as suas características.
  1. Tente fazer login com senha incorreta 6 ou mais vezes.
  2. Observe o que acontece:
Comportamento Resultado
Posso continuar tentando sem limite ❌ Sem proteção
CAPTCHA aparece após 3 tentativas ✅ Proteção básica
Conta bloqueada temporariamente ✅ Proteção forte
Recebo notificação de tentativas falhas ✅ Proteção + alertas

Gestão de sessões

Para proteger seus usuários, as sessões devem: ser geradas de forma segura, expirar a tempo, ser regeneradas após autenticação e invalidadas completamente ao encerrar a sessão. A seguir, os pontos-chave:

  • Tokens de sessão seguros: usar tokens gerados com funções criptográficas seguras.
  • Timeout por inatividade: encerrar a sessão após um tempo considerado (a ser definido pelo integrador).
  • Timeout absoluto: encerramento máximo de sessão de 8 a 12 horas (ou que represente o tempo de trabalho diário de um usuário na plataforma para solicitar re-login).
  • Regeneração de ID de sessão: sempre criar um novo ID de sessão após login e inativar as demais sessões ativas.
  • Logout seguro: invalidar a sessão no servidor e permitir encerrar todas as sessões ativas.

Uso de cookies de sessão

Caso utilize cookies para sessões, procure manter ativos os atributos Secure, HttpOnly e SameSite. Esses mecanismos garantem que os cookies não sejam acessíveis por terceiros sem autorização.

Compare sua implementação atual de cookies com estes cenários:

❌ INCORRETO - Cookie inseguro:

Set-Cookie: session=abc123

Problemas:

  • Pode ser roubado por um Javascript malicioso.
  • Pode ser enviado pelo protocolo inseguro HTTP (sem criptografia).
  • Pode ser enviado a outros sites maliciosos (CSRF).

✅ CORRETO - Cookie seguro:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

Atributos:
- Secure:        Somente enviado por HTTPS
- HttpOnly:      Não acessível via JavaScript
- SameSite=Lax:  Protege contra CSRF

Como verificar os cookies do meu site?

  1. Abra a aplicação no navegador.
  2. Pressione F12 ou clique com o botão direito e inspecionar.
  3. Vá à seção Application > Cookies.
  4. Revise o cookie de sessão:
Atributo Deve estar
Secure ✓
HttpOnly ✓
SameSite Lax ou Strict

Referências


Glossário

Termo Significado
Autenticação Verificar a identidade de um usuário (confirmar que é quem diz ser)
MFA / 2FA Autenticação multifator / de dois fatores. Requer algo que você sabe (senha) + algo que você tem (celular) ou algo que você é (impressão digital).
TOTP Time-based One-Time Password. Código de 6 dígitos que muda a cada 30 segundos (Google Authenticator, Authy)
Força bruta Ataque que testa todas as combinações possíveis de senhas até encontrar a correta
Hardcodear Escrever credenciais diretamente no código-fonte (má prática)
Rate limiting Limitar quantas tentativas de login são permitidas por minuto/hora para frear ataques
CAPTCHA Teste para verificar que o usuário é humano, não um bot automatizado
Hash de senha Transformação irreversível da senha para armazená-la de forma segura
Salt Valor aleatório adicionado à senha antes de aplicar o hash para prevenir ataques de dicionário


Próximo: Controle de acesso e autorização.