Segurança

Práticas de segurança implementadas na plataforma AssessIQ.

Visão Geral

O AssessIQ aplica múltiplas camadas de segurança para proteger dados de usuários, sessões e endpoints.

---

Autenticação

Login via POST

Credenciais enviadas no corpo da requisição (JSON), nunca via URL ou query params.

Bcrypt

Senhas armazenadas com bcrypt (cost factor 10). Nunca armazenadas em texto plano.

Sessão JWT

Cookie next-auth.session-token com flags HttpOnly e Secure. Inacessível via JavaScript.

2FA

Suporte a autenticação de dois fatores via e-mail OTP ou TOTP.

Revogação de Sessão

Toda sessão carrega um sessionVersion validado a cada request. Ao alterar senha, revogar sessão ou atualizar permissões, o sessionVersion é incrementado e todas as sessões ativas são invalidadas imediatamente.

---

Headers HTTP de Segurança

Adicionados globalmente via next.config.ts, aplicados em todas as rotas (/(.*)):

Header	Valor	Proteção
X-Frame-Options	SAMEORIGIN	Anti-clickjacking
X-Content-Type-Options	nosniff	Anti-MIME sniffing
Strict-Transport-Security	max-age=31536000; includeSubDomains; preload	Força HTTPS por 1 ano
Referrer-Policy	strict-origin-when-cross-origin	Limita dados no Referer
Permissions-Policy	camera=(), microphone=(), geolocation=()	Desativa APIs de browser
X-XSS-Protection	1; mode=block	Anti-XSS em browsers legados
Content-Security-Policy	Whitelist de origens	Anti-XSS e injeção de scripts

---

Rate Limiting

Implementado com Upstash Redis + sliding window:

Endpoint	Limite	Janela
/api/auth/check-credentials	5 tentativas	10 minutos por IP
API geral	100 req	1 minuto por IP
Submissões	Configurável	Por route

Se o Redis estiver indisponível, endpoints de autenticação retornam 503 (fail-closed). Outros endpoints permitem a requisição para evitar degradação de serviço.

---

CSRF

Proteção via double-submit cookie:

• Cookie csrf-token definido em cada resposta (SameSite=Lax, Secure=true)
• Header X-CSRF-Token obrigatório em requisições POST/PUT/PATCH/DELETE
• Verificado no middleware global antes de qualquer handler de rota

---

CORS

• Origens permitidas configuradas via variável de ambiente ALLOWED_ORIGINS
• Requisições de origens não listadas são bloqueadas com 403
• Sempre inclui a própria origem do servidor (same-origin)

---

Logs e PII

• Emails não são logados em produção para evitar exposição de dados pessoais
• Logs de erro identificam usuários apenas por uid= (ID interno)
• Sentry captura erros sem PII em campos sensíveis

---

Política de Senhas

• Mínimo de 8 caracteres
• Armazenamento com bcrypt
• DEFAULT_DEV_PASSWORD bloqueado em produção — usuários sem senha devem redefinir via “esqueci minha senha”

---

Proteção de Dados

• Campos sensíveis (CPF, dados médicos) criptografados na camada do Prisma via prisma-encryption-extension
• Backups exportados com timestamp e controle de acesso por role
• Soft delete: dados nunca apagados permanentemente sem ação explícita de SUPER_ADMIN

---

Checklist de Deploy Seguro

1. Variáveis de ambiente

   Configure NEXTAUTH_SECRET, DATABASE_URL, REDIS_URL, ALLOWED_ORIGINS e ENCRYPTION_KEY com valores fortes.

2. HTTPS obrigatório

   Garanta que o domínio usa TLS. O header HSTS reforça isso após o primeiro acesso.

3. Revise ALLOWED_ORIGINS

   Liste apenas os domínios efetivamente utilizados. Evite *.

4. 2FA para admins

   Ative 2FA para todas as contas com role ADMIN e SUPER_ADMIN.

5. Rotação de segredos

   Rotacione NEXTAUTH_SECRET e ENCRYPTION_KEY periodicamente. Isso invalida todas as sessões ativas.