Página institucional

Qualidade, Privacidade e Segurança

Esta página é mantida pela AMD para explicar, de forma transparente, como o Detector de Burla assegura o rigor das análises, protege os dados de quem o usa e defende a plataforma contra abuso. Descreve práticas actualmente em uso — não constitui certificação por entidade independente.

Análises

Qualidade e rigor dos resultados

Análise multi-sinal

Cada submissão gera um risk_score (0–100), um risk_level categórico e um novelty_score, combinando padrões conhecidos com padrões emergentes. Não é uma heurística simples de palavras-chave.

Biblioteca de burlas dupla

Auto-gerada a partir de submissões — só é publicada com ≥5 IPs distintos, ≥3 relatos de risco "elevado/muito elevado", score médio ≥85 e novelty ≥0.65 (thresholds conservadores).

Enriquecida por fontes oficiais confiáveis — alertas da PJ, BdP, CNCS, CERT.PT, DGC, ASAE, CNPD, ANACOM, DECO e Cibercrime do MP entram automaticamente na biblioteca com nível de confiança "high".

Filtro temático

Alertas de fontes oficiais são filtrados por vocabulário — apenas burla, fraude e cibercrime económico entram na plataforma. Crimes violentos, sexuais ou relacionados com drogas são rejeitados.

Revisão humana disponível

Nada é publicado sem passar por thresholds rigorosos ou por revisão de staff. Tudo o que não seja proveniente de fonte confiável passa por fila de moderação.

Retirada automática de indicadores obsoletos

Registos auto-gerados sem actividade há 180 dias passam automaticamente para o estado retired.

Transparência da fonte

Cada padrão publicado indica a sua origem (fonte oficial identificada ou "reportado pela comunidade") e a data em que foi registado.

Modelos de IA multi-provider com fallback

A análise usa vários modelos através do Lovable AI Gateway, com fallback automático entre provedores em caso de indisponibilidade ou degradação. Reduz o risco de dependência de um único fornecedor e mantém a consistência do serviço.

Prompt hardening contra prompt injection

O texto submetido pelo utilizador é isolado e escapado antes de chegar ao modelo, com instruções de sistema resistentes a tentativas de injecção de prompt ("ignora as instruções anteriores…", etc.).

Cache de análises para inputs idênticos

Submissões com o mesmo conteúdo canonicalizado reutilizam a análise anterior. Garante consistência de resultados para o mesmo indicador e evita custos e variabilidade desnecessária.

Whitelist temática e blacklist de vocabulário (RSS)

Ingestão de fontes oficiais via RSS filtrada por whitelist temática (burla, fraude, cibercrime económico) e por blacklist de vocabulário — conteúdos fora do âmbito são descartados automaticamente.

Detecção e normalização de contactos

URLs, telefones e e-mails são extraídos, com normalização E.164 dos telefones e canonicalização de URLs (esquema, domínio, remoção de tracking params). Assegura que variações do mesmo indicador são agregadas correctamente.

RGPD

Protecção de dados

Recolha minimizada

As submissões podem ser feitas anonimamente. Não é necessário criar conta nem fornecer qualquer identificação para usar o Detector de Burla. Consulte a nossa Informação de Protecção de Dados.

IPs nunca armazenados em claro

Guardamos apenas o hash SHA-256 com sal secreto, usado exclusivamente para rate-limiting e detecção de abuso. Este hash não permite re-identificar o utilizador.

Retenção limitada com auto-purga

As submissões têm um expires_at e são automaticamente anonimizadas pela função purge_expired_submissions — texto, URL, telefone e e-mail são apagados. O registo agregado (estatístico) fica; os dados pessoais desaparecem.

Whitelist de entidades oficiais

Números, domínios e e-mails legítimos (bancos, autoridades, serviços públicos) nunca são promovidos à biblioteca de fraude, mesmo se forem reportados repetidamente.

Direito ao esquecimento

Qualquer registo pode ser eliminado por staff através do backoffice, mediante pedido.

Sem tracking invasivo

Apenas analytics próprios (contagens de page views agregadas por sessão anónima). Sem cookies de terceiros, sem pixels de rastreio, sem perfis comerciais. Consulte a nossa Política de Cookies.

Mascaramento de PII antes da análise

Antes de qualquer conteúdo ser enviado ao modelo de IA, um passo dedicado detecta e mascara dados pessoais sensíveis — IBAN, NIF, números de cartão e matrículas — para que nunca sejam processados em claro pelo provedor.

Mascaramento público de URLs e telefones

Nos alertas e listagens públicas, URLs e telefones são apresentados de forma mascarada (funções maskUrlPublic e maskPhonePublic), evitando reutilização directa por terceiros e preservando o carácter informativo.

Banner de cookies com consentimento granular

O banner distingue cookies essenciais (necessárias ao funcionamento) de estatísticas (analytics próprios agregados). O utilizador aceita ou recusa cada categoria de forma independente.

Analytics próprios agregados

Não usamos Google Analytics, Meta Pixel nem qualquer plataforma equivalente. As contagens são calculadas internamente e guardadas de forma agregada.

Sem envio de dados pessoais brutos a terceiros

Nenhuma integração externa recebe dados pessoais em claro. As comunicações com o motor de IA passam pelo pipeline de mascaramento descrito acima.

Plataforma

Segurança

Defesa contra abuso nas submissões

Rate limiting em dupla janela (curto e longo prazo por IP), CAPTCHA (Cloudflare Turnstile) e detecção de bursts — o mesmo IP a submeter repetidamente o mesmo indicador é sinalizado.

Rate limiting adicional no edge

Limite complementar de 60 pedidos por minuto e por IP aplicado directamente na infraestrutura de edge, antes do pedido chegar à aplicação. Reduz o impacto de tráfego automatizado e protege os custos de análise por IA.

Cabeçalhos HTTP de segurança

Em produção, a plataforma envia Strict-Transport-Security (HSTS com preload), X-Content-Type-Options: nosniff,Referrer-Policy: strict-origin-when-cross-origin, uma Permissions-Policy restritiva e X-Frame-Options: DENY (protecção anti-clickjacking).

Row-Level Security (RLS) em todas as tabelas públicas

Cada tabela tem políticas de acesso explícitas — nada é acessível por defeito.

Auditoria completa

Qualquer alteração crítica (papéis, conteúdo público) é registada em admin_audit_log. Alterações "fora de banda" — feitas sem passar pelo backoffice — geram automaticamente um evento crítico em security_events.

HTTPS + domínio próprio

Servido exclusivamente em HTTPS, sob o domínio custom detectordeburla.pt.

Papéis via tabela dedicada

Os papéis de utilizador vivem numa tabela própria user_roles e são verificados pela função has_role declarada como SECURITY DEFINER. Impede escalada de privilégios via manipulação do perfil.

Middleware de autenticação em server functions

Todas as server functions privadas passam pelo middleware requireSupabaseAuth, que valida o token do utilizador antes de qualquer lógica ser executada.

Separação de clientes Supabase

Três clientes distintos: publishable no browser, authenticated no servidor (com token do utilizador, RLS aplicada) e service_role apenas em contexto servidor privilegiado — nunca exposto ao bundle cliente.

Verificação HMAC em endpoints públicos

As rotas em /api/public/* (webhooks, callbacks externos) exigem verificação de assinatura HMAC antes de qualquer processamento.

Turnstile verificado do lado do servidor

O token do Cloudflare Turnstile é sempre validado no servidor contra a API oficial — não apenas obtido no cliente.

Permissions-Policy restritiva

Cabeçalho Permissions-Policy restringe explicitamente acesso a APIs sensíveis do browser (câmara, microfone, geolocalização, pagamentos, etc.) que a aplicação não usa.

Zero segredos no bundle do cliente

O bundle servido ao browser é auditado — só contém chaves VITE_* publicáveis. Nenhuma service key ou segredo de servidor é embebido.

GRANT explícito em todas as tabelas públicas

Cada migration que cria uma tabela pública declara explicitamente os GRANT por papel. Nada depende de privilégios por defeito do PostgreSQL.

Security definer com search_path fixo

Todas as funções SECURITY DEFINER fixam explicitamente o search_path, prevenindo ataques de search_path hijacking.

Transparência

Transparência operacional

Página pública de estado

Publicamos o estado operacional dos principais componentes (site, motor de análise, base de dados) e o histórico de incidentes recentes em detectordeburla.pt/estado. Sempre que houver degradação, é aí que comunicamos.

Página de Qualidade, Privacidade e Segurança

Esta página, mantida e actualizada sempre que há alterações materiais nas práticas descritas.

Dados estruturados (JSON-LD) nas burlas

As páginas de burla incluem structured data — Article e BreadcrumbList — para permitir citação e verificação por motores de busca e agregadores.

sitemap.xml, robots.txt e llms.txt

Publicamos sitemap.xml (indexação), robots.txt (política para crawlers) e llms.txt (política explícita para modelos de linguagem).

Scan de segurança automatizado

Executamos periodicamente o linter de base de dados e o scan de segurança da plataforma — sem findings críticos em aberto.

security-memory.md — documento vivo

Mantemos internamente um documento security-memory.md co-mantido com o scanner, que regista o modelo de acesso, o que nunca deve acontecer e riscos conscientemente aceites.

Nota: O Detector de Burla é uma ferramenta informativa e pedagógica. Não substitui denúncia formal às autoridades competentes (PJ, Ministério Público) nem constitui aconselhamento jurídico, técnico ou regulatório.