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

A plataforma opera com ambientes distintos de desenvolvimento e produção. A segregação completa de bancos de dados e credenciais por ambiente, assim como a implantação de um ambiente de homologação, está em execução conforme o plano de ação de segurança vigente, com conclusão prevista para abril de 2027.

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
• Isolamento por tenant verificado no servidor: toda leitura e escrita é restrita ao tenant_id de quem faz a requisição, com verificação de escopo para qualquer identificador recebido do navegador; há ainda políticas de Row Level Security definidas no banco como camada adicional
• 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
• Injeção de SQL: o acesso ao banco é feito pelo SDK do Supabase, com parâmetros vinculados; nos poucos filtros montados como texto, os identificadores recebidos do navegador são validados quanto ao formato antes de compor a consulta
• 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 no menor prazo possível após a confirmação do incidente, conforme o art. 48 da LGPD e a regulamentação da ANPD aplicável
• 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: