Termos de Uso

Última atualização: 31 de agosto de 2026

Estes Termos de Uso ("Termos") regem o acesso e o uso da plataforma Guarita ("Guarita", "nós", "nosso"), operada por PCL DE SOUZA TECNOLOGIA, inscrita no CNPJ sob o nº 44.638.580/0001-12. Ao criar uma conta ou usar a Guarita, você ("você", "usuário") concorda com estes Termos. Se não concordar, não use a plataforma.

1. O que a Guarita faz

A Guarita é uma ferramenta de análise de segurança automatizada ("pentest como produto") para aplicações web. Ela executa verificações de configuração e exposição a partir da URL pública de um app, gera um relatório em português e, nos planos pagos, um prompt de correção pronto para uso em ferramentas de IA.

A Guarita não substitui uma auditoria de segurança humana completa. Ela cobre as falhas mais comuns e exploradas primeiro; a ausência de achados não garante que o app esteja livre de vulnerabilidades.

2. Uso autorizado — regra essencial

Você só pode escanear aplicações que você controla ou para as quais tem autorização expressa do responsável.

Escanear sistemas de terceiros sem autorização pode violar a Lei nº 12.737/2012 (Lei Carolina Dieckmann), o Marco Civil da Internet (Lei nº 12.965/2014) e outras normas. Ao iniciar uma análise, você declara e garante que tem essa autorização. Você é o único responsável pelos alvos que submete. Cada declaração é registrada como evidência (ver §2.1). Podemos suspender ou encerrar contas que violem esta regra, sem aviso e sem reembolso.

A ronda não é só leitura — e você precisa saber disso antes de autorizar. Para provar um achado em vez de apenas suspeitar dele, algumas verificações escrevem no alvo: sobem um arquivo, criam uma conta de teste, inserem um registro. O §2.2 lista o que é escrito, em qual modo, o que a Guarita limpa depois e o que ela não limpa. Os recursos mais intrusivos não são promessa futura — já estão em produção: são opt-in, exigem plano compatível, exigem posse comprovada do domínio e, no modo agressivo, uma confirmação explícita de autorização a cada ronda.

2.1 Antiabuso, monitoramento e registro de autorização

Para proteger alvos legítimos e a própria plataforma, monitoramos padrões de uso. Constitui abuso grave, sujeito a suspensão ou encerramento imediato da conta, sem aviso prévio e sem reembolso — e, conforme o caso, à comunicação às autoridades competentes e aos provedores afetados:

usar a Guarita para reconhecimento de alvos que você não controla ou para os quais não tem autorização — inclusive escanear, de forma repetida, múltiplos domínios de terceiros sem relação com você (padrão típico de reconhecimento ofensivo);
declarar autorização falsamente (o checkbox de autorização): além de violar estes Termos, configura abuso de direito (Código Civil, art. 187) e pode caracterizar ilícito civil e penal;
contornar a blocklist, os limites de uso justo, as cotas ou a verificação de propriedade do domínio;
escanear alvos sediados em outras jurisdições sem autorização, sujeitando você (e a Guarita) a leis estrangeiras (por exemplo, CFAA nos EUA ou o Computer Misuse Act no Reino Unido).

Registro de autorização (evidência). A cada análise, registramos de forma imutável a sua declaração de autorização: data e hora, o alvo, a versão destes Termos vigente no aceite e dados de atribuição da requisição (como o endereço IP). Esse registro é retido mesmo após a remoção do scan pela política de retenção e pode ser conservado após o encerramento da conta, para apuração de abuso e defesa em eventual processo (LGPD, art. 16, II). Ele protege você (comprova que você declarou ter autorização) e fundamenta a responsabilização em caso de uso indevido.

Dados revelados pela análise. O scan pode expor dados pessoais presentes no seu app (por exemplo, e-mails ou registros acessíveis publicamente). Ao submeter um alvo, você declara ter base legal para tratar esses dados e para que a Guarita os processe em seu nome ao gerar o relatório — nessa parte, você é a controladora e a Guarita atua como operadora. Você é responsável por esses dados e nos isenta de reclamações de terceiros decorrentes de alvos que você não estava autorizado a escanear.

2.2 O que a ronda escreve no seu app

Num produto de segurança, autorizar de olhos abertos é o mínimo. Então segue a lista, sem eufemismo — o que a ronda escreve, em qual modo, e o que ela limpa.

Antes da lista, o corte que mais importa: na ronda que você inicia no painel, nada disso acontece antes de você comprovar a posse do domínio. Ali só rodam as verificações que leem a superfície pública, o DNS, o TLS e o código já publicado. O que segue vale a partir do domínio verificado — e as rondas automáticas têm uma ressalva própria, no fim desta seção.

Ronda padrão, em domínio verificado — arquivo-canário. A verificação de métodos HTTP envia um PUT com um arquivo de texto pequeno e de nome próprio (guarita-scanner-<identificador>.txt) e, em seguida, um GET para conferir se o conteúdo voltou igual. É o que separa "o seu servidor aceita upload de arquivo arbitrário" de "o CDN responde 200 para qualquer coisa" — sem isso, a falha mais grave desse módulo viraria alarme falso em todo site estático. Esse arquivo não é apagado pela Guarita: ele só existe se o upload foi de fato aceito, e nesse caso ele é a própria evidência do problema. Ao fechar o PUT, remova o arquivo.

Ronda padrão, em domínio verificado — teste de cadastro aberto. Para saber se qualquer pessoa da internet pode criar conta no seu app, a Guarita tenta um cadastro no seu Supabase ou Firebase com uma identidade descartável, gerada só para aquela ronda. Se o cadastro estiver fechado, nada é criado. Se estiver aberto, a conta é criada — e essa ronda não a remove. É o achado e a prova ao mesmo tempo; a conta tem endereço reconhecível e pode ser apagada por você.

Ronda padrão, em domínio verificado — chamada de funções de banco (RPC). Para testar se a autorização está no lugar, a Guarita invoca com corpo vazio as funções de banco que descobre no seu projeto Supabase e observa se elas respondem sem exigir credencial. Aqui existe um filtro: funções cujo nome indica destruição (delete, drop, reset, remove, truncate, purge, revoke, cancel, refund e afins) são puladas no código, justamente porque uma chamada sem argumentos poderia executar algo irreversível. Se a função reclamar de um parâmetro faltando, tentamos de novo com um valor de teste reconhecível (guarita-probe, guarita-probe@example.com ou um UUID zerado), para confirmar se ela de fato executa para um anônimo: uma vez com o parâmetro que a própria mensagem de erro nomear e, quando o erro não nomeia nenhum e o nome da função é claramente de leitura (get_, list_, check_, verify_ e afins), até dez tentativas com uma lista curta de nomes de parâmetro comuns. Função cujo nome não é de leitura nunca recebe parâmetro chutado. Ainda assim, invocar uma função é rodar código seu: se você tiver função com efeito colateral e nome inofensivo, esse efeito acontece.

Ronda iniciada no painel, em domínio verificado — chamada de Edge Functions. Aqui o sujeito é outro, e a verdade é mais dura: não há filtro por nome. A Guarita percorre uma lista fixa de nomes comuns de Edge Function e manda um POST de corpo vazio para cada um, para ver quais respondem sem credencial — e a lista inclui nomes destrutivos de propósito, porque uma função chamada delete-account que roda para qualquer anônimo é exatamente o achado grave que este teste existe para encontrar. Estão na lista, entre outros: delete-account, create-user, send-email, payment, process-payment, export-data, admin, export, upload e webhook. Leia como está escrito: se o seu app tiver uma Edge Function com um desses nomes e ela executar sem credencial, ela executa de verdade — a conta é apagada, o e-mail sai, a cobrança roda. Este teste vem junto do mapeamento de infraestrutura, que o formulário do painel sempre liga; as rondas automáticas descritas no fim desta seção não o incluem. Se algum desses nomes existe no seu projeto e o efeito é inaceitável, rode a ronda completa em *staging*, não em produção.

Testes autenticados ("greybox") — opt-in, postos Pro e Business. Quando você liga esses testes, a Guarita cria uma conta de usuário de teste no serviço de autenticação do seu app (Supabase ou Firebase), confirma o cadastro e, com essa sessão, tenta: inserir um registro de teste claramente marcado (guarita-scanner-test) nas tabelas/coleções descobertas, e subir um arquivo de teste nos buckets de armazenamento. Cada item criado tem uma tentativa de remoção imediatamente depois — best-effort: se a remoção falhar, o item permanece. No fim, a Guarita tenta apagar a conta de teste, e o resultado depende do serviço: no Firebase a conta se apaga com a própria sessão e normalmente vai; no Supabase a exclusão exige uma chave administrativa que a Guarita não tem, a tentativa é recusada e a conta de teste fica na sua base. Nos dois casos a remoção é *best-effort*: a conta tem endereço reconhecível e você pode apagá-la. Nessa mesma bateria, a Guarita testa o direito à exclusão sempre contra a própria conta de teste: chama funções de auto-exclusão de nome conhecido (delete_user, delete_account, lgpd_delete e afins) e tenta apagar a linha de perfil filtrada pelo id da conta de teste. Se uma dessas funções do seu app apagar mais do que o titular que a chamou, esse efeito é do código dela.

Teste de IDOR (dentro do greybox) — altera um dado que já era seu. Para provar que o seu app não confere quem é o dono do registro, a Guarita envia um PATCH num registro que não pertence à conta de teste, alterando um campo inofensivo (o carimbo updated_at). Isso modifica um dado preexistente do seu banco. É a única forma de provar escrita cruzada entre usuários em vez de apenas suspeitar dela; se esse efeito for inaceitável no seu ambiente, não ligue os testes autenticados.

Modo agressivo — opt-in, com confirmação a cada ronda. Além de tudo acima, o modo agressivo: tenta inserir um registro de teste nas tabelas descobertas usando só a chave anônima (e apagar em seguida o registro que criou), para provar que qualquer visitante escreveria no seu banco; dispara uma rajada pequena e limitada de tentativas de login (6) com um e-mail que não existe, para ver se há bloqueio por tentativas; chama o endpoint de IA do seu app, o que consome a sua cota no provedor de LLM; e autoriza a análise com IA a fazer escritas ativas para confirmar exploração. Duas travas se aplicam aqui: a IA é instruída a só apagar o que ela mesma criou e a nunca invocar funções destrutivas — e as funções destrutivas (delete, drop, reset, truncate e afins) são bloqueadas no código, não só no texto do pedido. É um limite forte, não uma garantia absoluta: ao ligar o modo agressivo, você está autorizando escrita no seu ambiente.

O que só roda quando você liga, e o que roda sozinho. Os testes autenticados, o modo agressivo e o pré-diagnóstico LGPD só acontecem quando você os liga, ronda a ronda — nenhuma automação os liga por você.

O resto da lista é diferente, e você precisa saber disso antes de ligar qualquer automação. Depois que você liga o plantão agendado (posto Starter+) ou a ronda a cada publicação (posto Pro+, pelo botão da integração Vercel ou Lovable, ou pelo seu CI chamando a nossa API), a ronda passa a começar sem clique nenhum: na cadência que você marcou, e a cada deploy. Nenhuma delas roda os testes autenticados nem o modo agressivo, e nenhuma chama Edge Functions. O que elas escrevem, porém, não é igual — e a diferença importa:

Plantão agendado e ronda disparada pelo seu CI (o webhook de deploy) rodam o conjunto padrão completo: sobem o arquivo-canário, tentam o cadastro aberto e chamam as funções de banco (RPC), exatamente como descrito acima.
Ronda pelo botão da integração Vercel ou Lovable roda um conjunto restrito ao endereço exato do projeto: ela sobe o arquivo-canário, mas não testa cadastro aberto nem chama funções de banco.

E há uma segunda diferença, sobre a POSSE, que preferimos dizer a deixar você descobrir. A ronda que sai do botão da integração Vercel ou Lovable só passa a escrever depois que a posse do app está comprovada — antes disso ela fica observacional, como a primeira ronda. Já o plantão agendado e a ronda disparada pelo seu CI rodam o conjunto padrão sem reconferir a posse: se você ligar qualquer um dos dois num app ainda não verificado, ele escreve do mesmo jeito. Ligue os dois só em app cuja posse você já comprovou. (O plantão do domínio inteiro do §2.4 é outro caso: lá a posse é reconferida a cada ciclo e a vigília se desliga sozinha se deixar de valer.)

Se o seu ambiente de produção não tolera algum desses efeitos, rode o intrusivo em *staging* — e, em qualquer caso, faça a ronda sabendo o que ela escreve. É por isso que esta seção existe.

2.3 Alterações temporárias na sua conta Cloudflare

Ao conectar a integração Cloudflare, você autoriza a Guarita a fazer duas alterações temporárias na zona conectada, pela duração da ronda:

Uma regra temporária de WAF — o *web application firewall*, o filtro da Cloudflare que barra requisição suspeita antes de ela chegar no seu app. Antes de começar, criamos na sua zona uma *custom rule* com ação dispensar (skip), que casa apenas as requisições que carregam um segredo de uso único daquela ronda num header próprio. Para essas requisições — e só para elas — as checagens do WAF são dispensadas, que é o que permite a ronda enxergar o seu app em vez de bater no bloqueio. A regra é acrescentada ao conjunto existente: não desliga o WAF, não altera nem apaga as suas regras, e elas seguem valendo para todo o resto do tráfego. Ela é removida ao fim da ronda.
Bot Fight Mode desligado, e só no plano gratuito da Cloudflare. Nesse plano ele roda fora do motor de regras — não dá para abrir exceção nele, a regra acima não o dispensa. Então, se ele estiver ligado, a Guarita registra o estado anterior, desliga durante a ronda e religa no fim. Sem eufemismo: essa é uma proteção sua que fica de fato suspensa enquanto a ronda roda, justamente no plano gratuito. É a única, é pelo tempo da ronda, e o desfazer tem a ressalva do parágrafo abaixo.

Isso só acontece para um app com posse comprovada e com zona conectada e ativa. Sem os dois, nada é criado na sua conta.

Desfazer é obrigação nossa. Toda alteração é registrada antes de ser feita, justamente para poder ser desfeita mesmo se a ronda cair no meio. Além do desfazer ao fim de cada ronda, um processo de reconciliação varre periodicamente o que ficou aberto — regra de pé e Bot Fight Mode desligado — e conserta; ao desconectar a integração ou excluir a conta, a limpeza roda antes de o acesso ser revogado. Ainda assim, desfazer é melhor esforço, com teto de 5 tentativas, e isso vale para as duas alterações: se a Cloudflare recusar de forma repetida, a regra pode sobreviver à ronda e o Bot Fight Mode pode continuar desligado. Nos dois casos nós registramos e alertamos, e você resolve pelo painel da Cloudflare — a regra é identificada como Guarita scan <id> (auto, temporária), e o Bot Fight Mode você religa nas configurações de bots da zona — ou desconectando a integração. Você pode revogar o nosso acesso na Cloudflare quando quiser; se revogar antes da limpeza, podemos ficar sem meio de desfazer o que fizemos, e o desfazer passa a depender de você.

2.4 Plantão do domínio inteiro: descoberta de hosts e escopo da autorização

No plantão do domínio inteiro (exclusivo do posto Business) você aponta um domínio raiz e a Guarita procura sozinha os hosts que existem debaixo dele — inclusive os que você nunca submeteu, e principalmente os que você já tinha esquecido. É esse o valor do recurso: o subdomínio esquecido é justamente o que costuma estar aberto.

De onde vêm os hosts. Quatro fontes: registros públicos de Certificate Transparency (consultados em crt.sh e api.certspotter.com); tentativa de resolução de DNS de uma lista fixa de 41 prefixos comuns (staging, api, admin, dev…); os projetos da sua conta Vercel, se a integração estiver conectada; e os registros A/AAAA/CNAME da zona Cloudflare, se a integração estiver conectada com permissão de leitura de DNS.

A sua autorização se estende aos hosts encontrados. Ao ligar o plantão, você declara e garante — pela regra do §2 — que tem autorização para o domínio raiz e para os hosts sob ele, incluindo os que a descoberta encontrar depois. Só ligamos o plantão para domínio raiz com posse comprovada: verificação na Guarita (meta tag, arquivo ou registro DNS) ou zona conectada e ativa na Cloudflare. A posse é reconferida a cada ciclo; se ela deixar de valer, o plantão se desliga sozinho.

Host de terceiro. Um host debaixo do seu domínio pode apontar para infraestrutura de outra empresa (um CNAME para um SaaS, por exemplo). Quando identificamos isso, o host entra no inventário marcado como de terceiro e nunca é escaneado — varrer a infra de outra empresa não está na sua autorização. Se aparecer no inventário um host que não é seu para autorizar, marque-o como ignorado e ele sai da vigília.

Nem todo host descoberto recebe ronda. Um host recém-descoberto entra no inventário e só passa a ser varrido depois de promovido à vigília. Há um teto de hosts em vigília ativa: no Business, 200 por conta — por conta, não por domínio, ainda que o número de domínios seja ilimitado. Acima do teto o host não é recusado: ele cai para o estado passivo e recebe apenas a ronda observacional (as verificações que leem a superfície pública, DNS, TLS e o código já publicado, sem sondar endpoints do host).

3. Conta

Você é responsável por manter a confidencialidade das suas credenciais e por toda atividade na sua conta. Avise-nos imediatamente em caso de uso não autorizado. As contas são pessoais e intransferíveis. Você deve fornecer informações verdadeiras no cadastro.

4. Planos, pagamento e reembolso

A ronda básica (verificações sem IA) é gratuita e ilimitada, sujeita a uso justo (limites anti-abuso).
As análises com IA e demais recursos seguem o plano contratado, conforme a página de Preços. As cotas renovam a cada ciclo.
Pagamentos recorrentes (mensal ou anual) são processados pelo provedor de pagamento (Stripe). A cobrança é automática até o cancelamento.
Garantia de 7 dias: você pode solicitar reembolso integral nos primeiros 7 dias da primeira assinatura, desde que tenha rodado no máximo 3 análises com IA no período — margem pensada pra você testar o serviço antes de decidir. A janela é contada da primeira assinatura e não reabre em reassinaturas.
Cancelamento: a qualquer momento, sem multa. O acesso ao plano permanece até o fim do período já pago; depois, a conta volta ao plano gratuito.

5. Uso aceitável

Você concorda em não: usar a Guarita para atividades ilícitas; escanear alvos sem autorização; tentar burlar limites de uso, cotas ou cobrança; revender ou redistribuir o serviço sem autorização; sobrecarregar, comprometer ou fazer engenharia reversa da plataforma; ou usar os resultados para facilitar ataques a terceiros.

6. Propriedade intelectual

A plataforma, a marca Guarita, o código e o conteúdo são nossos ou licenciados a nós. Os relatórios e prompts de correção gerados para os seus apps são seus — você pode usá-los livremente para proteger suas aplicações.

7. Isenções e limitação de responsabilidade

A Guarita é fornecida "no estado em que se encontra". Não garantimos que a análise encontrará todas as vulnerabilidades, nem que o app estará seguro após aplicar as correções sugeridas. Os prompts de correção são sugestões geradas automaticamente e devem ser revisados antes de aplicados.

Na máxima extensão permitida pela lei, nossa responsabilidade total fica limitada ao valor pago por você nos 12 meses anteriores ao evento. Não respondemos por danos indiretos, lucros cessantes ou perda de dados decorrentes do uso (ou da impossibilidade de uso) da plataforma.

8. Suspensão e encerramento

Podemos suspender ou encerrar o acesso em caso de violação destes Termos, especialmente da regra de uso autorizado (§2 e §2.1), inclusive de forma imediata e sem aviso nos casos de abuso ali descritos. Você pode encerrar sua conta a qualquer momento pelas configurações — a exclusão é definitiva e apaga seus dados conforme a Política de Privacidade, ressalvado o registro de autorização retido para apuração de abuso e defesa (§2.1).

9. Alterações

Podemos atualizar estes Termos. Mudanças relevantes serão comunicadas por e-mail ou na plataforma. O uso continuado após a vigência implica concordância.

10. Lei aplicável e foro

Estes Termos são regidos pelas leis da República Federativa do Brasil. Fica eleito o foro da comarca do Rio de Janeiro/RJ para dirimir controvérsias, salvo competência legal diversa do consumidor.

11. Contato

Dúvidas sobre estes Termos: <contato@guarita.dev>.