Segurança
Como relatar uma vulnerabilidade, o que prometemos em troca, e como o serviço é protegido.
Last updated: 2026-09-03
1. Como relatar uma vulnerabilidade
Envie um e-mail para security@aukimi.com. Este endereço também está publicado em https://aukimi.com/.well-known/security.txt. Por favor, relate de forma privada primeiro e nos dê a chance de corrigir o problema antes de divulgá-lo publicamente.
2. O que incluir
- O que você encontrou, e por que isso importa — o impacto, não apenas a técnica.
- Passos precisos para reproduzi-lo, com o URL, a conta usada e o horário.
- Uma prova de conceito limitada ao que demonstra o problema.
- Como você gostaria de ser creditado, caso queira.
3. Escopo
No escopo: aukimi.com, app.aukimi.com, academy.aukimi.com, os hosts multijogador em mp.aukimi.com, e a API pública.
- Fora do escopo: serviços de terceiros que usamos, mas não operamos — relate-os aos programas dos próprios serviços.
- Fora do escopo: achados de scanners automatizados sem impacto demonstrado, a mera ausência de cabeçalhos de hardening, ou relatos de que existe um limite de taxa (rate limit).
- Fora do escopo: engenharia social contra nossa equipe ou nossos usuários, ataques físicos, e qualquer coisa que degrade o serviço para outros.
4. Regras de conduta, e porto seguro
Se você seguir estas regras enquanto pesquisa de boa-fé, trataremos seu trabalho como autorizado, não o processaremos, e não pediremos a mais ninguém que o faça:
- Use apenas suas próprias contas e seus próprios dados. Pare ao primeiro sinal de que você pode alcançar os de outra pessoa.
- Não exfiltre, modifique ou destrua dados — uma captura de tela comprovando o acesso é suficiente.
- Nada de negação de serviço, nada de testes de carga, nada de spam.
- Dê-nos um tempo razoável para corrigir um problema antes de publicá-lo, e combine o momento conosco.
5. O que fazemos em troca
- Confirmamos o recebimento de um relato em até 5 dias úteis.
- Informamos nossa avaliação e um prazo de correção em até 10 dias úteis.
- Mantemos você informado até que seja corrigido, e o creditamos caso queira ser creditado.
Atualmente não operamos um programa de recompensas pago (bug bounty). Dizemos isso claramente em vez de deixar a questão ambígua.
6. Como o serviço é protegido
O que já está implementado, para que um relato possa ser direcionado a algo novo, e não ao que já sabemos:
- HTTPS em toda parte, HSTS, e uma política de segurança de conteúdo (CSP) que proíbe manipuladores de eventos inline.
- Senhas com hash usando bcrypt em 12 rounds; as sessões são JWTs assinados, fixados a um único algoritmo.
- Limitação de taxa (rate limiting) na autenticação, na API, e separadamente nos endpoints não autenticados.
- O login entre domínios usa códigos de autorização de curta duração e uso único, em vez de tokens em URLs.
- Os uploads são validados por seus magic bytes, têm os metadados EXIF removidos, e são servidos a partir de um caminho isolado (sandboxed); SVG é recusado sempre que um arquivo puder se tornar um documento.
- Os arquivos de ativos pagos são armazenados fora da árvore pública, de modo que é o pagamento que os desbloqueia, não a obscuridade.
7. Incidentes de dados e privacidade
Se uma vulnerabilidade expôs dados pessoais, diga isso em seu relato — as obrigações de notificação que se seguem são nossas, e o prazo começa a contar a partir do momento em que tomamos conhecimento. A Política de Privacidade estabelece como tratamos os dados pessoais.