A equipa SifG22 mostrou-me uma falha no acesso às contas da Luxine

// relatório de divulgação responsável · 11-10-2026
[1]  falha na recuperação de palavra-passe (F12) → conta tomada
[2]  service key do Supabase via consola (F12)
[3]  chave secreta ... luxine
// fim do método
------------------------------------------------
[fix] login / contas / comentários ... DESATIVADOS
[fix] novas API keys secret ......... A REGENERAR
[fix] reforço RLS em SQL ............ EM CURSO
▍

A segurança digital é um daqueles aspetos do desenvolvimento que podem passar despercebidos até alguém demonstrar que existe um problema. Esta semana vivi-o de perto e quero contá-lo com total transparência.

Primeiro e mais importante, uma mensagem para quem tem uma conta na Luxine: lamentamos a preocupação que isto possa ter causado, mas por sorte não aconteceu nada grave. Quem o fez foi uma equipa amiga, a equipa SifG22, com uma intenção puramente preventiva, e não se divulgou nem se utilizou qualquer dado pessoal. Como medida de precaução, enquanto o resolvemos desativámos por completo o início de sessão, as contas e os comentários. Voltarão a estar disponíveis assim que terminarmos de reforçar a segurança.

O que aconteceu

A equipa SifG22, com quem tenho amizade, interveio na Luxine para me demonstrar que existia um risco que eu devia corrigir antes de poder dar origem a um problema maior. Não foi um ataque com má intenção: foi um aviso.

O método foi simples e, por isso mesmo, revelador. A partir da consola do navegador (a que se abre com F12) e com comandos, sondaram como o site se comportava por dentro. A partir daí conseguiram alterar a palavra-passe de uma conta usando o próprio painel de login. Nada mais: não foi preciso qualquer truque elaborado nem acesso a servidores externos, bastou o que qualquer pessoa tem no seu navegador.

Porque foi possível

A consola do navegador (F12) é uma ferramenta normal de desenvolvimento: qualquer visitante a tem. O problema não é que exista, mas sim confiar que o navegador se porte bem. Se uma operação sensível —como alterar uma palavra-passe— é decidida do lado do cliente, alguém pode manipular essas chamadas a partir da consola e contornar as verificações.

A lição é clara: as operações críticas têm de ser verificadas no servidor, nunca apenas na interface. Não basta ocultar botões ou validar no navegador; o backend deve verificar, em cada pedido, que quem o faz está autorizado a fazê-lo. Essa é a principal lição de toda esta experiência.

O que desativei enquanto o resolvo

Não quis disfarçar o sucedido nem deixá-lo correr. Preferi cortar pela raiz a superfície afetada e avisar o público. Neste momento:

• Início de sessão e contas: desativados. As páginas de login e de conta estão temporariamente fora de serviço.
• Comentários e moderação: desativados, porque a escrita de comentários dependia do sistema de contas.
• Ligação ao Supabase: desligada tanto no frontend como no backend, para que não se possa ler nem escrever nada enquanto durar a revisão.
• Rotas de administração: retiradas do serviço público.

Houve fuga de informação?

Esta pergunta tem de ser tratada com cuidado. O que se demonstrou foi que se podia alterar a palavra-passe de uma conta a partir do cliente, mas isso não permite por si só concluir que foram extraídos dados nem que se publicou informação. A equipa SifG22 tem amizade comigo e guardou as suas capturas como prova, sem divulgar nada.

Não quero apresentar como confirmada uma fuga que não foi comprovada. Por isso o passo seguinte é rever os registos e estabelecer o que pode ter ocorrido, antes de afirmar seja o que for.

O que estou a reforçar

A experiência deixa uma lista clara de trabalho, já em curso:

• Verificação no servidor: que a alteração de palavra-passe e qualquer operação sensível sejam verificadas no backend, não no navegador.
• Fluxo de acesso: refazer o login e a recuperação de palavra-passe para que não possam ser manipulados a partir do cliente.
• Sessões: rever os registos de autenticação e encerrar qualquer sessão que possa estar comprometida.
• Chaves e dados: rodar os segredos que convenham, evitar expô-los no frontend e rever as políticas de acesso no Supabase.

O que levo desta experiência

Às vezes, ter alguém de confiança a apontar uma falha é a melhor forma de descobrir que os teus sistemas precisam de mais atenção do que pensavas. Prefiro tê-lo sabido assim, de forma preventiva, do que tê-lo descoberto através de um incidente real.

A segurança de uma aplicação não se demonstra afirmando que está protegida, mas verificando que os seus controlos funcionam quando realmente importa —e do lado certo, o do servidor. Obrigado pela compreensão enquanto deixamos tudo em ordem.