Segurança

1. Princípios de Segurança

A segurança do Caixa Exato é construída sobre dois princípios fundamentais que orientam todas as decisões de arquitetura e desenvolvimento:

2. Segurança desde a Concepção (Security by Design)

As decisões de segurança abaixo foram tomadas na fase de modelagem do sistema, antes do desenvolvimento, e fazem parte da arquitetura fundamental da plataforma:

Isolamento multi-tenant por arquitetura

Cada empresa (tenant) possui um identificador único (tenant_id) vinculado a todos os seus dados no banco. O isolamento é garantido em nível de banco de dados via Row Level Security — não apenas na camada de aplicação — impedindo que dados de um cliente sejam acessados por outro, mesmo em caso de falha na lógica da aplicação.

Lógica de negócio exclusivamente server-side

Toda regra de negócio, validação e acesso ao banco de dados é executada em Server Actions do Next.js — código que roda exclusivamente no servidor. Nenhuma credencial, regra de autorização ou dado sensível é exposto ao navegador do usuário.

Controle de acesso baseado em perfis (RBAC)

O sistema define perfis com permissões distintas desde a modelagem: ADMIN (equipe interna), DONO (titular da conta), FINANCEIRO e VENDEDOR (sub-usuários com acesso limitado). Cada rota e ação verifica o perfil antes de qualquer operação.

Limites de usuários por plano na camada de servidor

As restrições de quantidade de usuários por plano contratado são verificadas e aplicadas no servidor — não no frontend — impedindo que a regra seja contornada por manipulação de interface.

Separação de ambientes

Os ambientes de desenvolvimento, homologação e produção são completamente isolados, com credenciais, bancos de dados e configurações independentes. Não há compartilhamento de dados entre ambientes.

3. Segurança por Padrão (Security by Default)

Os controles abaixo estão ativos por padrão em toda a plataforma — nenhuma configuração adicional é necessária para ativá-los:

• Autenticação obrigatória em todas as rotas protegidas: qualquer tentativa de acesso sem sessão válida é redirecionada para a tela de login automaticamente
• Row Level Security (RLS) ativo em todas as tabelas: mesmo que a aplicação não filtre por user_id, o banco recusa o acesso a dados de outros tenants
• Credenciais exclusivamente por variáveis de ambiente: nenhuma senha, chave de API ou token é armazenado no código-fonte
• Content Security Policy (CSP) configurado: o navegador é instruído a bloquear scripts, estilos e conexões de origens não autorizadas
• HTTPS obrigatório: toda comunicação ocorre sobre TLS — conexões HTTP são redirecionadas automaticamente
• Hashing de dados sensíveis: dados pessoais enviados a terceiros (ex.: integrações de marketing) são anonimizados com SHA-256 antes do envio
• Senhas armazenadas com hash seguro: nunca armazenadas em texto puro — gerenciadas pelo Supabase Auth com bcrypt
• Tokens de sessão com expiração automática: sessões inativas são encerradas automaticamente pelo Supabase Auth

4. Controles Técnicos Implementados

5. Controle de Acesso e Identidade

O acesso à plataforma é controlado por uma hierarquia de perfis com permissões distintas:

A quantidade de sub-usuários é limitada pelo plano contratado e verificada no servidor a cada criação. Nenhum usuário pode elevar seus próprios privilégios.

6. Proteção de Dados em Trânsito e Repouso

• Em trânsito: toda comunicação entre o navegador, o servidor de aplicação (Vercel) e o banco de dados (Supabase) utiliza TLS 1.2 ou superior. Conexões sem criptografia são bloqueadas.
• Em repouso: os dados armazenados no banco PostgreSQL são criptografados com AES-256 pelo Supabase (infraestrutura AWS). Backups diários seguem o mesmo padrão de criptografia.
• Senhas: armazenadas exclusivamente como hash bcrypt — impossível recuperar o valor original.
• Dados de integração: informações pessoais enviadas a plataformas externas (ex.: ferramentas de marketing) são anonimizadas com SHA-256 antes do envio, conforme boas práticas da indústria e requisitos de privacidade.

7. Gestão de Vulnerabilidades

O Caixa Exato adota as seguintes práticas para prevenção e gestão de vulnerabilidades:

• Dependências atualizadas: bibliotecas e frameworks são mantidos atualizados para incorporar correções de segurança
• Proteção contra OWASP Top 10: as principais categorias de vulnerabilidade (injeção SQL, XSS, CSRF, exposição de dados sensíveis, controle de acesso quebrado) são mitigadas por padrão de arquitetura
• SQL Injection: o uso do ORM do Supabase com queries parametrizadas elimina a possibilidade de injeção SQL em todas as operações
• XSS: o React e o Next.js fazem escape automático de saídas no HTML — conteúdo inserido por usuários não é executado como código
• CSRF: Server Actions do Next.js possuem proteção CSRF nativa via verificação de origem

8. Resposta a Incidentes

Em caso de incidente de segurança que possa comprometer dados pessoais ou financeiros dos usuários:

• O incidente será investigado e contido imediatamente pela equipe técnica
• Os usuários afetados serão notificados em até 72 horas após a confirmação do incidente, conforme exigido pela LGPD (art. 48)
• A notificação incluirá: natureza dos dados afetados, medidas adotadas e orientações ao usuário
• A Autoridade Nacional de Proteção de Dados (ANPD) será comunicada nos casos previstos em lei

9. Contato de Segurança

Para reportar vulnerabilidades, incidentes de segurança ou dúvidas sobre as práticas descritas neste documento: