Dossier Técnico de Segurança da Plataforma Mova

A Mova está implementada como uma aplicação Next.js onde o acesso privilegiado aos dados fica concentrado em rotas de API no servidor. O navegador pode autenticar-se com uma sessão do utilizador, mas não deve receber credenciais de serviço da base de dados nem executar operações privilegiadas do Supabase diretamente.

O modelo de segurança combina várias camadas: validação de bearer token, proteção de mesma origem em pedidos mutativos, limitação de pedidos, comportamento estrito de cache, row-level security na base de dados e cifragem na camada da aplicação para campos financeiros do utilizador.

Um pedido protegido normal flui do browser para a API da aplicação, passa pelos controlos de segurança do pedido e só depois atinge o acesso ao Supabase no servidor. A fronteira de confiança é, portanto, o runtime do servidor e não o bundle do cliente. As rotas públicas ficam limitadas a um pequeno conjunto de endpoints de mercado ou health.

Como a service role key permanece apenas no servidor, um bundle frontend copiado ou um URL da base de dados não fornecem o material necessário para leituras privilegiadas. Isto reduz de forma material o blast radius de fugas típicas do lado do cliente.

Nas tabelas financeiras protegidas, os campos seguros são serializados para encrypted_data antes da persistência. O runtime deriva uma chave AES-GCM por utilizador a partir do segredo de serviço, do identificador do utilizador e de um salt único do perfil. A descifragem acontece apenas dentro de pedidos autorizados no servidor.

Este desenho significa que um dump direto das tabelas ainda expõe metadados estruturais como identificadores de linha e timestamps, mas os campos de negócio protegidos permanecem opacos sem o segredo do servidor e sem o caminho de derivação da chave.

O dispatcher da API interna rejeita segmentos inválidos, bloqueia prefixes reservados, aplica verificação de mesma origem em métodos mutativos, impõe um limite de um megabyte para o corpo genérico da API e responde com cabeçalhos no-store para o tráfego de API.

O rate limiting é atualmente implementado em memória do processo, com janela de 60 segundos e chaves por rota derivadas do IP do cliente, do estado de autenticação e do prefixo da rota. É eficaz para uma única instância de runtime e deve ser entendido como controlo prático da aplicação, não como controlo distribuído de edge.

Os uploads de faturas são tratados por rotas dedicadas no servidor em vez de escritas diretas do cliente para o bucket. A rota valida mesma origem, exige utilizador autenticado, restringe MIME types a uma pequena allowlist e limita o upload a dez megabytes.

Os ficheiros ficam guardados em caminhos por utilizador e são depois expostos por URLs assinadas. Isto reduz o risco de enumeração de bucket e evita expor caminhos de objetos como recursos publicamente recuperáveis.

As rotas administrativas são protegidas por autenticação e por verificação de papel admin. Alterações de acesso do utilizador, ações sobre feedback e outros eventos privilegiados são inseridos em admin_audit_logs, garantindo trilha de revisão para operações sensíveis.

A plataforma também inclui fluxos de reencriptação para dados do utilizador. Isto tem valor operacional em migrações, reparação de dados ou manutenção criptográfica porque oferece um procedimento definido em vez de manipulação direta e pontual da base de dados.

Um atacante com acesso apenas ao browser, um bundle do cliente vazado ou um operador da base de dados sem os segredos do servidor não devem conseguir ler em plaintext os campos financeiros protegidos. Esse é o valor prático do desenho com segredo apenas no servidor e blobs cifrados por utilizador.

Um operador privilegiado de produção com acesso ao runtime e ao segredo de serviço continua dentro da fronteira de confiança e pode executar a lógica autorizada de descifragem. Por isso, o desenho não afirma zero-knowledge. Uma revisão de segurança deve tratar isto como modelo de servidor confidencial endurecido e não como criptografia end-to-end com chave do cliente.

As tabelas de comparação deste dossier não afirmam paridade de escopo com plataformas bancárias reguladas. Elas servem para mostrar que a Mova segue famílias de controlo reconhecíveis e descritas publicamente por fintechs estabelecidas: transporte cifrado, sessões protegidas, acesso interno restrito e práticas explícitas de monitorização ou fraude.

As colunas dos fornecedores abaixo baseiam-se em documentação oficial pública disponível em 7 de março de 2026. São ilustrativas e não substituem uma auditoria independente aos fornecedores citados.

Se o produto exigir uma postura de privacidade ainda mais forte contra operadores privilegiados do servidor, o passo seguinte de arquitetura será a adoção de chaves mantidas pelo cliente ou de um desenho zero-knowledge. Isso altera de forma relevante pesquisa, recuperação e workflows administrativos e deve ser tratado como tradeoff de produto, não como um pequeno ajuste.

Se o produto exigir maior resistência a abuso em escala, devem ser adicionados rate limiting distribuído, controlos de anomalia suportados por WAF, workflows dedicados de rotação de segredos e testes externos formais de penetração sobre a base atual.