Política de Divulgação de Vulnerabilidades

Esta política também está disponível emEnglish.

1. Resumo em 30 segundos

• Encontrou uma falha? Mande para security@borai.app.br com passo a passo reproduzível, de preferência em português.
• Enquanto você seguir esta política, sua pesquisa é autorizada por nós. Não vamos processar você nem acionar autoridades por causa dela.
• Somos uma startup em estágio inicial. Não pagamos recompensa em dinheiro e não enviamos brindes. O que oferecemos hoje é reconhecimento público: Hall da Fama, menção nominal nas nossas postagens de segurança e um certificado verificável com o nível da sua descoberta.
• Proibido sem exceção: negação de serviço (DoS/DDoS), teste de carga e engenharia social. Também não toque em conta ou dado de outra pessoa.
• Um relatório sem prova de conceito manual não é triado.

2. Escopo: o que pode ser testado

Os alvos abaixo são operados pelo Borai e estão cobertos por esta política. Fora dessa lista, não há autorização.

Fora de escopo, sem exceção:

• Serviços de terceiros que usamos, como provedor de hospedagem, CDN, gateway de pagamento, provedor de e-mail, formulários, analytics e plataforma de feedback. Falha nesses produtos deve ser reportada ao fornecedor, não a nós. Se a falha for de configuração nossa dentro desses serviços, aí sim está em escopo.
• Contas, dispositivos e dados de qualquer pessoa que não seja você.
• Escritórios, funcionários, prestadores e infraestrutura física.
• Domínios e perfis que não estejam na tabela acima, incluindo redes sociais da marca.

3. O que mais nos interessa

Priorizamos por impacto real no negócio. Estes são os achados que fazem a nossa triagem parar tudo:

• Falha na validação de ingresso: forjar, duplicar ou reutilizar um QR code, ou fazer a portaria aceitar um ingresso inválido.
• Manipulação financeira: alterar preço, lote, cortesia, taxa, comissão de afiliado ou repasse de excursão.
• Autorização quebrada (IDOR): ler ou alterar evento, venda, lista de participantes ou relatório de outro organizador.
• Escalada de privilégio: participante virar promoter, promoter virar organizador, organizador virar administrador.
• Tomada de conta: falha em recuperação de senha, OTP, sessão, token ou login social.
• Exposição de dado pessoal: acesso a dados de participantes, freelancers, certificados ou álbuns de fotos fora da permissão prevista.
• Injeção e execução: SQL/NoSQL, comando, template, desserialização, SSRF, RCE.
• Segredos vazados: chave de API, token ou credencial ativa em repositório público, bundle, resposta HTTP ou histórico de build.
• Takeover de subdomínio comprovado.

4. Regras de teste

Sempre:

• Use exclusivamente contas criadas por você. Prefixe o nome com pentest- para facilitar nossa triagem.
• Identifique seu tráfego enviando o cabeçalho X-Bug-Bounty: seu-handle nas requisições. Isso separa pesquisa de ataque nos nossos logs e evita bloqueio.
• Pare no momento em que confirmar a falha. Um registro, uma linha ou um screenshot parcial já provam o acesso. Não pivote, não escale além do necessário, não vasculhe.
• Concentre teste destrutivo, fuzzing e injeção no ambiente beta.

Nunca:

• Negação de serviço e engenharia social, nas duas proibições absolutas detalhadas logo abaixo.
• Automação agressiva. Mantenha até 5 requisições por segundo e nada de varredura em massa de diretórios ou parâmetros em produção.
• Acessar, baixar, copiar, alterar ou apagar dado que não seja seu. Se o acesso a dado de terceiro for o próprio bug, veja a seção 8.
• Apagar ou corromper dados, contas ou eventos. Se precisar escrever algo, escreva em registro seu e marcado.
• Disparar e-mail, SMS ou notificação para endereços e números de outras pessoas.
• Instalar backdoor, manter persistência, ou deixar qualquer coisa rodando após o teste.
• Tornar a falha pública antes do combinado na seção 11.
• Condicionar a entrega dos detalhes a pagamento. Relatório com esse tipo de cobrança sai do programa e é tratado como incidente de extorsão.

5. O que não qualifica

Fechamos sem triagem os itens abaixo. Não é falta de educação: somos um time enxuto e cada relatório genérico atrasa a correção de um achado que importa.

• Saída bruta de scanner automático, sem prova de conceito manual e impacto demonstrado.
• Ausência de cabeçalho de segurança sem exploração concreta.
• Configuração de SPF, DKIM ou DMARC, sem um e-mail forjado que efetivamente chegue à caixa de entrada.
• Self-XSS, ou XSS que dependa da vítima colar código no console.
• CSRF em ação sem impacto, como logout, troca de tema ou inscrição em lista.
• Clickjacking em página sem ação sensível.
• Enumeração de usuário ou e-mail, sem impacto adicional demonstrado.
• Ausência de limite de tentativa, sem exploração concreta e bem-sucedida.
• Divulgação de versão de software, banner de servidor, arquivo de metadados público.
• Flags de cookie em cookie não sensível.
• Falha que exija navegador fora de suporte, dispositivo com root ou jailbreak, ou acesso físico ao aparelho destravado da vítima.
• Engenharia social, ataque físico, e qualquer forma de negação de serviço.
• Relatório de "boa prática" sem risco associado.
• Discordância com regra de negócio, preço, política de reembolso ou conteúdo do site.
• Falha já conhecida por nós ou já reportada por outra pessoa. Vale a primeira submissão válida.

6. Como reportar

Envie para security@borai.app.br um relatório por vulnerabilidade, contendo:

1. Título objetivo e sua estimativa de severidade, com vetor CVSS 3.1 se você usar.
2. URL, endpoint e parâmetro exatos, e em qual ambiente o teste foi feito.
3. Passo a passo reproduzível, executado manualmente.
4. Prova de conceito: requisição e resposta, captura de tela ou vídeo curto. Sem PoC reproduzível, o relatório é fechado.
5. Impacto no mundo real: o que um atacante consegue fazer com isso.
6. Sugestão de correção, se você tiver. É opcional e sempre bem-vinda.
7. Como quer ser creditado: nome, apelido, handle, link de perfil — ou anônimo.

Não anexe dado pessoal de terceiro que você tenha encontrado. Descreva o que viu, informe o volume estimado e, se precisar provar, envie um único registro com os campos sensíveis borrados.

Idioma do relatório

Escreva em português sempre que possível. Nosso time é brasileiro, e relatório em português é lido, entendido e triado mais rápido, sem nada se perder na tradução — especialmente em falha de regra de negócio, onde a nuance importa.

Quando não for possível, escreva em inglês. Aceitamos relatórios em inglês integralmente e sem prejuízo algum de tratamento, prazo ou reconhecimento. Se for mais confortável para você, esta política também está disponível em English.

Não recusamos relatório por causa do idioma, e não use tradutor automático se isso prejudicar a clareza técnica — inglês direto é melhor que português confuso.

7. Nossos prazos de resposta

Como classificamos a severidade

A severidade define o prazo de correção e é o nível que aparece no seu certificado. Usamos o CVSS 3.1 como referência, mas a classificação final é nossa e pondera o impacto no contexto do Borai: ingresso, dinheiro e dado de participante pesam mais que severidade teórica.

Se você discordar da classificação, argumente. Reclassificamos com frequência quando o pesquisador demonstra um caminho de exploração que não tínhamos enxergado, e o certificado é reemitido com o nível corrigido.

Prazos

O Borai é operado por um time pequeno. Preferimos publicar prazo folgado e cumprir a publicar prazo bonito e furar. Os prazos abaixo consideram o fuso de Brasília:

Se estourarmos um prazo, avisamos você antes de estourar, com o motivo e a nova data. Falha crítica em produção corta a fila: nesses casos trabalhamos em regime de urgência e você recebe atualização a cada poucos dias, independentemente da tabela.

Changelog de segurança: publicamos agregado

A cada semestre publicamos um balanço público de segurança. Ele é intencionalmente agregado, no formato "no período recebemos X relatórios válidos, sendo Y de autorização e Z de exposição de dado, com tempo médio de correção de N dias".

Não publicamos endpoint, parâmetro, payload, versão vulnerável, nem descrição técnica que permita reproduzir ou procurar variações da mesma falha. Isso não é falta de transparência: divulgar o mapa detalhado de cada correção entrega superfície de ataque a quem nunca reportou nada, e não acrescenta nada a quem reportou. O detalhe técnico fica entre você e a gente, e pode ir a público no write-up que você mesmo escrever, nas condições da seção 11.

8. Porto seguro (safe harbor)

Esta seção é a parte mais importante do documento para você.

Enquanto você seguir esta política, o Borai considera sua pesquisa uma atividade expressamente autorizada. Nesse caso, nos comprometemos a:

• não iniciar ação civil nem representação criminal contra você em razão da pesquisa;
• não comunicar sua atividade a autoridades como acesso não autorizado;
• declarar por escrito, inclusive publicamente, que a atividade estava autorizada, caso um terceiro questione ou acione você por ela;
• não tratar como violação de nossos Termos de Uso o teste realizado dentro destas regras.

A autorização importa porque o art. 154-A do Código Penal, incluído pela Lei nº 12.737/2012 e alterado pela Lei nº 14.155/2021, tipifica a invasão de dispositivo informático justamente quando ela ocorre sem autorização expressa ou tácita de quem o opera. Esta política é a autorização expressa, e vale apenas:

• para os alvos listados na seção 2;
• para as ações permitidas na seção 4;
• para quem reportar pelo canal oficial desta página.

Sair do escopo, acessar dado de terceiro sem necessidade, degradar o serviço, extorquir ou publicar antes do combinado encerra o porto seguro para aquele caso.

Esta autorização vincula apenas o Borai. Ela não alcança terceiros — provedores de infraestrutura, gateway de pagamento e demais fornecedores têm as próprias regras, e você continua sujeito à legislação aplicável.

9. Dados pessoais e LGPD

Se durante o teste você se deparar com dado pessoal de outra pessoa — nome, CPF, telefone, e-mail, foto, histórico de compra:

1. Pare imediatamente. Não continue a exploração para medir o tamanho do vazamento.
2. Não baixe, não copie, não armazene e não compartilhe o conteúdo.
3. Nos avise no relatório, com estimativa de volume e tipo de dado exposto.
4. Apague qualquer cópia acidental assim que confirmarmos o recebimento.

Seguir esses passos protege você e protege quem usa o Borai. Como controlador, temos o dever de comunicar a Autoridade Nacional de Proteção de Dados e as pessoas afetadas quando um incidente puder gerar risco relevante, nos termos do art. 48 da Lei nº 13.709/2018. Quanto mais preciso for o seu relato, mais correta é essa comunicação.

Os dados que você nos enviar no relatório — nome ou handle, e-mail e conteúdo técnico — são tratados para triagem, correção e crédito público, com base no legítimo interesse, e o crédito nominal só acontece com a sua autorização. Detalhes na Política de Privacidade.

10. Reconhecimento

Para todo relatório válido, único e corrigido, você recebe:

• Hall da Fama permanente nesta página, com o nome ou handle que você escolher e, se quiser, link para o seu perfil. A página é indexável e o crédito não é removido.
• Menção nominal nas postagens de segurança publicadas nos nossos canais a cada semestre, celebrando quem contribuiu no período.
• Certificado verificável com o nível da sua descoberta, hospedado em endereço público e permanente no nosso domínio. Detalhado logo abaixo.
• Resposta humana e técnica, sem formulário automático e sem silêncio.

Quando a plataforma abrir ao público, quem estiver no Hall poderá receber um selo no perfil dentro do app, se tiver conta e quiser. É um extra simbólico, não a essência do programa.

Certificado verificável

Todo relatório válido, único e corrigido gera um certificado, automaticamente e sem você precisar pedir. Ele é emitido pela própria plataforma Borai, pelo mesmo mecanismo que emite certificado de participação para quem vai a um evento na nossa plataforma. Não é um PDF montado à mão: passa pela mesma emissão, o mesmo código e o mesmo verificador que qualquer certificado nosso.

Cada certificado carrega um código de verificação impresso no documento. Qualquer pessoa — recrutador, cliente, banca — confere a autenticidade no verificador público, sem precisar de conta nem login, no endereço:

https://borai.app.br/certificados/verificar/<código>

A verificação é pública e independente de nós: você não precisa nos pedir confirmação, e quem consulta não depende de resposta nossa. O PDF é gerado sob demanda a partir do código, nunca fica armazenado, e o código continua válido indefinidamente.

Cada certificado exibe:

• Código de verificação único;
• Nome ou handle que você escolheu;
• Nível da descoberta — crítica, alta, média ou baixa —, conforme a escala da seção 7;
• Categoria ampla da falha, como "autorização" ou "validação de ingresso";
• Mês do relatório e data de emissão;
• Confirmação de que a falha foi corrigida e o relatório seguiu esta política.

Coerente com a regra de agregação da seção 7, o certificado não traz endpoint, parâmetro, payload nem qualquer detalhe que permita reproduzir a falha. Ele atesta a contribuição e o nível, não a receita.

Só revogamos um certificado se o crédito tiver sido obtido por fraude, como relatório copiado de terceiro ou falha forjada. Nesse caso o código passa a constar como revogado no verificador, e não simplesmente a desaparecer — histórico de segurança não se reescreve. Correção de mérito gera reemissão com o nível corrigido, não exclusão. Quem pediu anonimato recebe o certificado normalmente, sem entrar no Hall da Fama.

Sobre dinheiro e brindes, para não restar dúvida

Hoje o programa oferece somente os itens listados acima. Pretendemos, no futuro, incluir brindes físicos como adesivo, camiseta e moletom para achados de severidade alta e crítica, quando o caixa da empresa permitir. Isso é uma intenção declarada, não uma promessa.

• Nenhum relatório enviado hoje gera direito a recompensa, brinde ou pagamento futuro.
• Se a lista de recompensas mudar, a mudança será publicada nesta página, com regras próprias e sem efeito retroativo.
• Nada nesta página deve ser lido como oferta, promessa de pagamento ou obrigação de entrega de qualquer bem.

11. Divulgação coordenada

• Você pode publicar sobre o achado depois da correção, ou 120 dias após o nosso aceite de triagem, o que vier primeiro.
• Se precisarmos de mais prazo, pedimos e explicamos o porquê. Não temos direito de veto indefinido.
• A publicação não pode conter dado pessoal de usuário, segredo nosso ainda ativo, nem material suficiente para reexploração antes da correção estar no ar.
• Adoramos write-up técnico. Avise que a gente divulga junto e credita você.

12. Contato e vigência

Canal oficial para relatórios de segurança: security@borai.app.br. Este endereço também consta no nosso security.txt, conforme a RFC 9116.

Para assuntos que não sejam segurança, use contato@borai.app.br.

Podemos atualizar esta política a qualquer momento. A versão vigente é sempre a publicada nesta página, e vale para o relatório enviado enquanto ela estiver no ar.

13. Hall da Fama

Pessoas que reportaram falhas reais no Borai de forma responsável, da mais recente para a mais antiga. O crédito é permanente.

Cada entrada registra o nome ou handle escolhido pela pessoa, o nível da descoberta, a área afetada em termos amplos e o código do certificado, que leva ao verificador público. Seguindo a regra de agregação da seção 7, o Hall nunca publica detalhe técnico que permita reexplorar uma falha, nem dados de quem preferiu permanecer anônimo.