Skip to main content

Arquitetura de Segurança

O tupynambalucas.dev implementa uma estratégia de segurança em camadas para proteger os dados da comunidade e garantir a integridade dos ciclos de compartilhamento. Nossa abordagem combina protocolos padrão da indústria com proteção especializada contra bots e mitigação de força bruta.

1. Proteção contra Bots (Cloudflare Turnstile)​

Para evitar cadastros e tentativas de login automatizados, utilizamos o Cloudflare Turnstile. Ao contrário dos CAPTCHAs tradicionais, o Turnstile oferece uma experiência de verificação não intrusiva e focada em privacidade.

1.1. Integração no Lado do Cliente (React 19)​

O AuthFeature utiliza o componente @marsidev/react-turnstile no Managed Mode.

  • Managed Mode: Exibe uma caixa de seleção inteligente que verifica se o usuário é humano.
  • State Management: O botão de envio permanece desativado até que um turnstileToken válido seja emitido pelo widget.
  • Isolation: Cada formulário (Login/Registro) mantém sua própria instância do Turnstile por meio de chaves exclusivas do React para garantir uma validação nova ao alternar o modo.

1.2. Validação no Lado do Servidor (Fastify 5)​

A API não confia apenas no estado do lado do cliente.

  • Verification: O AuthService realiza uma requisição POST segura para https://challenges.cloudflare.com/turnstile/v0/siteverify.
  • IP Validation: O endereço IP do cliente é passado para o Cloudflare para detectar botnets baseadas em proxy.
  • Mandatory DTOs: O LoginDTOSchema e o RegisterDTOSchema em @repo/hub/core exigem estritamente o turnstileToken.

2. Mitigação de Força Bruta​

Protegemos nossos endpoints de autenticação contra ataques de dicionário e adivinhação automatizada por meio de dois mecanismos principais.

2.1. Rate Limiting​

Utilizando @fastify/rate-limit, aplicamos limites específicos de contexto a rotas sensíveis.

  • Global Policy: Um limite base de 100 requisições por minuto por IP para o uso geral da API.
  • Strict Auth Policy: As rotas /api/auth/login e /api/auth/register são limitadas a 5 tentativas por minuto por IP.
  • Return Code: O excedente desses limites aciona uma resposta 429 (Too Many Requests).

2.2. Lógica de Bloqueio de Conta​

Para evitar ataques direcionados a contas de usuários específicos:

  • Max Attempts: Após 5 tentativas consecutivas falhas, a conta é bloqueada.
  • Lock Duration: A conta permanece inacessível por 15 minutos (lockUntil).
  • Persistence: O estado de bloqueio é armazenado diretamente no modelo User do Mongoose (loginAttempts, lockUntil).

3. Proteção e Ofuscação de Dados​

3.1. Prevenção de Enumeração de Usuários​

A API foi projetada para vazar o mínimo possível de informações sobre o estado do sistema para usuários não autenticados.

  • Generic Errors: Tanto "User Not Found" quanto "Invalid Password" retornam um código de erro unificado INVALID_CREDENTIALS.
  • Uniform Response Time: Comparações criptográficas (Bcrypt) são realizadas mesmo se o identificador do usuário não existir, prevenindo ataques de tempo (timing attacks).

3.2. Comunicação Segura​

  • JWT (HS256): Todas as requisições autenticadas exigem um JSON Web Token assinado com um segredo simétrico forte.
  • CSRF Protection: @fastify/csrf-protection está ativado, exigindo um cabeçalho CSRF-Token para todas as requisições que alteram estado (POST, PUT, DELETE).
  • HTTP-Only Cookies: Os tokens de sessão são armazenados em cookies assinados e HTTP-only para mitigar roubo de token baseado em XSS.

4. Requisitos de Ambiente​

As seguintes chaves de segurança são obrigatórias para a operação da stack do Hub. Cada variável reside no arquivo .env pertencente à aplicação responsável, seguindo o princípio de isolamento de Bounded Context do projeto.

4.1. API (hub/services/api/.env.*)​

VariávelPropósitoAmbientes
TURNSTILE_SECRET_KEYVerificação de token do Cloudflare Turnstile no lado do servidor.dev, prod, staging
JWT_SECRETAssinatura e verificação de JSON Web Tokens.dev, prod, staging
SESSION_SECRETCriptografia de cookies de sessão assinados e HTTP-only.dev, prod, staging
MONGO_URIString de conexão do MongoDB. O dev usa Replica Set local; prod/staging usam o MongoDB Atlas (mongodb+srv://).dev, prod, staging

4.2. Web (hub/services/web/.env.* / Docker ARG)​

VariávelPropósitoMétodo de Injeção
VITE_TURNSTILE_SITE_KEYChave pública do site para renderizar o widget do Turnstile.Dev local: lida de .env.dev pelo Vite (--mode dev). Produção: injetada como ARG do Docker durante a construção da imagem — embutida estaticamente no bundle JS.
warning

Important: VITE_TURNSTILE_SITE_KEY é uma chave pública (segura para ser embutida em bundles do cliente). O TURNSTILE_SECRET_KEY é privado e deve existir apenas no ambiente da API, nunca na aplicação Web ou commitado no controle de versão.

Última atualização: Junho de 2026