Última atualização · 10 de junho de 2026 · Versão 1.0

Política de Segurança

Todo documento jurídico deste site é escrito em inglês, e é o texto em inglês que produz efeito. Publicamos traduções para que os termos sejam mais fáceis de ler no seu idioma, não para criar uma segunda versão deles. Uma tradução não obriga ninguém por si só e não substitui o documento em inglês. Onde a tradução e o texto em inglês disserem coisas diferentes, vale o texto em inglês.

Preferimos saber de uma falha por você a ler sobre ela em outro lugar. Esta página diz o que pedimos a quem pesquisa segurança, e com o que nos comprometemos em troca.

Se você acredita ter encontrado uma vulnerabilidade, escreva para [email protected]. Não precisa de permissão para começar, e não precisa ser cliente.

011. Porto seguro

Pesquisa feita de boa-fé e dentro desta política está autorizada. Não vamos mover nem apoiar ação judicial contra você por isso, e se um terceiro acionar você por pesquisa que seguiu estas regras, tornaremos público que ela era autorizada.

Boa-fé quer dizer que você parou assim que confirmou o problema, não levou mais dado do que o necessário para demonstrá-lo, e nos deu chance de corrigir antes de contar a mais alguém.

Na dúvida se algo é permitido, pergunte antes. Uma pergunta nos custa um e-mail; um mal-entendido pode custar muito mais a você.

022. Escopo

Dentro do escopo:

A API da nulvless e suas superfícies de autenticação, autorização, servidor OAuth, comunicações e observabilidade.
O Console.
Nosso site público.
Os SDKs oficiais que publicamos.

Fora do escopo:

Produtos que nossos clientes constroem sobre a nulvless. São deles; reporte a quem opera aquele produto.
Serviços dos quais dependemos mas que não operamos, como provedores de nuvem e CDN. Reporte ao provedor.
Qualquer conta ou dado que não seja seu, e qualquer projeto ao qual você não recebeu acesso.

033. O que não fazer

Estas são as linhas que transformam pesquisa em outra coisa:

Sem negação de serviço, teste de carga ou qualquer coisa que degrade o serviço para outras pessoas.
Sem acessar, alterar ou guardar dado de outro usuário ou de outro projeto. Se chegar a dado alheio por acidente, pare e nos avise.
Sem engenharia social com nossa equipe, nossos clientes ou nossos provedores. Sem phishing, sem pretexto, sem invasão física.
Sem varredura automatizada que gere tráfego significativo. Teste num volume que uma pessoa produziria.
Sem publicar detalhes antes de termos tido chance de corrigir.

Use a sua própria conta e o seu próprio projeto de teste. Criar um é gratuito.

044. Como reportar

Escreva para [email protected]. Inclua o suficiente para reproduzirmos sem adivinhar:

Qual é o problema, e o que um atacante faria com ele.
Passos para reproduzir, em ordem.
O ambiente: qual endpoint, qual projeto, mais ou menos quando.
O que ajudar — uma requisição, uma captura de tela, uma gravação curta.

Escreva em português ou inglês, como preferir.

Reporte um problema por mensagem. Vários achados no mesmo tópico demoram mais para triar e são mais fáceis de perder.

055. O que acontece depois

Quando	O que fazemos
Em até 3 dias úteis	Confirmamos que recebemos o seu relato.
Em até 10 dias úteis	Dizemos se conseguimos reproduzir e como avaliamos a severidade.
Enquanto trabalhamos	Mantemos você informado em momentos que importam, em vez de num calendário fixo.
Depois de corrigido	Avisamos você, e combinamos se e como tornar público.

Se concluirmos que algo não é vulnerabilidade, explicamos por quê em vez de fechar a conversa em silêncio. Você pode discordar, e dizer isso.

066. Reconhecimento

Não mantemos programa pago de recompensa hoje. Somos um time pequeno, e prometer dinheiro que não orçamos seria pior do que dizer isso com todas as letras.

O que oferecemos: crédito nesta página para quem quiser, e um reconhecimento por escrito que você pode mostrar. Se isso não compensa o seu tempo, entendemos — e ainda assim preferimos que nos conte.

077. Coisas que já sabemos

Relatos sobre os itens abaixo geralmente não são tratados como vulnerabilidade por si só, a menos que você mostre um caminho concreto de exploração:

Headers de segurança ausentes, sem impacto demonstrado.
Saída de scanner automatizado, enviada sem reprodução que funcione.
Fraquezas em configuração de entrega de e-mail, como SPF ou DMARC em domínios que não enviam mensagem.
Números de versão revelados por banner ou header.
Ataques que exigem que a vítima já esteja comprometida, ou que instale algo.
Limites de taxa que você considera generosos demais, sem um caminho de abuso demonstrado.

Isso não é descartar a categoria. É dizer que o achado precisa de um impacto anexado a ele.