Gerencie o seu app
Segurança
Manage, depois Security: uma varredura rápida ou profunda do seu app, o que ela encontrou e a correção de cada problema, o contexto que a deixa mais inteligente e as bibliotecas que o Setherion mantém atualizadas.
Security lê o código do seu app em busca de vulnerabilidades e configurações arriscadas: abra Manage e depois Security.
Duas varreduras
| Quick scan | Deep scan | |
|---|---|---|
| O que lê o código | Um modelo rápido | O modelo que você escolheu acima do chat |
| O que ela procura | Os erros comuns: XSS, chaves secretas escritas no código, entradas que não são higienizadas e tabelas que qualquer pessoa poderia ler ou escrever | Tudo o que a varredura rápida faz, mais problemas específicos deste app: a lógica dele, quem pode ver o quê e suas tabelas |
| Quanto tempo leva | Segundos | Mais tempo |
Cada uma custa créditos, e o preço está escrito ao lado do botão dela, com a data em que rodou pela última vez. Clicar no bloco Security em Visão geral inicia uma varredura rápida se nenhuma tiver rodado, e gasta esses créditos. Out of date significa que o código mudou desde então. Quando nada no código ou no contexto mudou desde a última varredura, a página diz isso.
Scan on publish, na varredura rápida, a executa sozinha depois de cada publicação que mudou o código, pelo mesmo preço. Ela fica desativada até você ativá-la. A janela Publish tem o mesmo interruptor. Veja Publicar na web.
O que ela encontrou
Detected issues lista cada problema, com a gravidade, onde ele está e o que fazer.
- Send to chat to fix coloca a correção no chat, para você ler e enviar. Fix all in chat faz isso para todos os problemas de uma vez.
- Quando um problema é uma coleção que qualquer pessoa pode ler, Require sign-in ou Close to your team a fecha na hora, sem mudar o código. Veja Quem pode ver o quê.
- Depois de uma correção, os problemas são verificados de novo, e a lista diz quais sumiram e quais continuam.
“No issues found” significa que a varredura não encontrou nada. Ela lê o código atrás de erros comuns, então não pode descartar todos os riscos.
Adicionar contexto
O verificador conhece só o código. Add context, no alto à direita, conta a ele o que o código não pode contar: para que serve o app, quem o usa, que dados ele guarda e o que é proposital.
A shop for a bakery. Customers order without an account. We store names,
phone numbers and addresses for delivery. The menu and prices are public on purpose.Com isso, um cardápio público não é apontado como vazamento, e os pedidos com endereços são verificados como os dados privados que são.
Bibliotecas
React, Supabase e as outras bibliotecas em que todo app roda são mantidas pelo Setherion e verificadas a cada lançamento quanto a problemas de segurança conhecidos. Não há nada para você atualizar. O cartão mostra No known issues e a data da última verificação.
Sempre ativas
Algumas proteções não esperam por uma varredura:
- Uma chave secreta escrita no código do app nunca é publicada. A publicação é recusada, sem cobrança, qualquer que seja o resultado da varredura, e a mensagem nomeia o tipo de chave e o arquivo e a linha. A verificação reconhece as chaves dos serviços comuns de IA, pagamento, e-mail, mensagens e hospedagem de código, chaves privadas e as chaves de administrador de um projeto Supabase. Chaves que são públicas por design, como uma anon key do Supabase ou uma publishable key do Stripe, são deixadas em paz.
- As chaves dos serviços conectados ficam nos servidores do Setherion, e o app publicado faz as chamadas por meio do Setherion.
- Um registro só é lido por quem o salvou e por sua equipe, até você abri-lo em Access rules.
- Toda criação e toda mudança são abertas fora da vista antes de você vê-las, e devolvidas para reparo se travarem. Veja Antes de ir ao ar.
- No Business, um app pode ser tornado privado, de modo que só as pessoas logadas do seu espaço de trabalho o abrem. Veja Visibility.
- Os e-mails que o app envia param por conta própria se muitos voltarem ou forem marcados como spam. Veja E-mails.
Esta página foi útil?
