Política de segurança

Como reportar

Não abra um issue público para uma falha de segurança.

Escreva para correio@coreto.org com [segurança] no assunto. É o contacto de quem escreve e corrige o software — uma falha no Coreto é uma falha em todas as regiões ao mesmo tempo. O contacto da agenda por onde chegou, que está no security.txt do domínio dela, fica como alternativa.

Se a falha envolver dados pessoais de alguém, diga-o na primeira linha: muda a ordem pela qual as coisas são tratadas e os prazos que a lei impõe.

Ajuda muito incluir:

• o que se consegue fazer que não se devia conseguir;
• os passos para lá chegar, com o endereço concreto;
• a data e a hora aproximadas em que tentou, para se poderem encontrar os registos;
• se chegou a dados de alguém — e, se sim, que não ficou com cópia.

O que esperar

Em 72 horas

Acusamos a receção e dizemos se conseguimos reproduzir.

Em 30 dias

Falha confirmada corrigida, ou uma data com fundamento para o ser.

Depois

Publicamos o que se passou, e o seu nome se o quiser.

Este é um projeto pequeno, com poucas pessoas e sem programa de recompensas. Os prazos acima são um compromisso honesto, não um contrato comercial.

Âmbito

Interessa-nos, por esta ordem:

• qualquer caminho que leia ou escreva dados de submissões — endereços de email de quem submete, anexos, hashes de IP — sem passar pela moderação;
• qualquer forma de entrar na área de moderação sem a palavra-passe, ou de correr uma ação de moderação sem sessão;
• exposição da chave de serviço da base de dados, ou escrita em tabelas que a política de leitura devia proteger;
• injeção em SQL, em HTML ou nos feeds gerados;
• falhas na caixa incorporável que permitam correr código no sítio de quem a embebeu.

O que não é falha

Fora de âmbito, e escrito para poupar tempo a quem reporta: resultados brutos de varredores automáticos sem impacto demonstrado; a ausência de cabeçalhos que não mudam nada neste contexto; o CORS aberto em /api/events e nos feeds, que é deliberado — os dados são públicos e existem para ser reutilizados; e os contadores por evento poderem ser inflacionados por quem insista, que é um custo conhecido da decisão de não identificar quem visita.

O que já está feito

Para não gastar tempo a confirmar o que já se sabe:

• Não há contas de utilizador. A área de moderação tem uma palavra-passe, guardada em hash scrypt com sal, e um cookie de sessão assinado com HMAC, httpOnly e sameSite=strict. As tentativas de entrada são limitadas por IP.
• A chave de serviço nunca chega ao navegador. O que vai para o cliente é a chave pública de leitura, e o que ela pode ler é o que a política de leitura da base deixa.
• Todas as escritas de moderação passam por funções SQL com auditoria, com a execução revogada a quem lê do lado público.
• Endereços IP nunca são guardados em claro — só um hash com sal, e o registo que serve para limitar tentativas é apagado ao fim de dois dias.
• O webhook de email exige assinatura HMAC; sem segredo configurado, recusa tudo.
• A CSP é restritiva, com frame-ancestors 'none' em todo o lado exceto na caixa incorporável, que existe para ser embebida. Uma exceção, e está aqui escrita por ser exceção: script-src leva 'unsafe-inline', porque a hidratação arranca com scripts inline e a alternativa canónica obrigava a renderização dinâmica em todas as páginas. O risco aceite: um script inline só corre se alguém conseguir injetar HTML.
• Há varrimento de segredos em cada alteração, sem exceções silenciosas. A análise estática do código e dos próprios workflows está configurada e corre quando o repositório for público; enquanto for privado, não corre — e esta página di-lo em vez de o prometer.

Divulgação

Pedimos divulgação coordenada: dê-nos a hipótese de corrigir antes de tornar público. Em troca, mantemo-lo a par e damos-lhe crédito no aviso, se quiser.

Política revista a 19 de setembro de 2026. O endereço de máquina que aponta para aqui é /.well-known/security.txt, em cada um dos domínios do Coreto.

Voltar à ficha técnica do Coreto