Segurança

A segurança do BriefingNews Bot é projetada com o princípio de "seguro por padrão" (secure-by-default): na ausência de configuração, os acessos permanecem fechados, não abertos. Validamos toda entrada não confiável na borda e minimizamos os dados expostos em cada resposta.

Nossa arquitetura é multi-tenant: separamos rigorosamente os dados e as configurações de cada usuário e de cada servidor Discord conectado.

A autenticação usa o better-auth com e-mail/senha e verificação de e-mail obrigatória. As senhas são armazenadas apenas como hash criptográfico, nunca em texto claro. Oferecemos login social (GitHub, Google e Discord) e autenticação em dois fatores (2FA) por código enviado por e-mail.

As sessões são mantidas em cookies HttpOnly first-party (inacessíveis a scripts do navegador) e escopados apenas aos subdomínios da aplicação. O tráfego entre o frontend e a API passa por um proxy de mesma origem, mantendo o cookie de sessão restrito e nunca expondo a URL bruta da API ao navegador.

O acesso é controlado por uma matriz de papéis (RBAC), do menor para o maior privilégio: usuário, estudante, professor, coordenador, administrador e super-administrador. Nenhum usuário promove outro acima do próprio nível.

Além de "quem você é" (RBAC), verificamos "o que você contratou" (entitlements do plano) e a propriedade dos recursos: antes de configurar os canais de um servidor Discord, confirmamos que você é dono daquele servidor, prevenindo acesso indevido a recursos de terceiros (IDOR).

Aplicamos limitação de requisições por IP (rate limiting), cabeçalhos de segurança HTTP via Helmet e uma política de CORS restrita apenas às origens oficiais do frontend — nunca curinga com credenciais. A configuração de proxy confiável é fixada para impedir a falsificação do IP de origem (spoofing de X-Forwarded-For) que burlaria o rate limiting.

Chaves de API internas são comparadas em tempo constante (constant-time) para evitar ataques de temporização, e permanecem fechadas por padrão quando não configuradas.

A ingestão de feeds externos passa por um guard de proteção contra SSRF (Server-Side Request Forgery), que valida e restringe as URLs buscadas — este componente é coberto por testes automatizados com meta de cobertura elevada.

Os dados são armazenados em PostgreSQL gerenciado (Neon, região São Paulo — Brasil). Todo acesso ao banco usa consultas parametrizadas via Drizzle ORM; nunca construímos SQL por concatenação de strings, e qualquer identificador dinâmico é tratado por lista de permissão — prevenindo injeção de SQL.

As métricas e painéis agregados são projetados para não conter dados pessoais identificáveis (PII). Expomos nas respostas da API apenas os campos estritamente necessários, jamais linhas cruas do banco, segredos ou tokens.

Os pagamentos são processados pelo gateway Asaas. Não coletamos, transmitimos nem armazenamos dados de cartão de crédito — essa responsabilidade é do provedor de pagamento, em conformidade com o padrão PCI. Guardamos apenas um espelho do estado da assinatura (plano e status).

Os webhooks de cobrança são verificados e processados de forma idempotente (uma reentrega do mesmo evento não aplica a cobrança duas vezes), e o token de webhook é rotacionável.

A aplicação roda na Railway, com terminação de TLS na borda, garantindo criptografia em trânsito (HTTPS). O banco de dados é hospedado na Neon.

Segredos (credenciais de banco, chaves de autenticação, tokens de pagamento e de e-mail, chaves de provedores sociais e de IA) vivem exclusivamente como variáveis de ambiente protegidas na Railway e nos GitHub Secrets — nunca são versionados no código nem registrados em logs. As migrações de banco são aplicadas de forma controlada e explícita, nunca automaticamente no boot.

O consentimento legal é versionado e aplicado de forma fail-closed: enquanto um documento obrigatório estiver pendente, o acesso às rotas protegidas é bloqueado. Os aceites são registrados em base imutável (append-only), com data, IP e user-agent, como prova de conformidade com a LGPD. Consulte a Política de Privacidade para detalhes sobre o tratamento de dados.

A aplicação expõe uma sonda de saúde (health check) que verifica o banco de dados e a conexão com o Discord, e realiza desligamento gracioso ao receber sinais de encerramento. Dispomos de mecanismos de reversão (kill-switches de recursos, redeploy de versões anteriores) para mitigar incidentes rapidamente.

Em caso de incidente de segurança com risco relevante aos titulares, comunicaremos os afetados e a Autoridade Nacional de Proteção de Dados (ANPD) conforme a LGPD.

Se você identificar uma potencial vulnerabilidade, pedimos que a reporte de forma responsável e privada para administrativo@briefingnews.com.br, sem explorá-la nem divulgá-la publicamente antes da correção. Analisaremos e responderemos com a devida prioridade.