A segurança das aplicações que construímos e operamos — controlos escritos em código, verificáveis externamente, sem certificações que não temos.
O trabalho cobre a segurança da aplicação e a engenharia da confidencialidade: cabeçalhos e política de conteúdo, limitação de taxa, posição predefinida «fechado» das verificações, encriptação dos segredos, registos que não podem ser reescritos, anonimização dos dados e prazos de retenção definidos no código, não apenas na política. Não somos auditores certificados e não emitimos certificados.
Já construídoAm ales „livrat” pentru un domeniu deliberat îngust, iar limita o scriem înaintea listei de capabilități. Controalele descrise mai jos rulează în sisteme proprii și o parte se pot verifica din exterior chiar acum: limitarea de rată se demonstrează cu douăsprezece cereri consecutive (a zecea primește 429, verificat pe producție la 06.09.2026), sonda de sănătate întoarce doar valori logice, iar antetele de securitate se citesc din răspuns. A doua și a treia implementare citate sunt platforma de sesizări — politică de conținut cu valoare unică per răspuns, listă albă de destinații de rețea verificată în integrarea continuă, autentificare în doi pași obligatorie pentru personal — și clientul de semnătură electronică scris fără nicio dependență nouă, cu apărare împotriva încadrării semnăturii XML. Ce NU susține dovada: nu avem nicio certificare, nu facem testare ofensivă ca serviciu, nu operăm un centru de monitorizare și nu emitem atestate de conformitate.
A maioria das falhas que encontrámos nos nossos próprios sistemas não eram explorações sofisticadas. Eram valores predefinidos. Uma rota que iniciava uma chamada telefónica para qualquer número, sem autenticação, que nenhuma componente da interface chamava há muito. Uma verificação de origem que passava quando a lista estava vazia. Um endereço IP completo enviado numa mensagem de notificação, enquanto a página pública prometia anonimização. As três estavam escritas no nosso código e nenhuma teria sido vista num scanner automático.
Daqui vem a forma do serviço. Não vendemos um relatório de análise. Lemos o código com uma pergunta precisa: quando esta verificação não consegue decidir, o que faz — permite ou recusa? A posição predefinida é a diferença entre um gate e uma decoração. Nos nossos sistemas, o gate de consumo devolve «não permitido» em caso de exceção, e a rota de chamada telefónica responde 404 se o segredo não estiver configurado — ou seja, a função está desligada se alguém não a tiver iniciado deliberadamente.
A segunda metade do trabalho é a engenharia da confidencialidade, porque na prática as duas não se separam. O prazo de retenção declarado publicamente não significa nada se não for aplicado pelo código. Connosco, o registo de pedidos elimina os ficheiros mais antigos do que o prazo declarado, com o número de dias retirado do mesmo valor que aparece na política publicada. Noutro sistema, a tabela de retenção guarda, ao lado de cada prazo, o texto publicado, palavra por palavra, e a base legal — para que a política e a base de dados não possam divergir uma da outra em silêncio.
O que publicamos sobre nós próprios faz parte do método. A política de conteúdo deste site permite `unsafe-inline` e `unsafe-eval` em scripts. É uma fraqueza real e escrevemo-la aqui, não num relatório interno — foi até o mecanismo pelo qual a nossa própria auditoria de acessibilidade pôde injetar uma ferramenta de verificação diretamente na página de produção. Um fornecedor que não publica as suas próprias fraquezas conhecidas não consegue encontrar as suas.
Qué incluye
El trabajo, por componentes
Lemos a posição predefinida de cada verificação
A questão central da análise: quando a verificação não consegue decidir, permite ou recusa? Exemplo real, do nosso próprio código, assinalado como tal: a lista de origens permitidas de um widget deixa a verificação passar se a lista estiver vazia — escolha deliberada de compatibilidade com instalações antigas, escrita no comentário, mas que significa que a restrição por domínio tem de ser configurada explicitamente em cada implementação. O contraexemplo: o gate de consumo que, perante qualquer exceção, devolve «não permitido».
Limitação de taxa correta por detrás de um proxy
Dez pedidos por minuto por endereço, com uma subtileza que decide se o limite funciona ou não: a chave é retirada do último salto do cabeçalho de encaminhamento, não do primeiro. O nosso proxy acrescenta o endereço real no fim do que o cliente enviou, portanto a primeira entrada é controlada pelo atacante — quem basear a chave nela pode ultrapassar o seu limite enviando valores aleatórios. Pode ser verificado a partir do exterior: doze pedidos consecutivos dão nove respostas bem-sucedidas e depois 429.
Cabeçalhos e política de conteúdo, com valor único por resposta onde se pode
Neste site: transporte estrito por dois anos com subdomínios e inscrição na lista de pré-carregamento, tipo de conteúdo não dedutível, política de referência restrita, política de permissões que fecha a câmara e deixa o microfone e a localização apenas para a própria página. Na plataforma de sesizări, mais estrito: a política de conteúdo recebe um valor único a cada resposta, gerado no proxy, sem fontes terceiras para scripts, ligações ou fontes tipográficas, e o enquadramento é recusado por completo.
Lista branca de destinos de rede, verificada automaticamente
Num projeto público, que endereços a aplicação pode contactar é uma lista verificada por um comando executado em integração contínua, tanto estaticamente como em execução. Um pacote novo que comece a telefonar para casa falha na verificação, não em produção. É o controlo que apanha precisamente a classe de incidentes da cadeia de abastecimento contra a qual ninguém se protege com um scanner de vulnerabilidades.
Os segredos não chegam a respostas, registos ou notificações
A sonda de saúde do formulário de contacto devolve apenas valores lógicos — se está configurado, se a credencial é válida, se o registo pode ser escrito — nunca o token, o identificador da conversa ou o nome do bot. Os tokens de canal da plataforma de mensagens são guardados encriptados. Os registos de alerta passam por um módulo de redação de dados pessoais antes da escrita.
Anonimização aplicada antes da escrita, não depois
O endereço IP é truncado para o prefixo de rede — /24 para IPv4, /48 para IPv6 — antes de entrar no registo ou numa notificação. Com dois detalhes que importam: é tomado o último salto, não o primeiro, pelo mesmo motivo que no limite de taxa; e os endereços IPv4 reportados em forma mapeada IPv6 são reconhecidos e tratados como IPv4, caso contrário seriam mantidos na íntegra, ou seja, exatamente ao contrário do objetivo.
Registo que acrescenta, não reescreve
Os pedidos através do formulário são escritos num registo de adição, um objeto por linha, com permissões 0600 para o ficheiro e 0700 para o diretório, antes de se tentar a entrega. O motivo é uma falha real: quando o canal de notificação falhou, o endpoint devolvia 500 e cada pedido perdia-se sem deixar rasto. Agora, um canal estragado significa «temos de olhar para o ficheiro», não «o pedido nunca existiu». O resultado da entrega é escrito como segunda linha, com o mesmo identificador.
O prazo de retenção aplicado pelo código, não apenas declarado
O registo de pedidos elimina os ficheiros mais antigos do que o prazo declarado publicamente, com o número de dias retirado do mesmo valor. Noutro sistema, a tabela de retenção guarda junto de cada prazo o texto publicado palavra por palavra e o fundamento legal, e a função de limpeza reporta implicitamente o que apagaria; a eliminação real exige um argumento explícito. A eliminação silenciosa é um modo de falha, não uma função.
A identidade e a assinatura, quando o projeto as exige
Temos escritos, do zero e sem novas dependências, um fornecedor de serviços para autenticação federada e um cliente para assinatura eletrónica. O analisador XML não processa definições de tipo de documento, pelo que a classe de ataques por entidades externas não se aplica; a verificação de assinatura devolve o nó coberto pela assinatura, não um valor lógico, e o chamador é obrigado a comparar a identidade do objeto — a defesa contra a envelopagem da assinatura. A canonicalização foi verificada nos vetores oficiais da especificação.
Qué aspecto tiene
El recorrido, paso a paso.
01
Definimos o domínio e o que não podemos tocar
Por escrito, antes de qualquer comando: que sistemas, que período, que tipos de verificação são permitidos e quem é a pessoa de contacto se algo parar. Entregamos: o documento de domínio assinado e a lista dos sistemas excluídos.
02
Lemos o código e a configuração, com foco na posição predefinida
As verificações que não podem decidir, os segredos que chegam a respostas ou registos, as rotas que já ninguém chama mas continuam abertas, os cabeçalhos em falta. Entregamos: as constatações com ficheiro e linha, ordenadas pelo que se pode fazer com elas, e não pela gravidade teórica.
03
Corrigimos ou descrevemos exatamente a correção
Onde temos acesso, colocamos o controlo e escrevemos o teste que o mantém no lugar — uma verificação que não tem teste perde-se na primeira refatorização. Onde não temos acesso, entregamos a alteração descrita com precisão suficiente para que a equipa do cliente a possa aplicar sem nos voltar a perguntar.
04
Ligamos a confidencialidade ao código
O prazo de retenção, a anonimização e a lista de destinatários tornam-se valores no código, com o texto publicado ao lado. Entregamos: o registo de tratamentos preenchido, com a coluna «onde está implementado» completa, e a lista dos pontos ainda por decidir, com quem decide cada um.
05
Verificamos do exterior o que se pode verificar do exterior
Os cabeçalhos, o comportamento no limite, o que devolvem as sondas de saúde. Entregamos: os comandos exatos de verificação, para que qualquer pessoa — incluindo um auditor do cliente — possa repetir a verificação sem nós.
Straturile pe care le atingem, de sus în jos
Os dados
Qué tocamos, dónde están y cuánto se quedan
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
O que abrangemos numa análise
O código, a configuração do servidor, os cabeçalhos das respostas e, quando aplicável, o esquema da base de dados e as políticas de acesso, linha por linha. Não precisamos dos dados reais dos clientes para fazer a análise e preferimos não lhes tocar de todo.
O que não fazemos sem um domínio autorizado por escrito
Nenhuma ação que produza tráfego contra um sistema em funcionamento. As verificações em produção que aparecem nesta página são pedidos normais de leitura, em sistemas próprios. Qualquer ultrapassagem deste limite exige uma autorização por escrito, com período e endereços, assinada por quem tem direito de a dar.
Onde vão as constatações
Num documento com uma constatação por linha: onde está, o que se pode fazer com ela, o que a corrige e como se verifica a correção. As constatações que descrevem um caminho de exploração não circulam por canais não seguros e não chegam a materiais públicos antes da reparação.
Registo de tratamentos
Na parte da confidencialidade, o resultado é um registo com uma linha por atividade: finalidade, base legal, categorias de dados, destinatários, transferências, local de armazenamento, prazo, medidas e o ficheiro no código onde está implementado. O que não pôde ser verificado escreve-se “não verificado”, não se completa a partir de um modelo.
A regra que mantém a política ligada ao código
Se uma alteração de código mudar o que é recolhido, a quem chega ou quanto tempo é mantido, a política publicada é alterada no mesmo passo de entrega. A divergência entre a política publicada e o código foi precisamente o problema que nos levou a escrever o nosso registo próprio.
Un caso
Uma rota esquecida que podia ligar para qualquer pessoa
A situação
Numa revisão do nosso próprio site, encontrámos uma rota de interface de programação que iniciava uma chamada telefónica para qualquer número enviado no corpo do pedido. Sem autenticação, a custo e a partir do número da empresa. Nenhum componente da interface já a chamava — o único chamador era um elemento que já não era mostrado. Ou seja, tinha funcionado aberta à internet sem que ninguém tivesse motivo para olhar para ela.
Qué construimos
Tratámo-la como dois problemas, não um. Tecnicamente: a rota pede agora um segredo partilhado num cabeçalho, e se o segredo não estiver configurado responde 404 — a capacidade fica desligada se alguém não a ligar deliberadamente, não ligada até alguém a desligar. Juridicamente e eticamente: uma chamada automática não solicitada é um tratamento de dados que a pessoa chamada não pediu, por isso escrevemos no registo o que seria necessário para uma eventual reativação — base documentada em relação ao chamado, registo do consentimento e um canal de oposição.
Qué salió
A capacidade está fechada por defeito e permanece fechada até alguém tomar uma decisão explícita. A linha do registo de tratamentos descreve o estado, o que existia antes, o risco e as condições de reativação — assim, a próxima pessoa que encontre a rota não precisa de reconstruir o raciocínio.
Qué no dice el caso
Não percebemos isso por um instrumento. Encontrámo-lo lendo as rotas uma a uma e perguntando, para cada uma, quem a chama. Um scanner automático teria visto uma rota que devolve 400 a um pedido vazio e teria passado à frente. Essa também é a limitação do método: cobre o que lemos, e o que não lemos fica por cobrir — por isso o âmbito é definido por escrito.
Perguntas
Lo que nos pregunta la gente antes de llamar
Têm certificações de segurança?
Não. Nem ISO 27001, nem SOC 2, nem uma certificação de teste ofensivo, nem acreditação de auditor. Não emitimos certificados e não assinamos atestados de conformidade. O que podemos mostrar é a prática própria, com ficheiro e linha, e os controlos que colocámos em sistemas em funcionamento. Se precisa de um certificado para um dossier, precisa de um organismo acreditado, não de nós — e é melhor saber isso agora.
Fazem testes de penetração?
Não como serviço. Não temos equipa de teste ofensivo, licença ou metodologia certificada, e não fingimos que temos. O que fazemos é análise do código e da configuração, mais verificações não invasivas do exterior — cabeçalhos, comportamento no limite da taxa, o que as respostas de erro revelam. Se o projeto exigir um teste ofensivo verdadeiro, vai precisar de uma empresa especializada; podemos trabalhar ao lado dela na parte da correção.
O que encontraram nos vossos próprios sistemas?
Três coisas, num único dia de análise, todas escritas publicamente no nosso registo. Uma rota que iniciava uma chamada telefónica para qualquer número no corpo do pedido, anónima, sem autenticação, que nenhum componente da interface já chamava — agora responde 404 se o segredo não estiver configurado, ou seja, fica desativada se alguém não a ligar deliberadamente. Um widget de conversa que carregava em cada visualização e escrevia a sessão na memória do navegador antes de o visitante pedir algo — agora carrega ao premir o botão. E o endereço IP completo enviado numa notificação, enquanto a página pública prometia anonimização — agora é truncado antes da escrita.
A vossa política de conteúdo permite `unsafe-eval`. Porque deveria acreditar em vocês?
Porque fomos nós que vos dissemos, não foi vocês que descobriram. Sim, a política deste site permite `unsafe-inline` e `unsafe-eval` em scripts — é uma fragilidade real, herdada da forma como certos scripts de terceiros são carregados, e é precisamente o mecanismo pelo qual o nosso próprio auditor de acessibilidade injetou uma ferramenta de verificação na página de produção. Num projeto onde a restrição é definida por nós desde o início, a forma correta é a da plataforma de reclamações: valor único por resposta gerado no proxy e nenhuma fonte de terceiros para scripts. A diferença entre as duas é exatamente a discussão que devíamos ter no início de um projeto, não no fim.
Como verifico, sem ter de acreditar na sua palavra, que a limitação de taxa funciona?
Enviando doze pedidos consecutivos para uma rota de interface de programação deste site e contando as respostas: as primeiras nove passam, a décima recebe 429 com o cabeçalho que indica quando pode ser tentado novamente. A janela é de um minuto. O comando está na lista de fontes desta página e pode executá-lo agora. Aplicamos o mesmo princípio ao que entregamos: se um controlo não puder ser verificado do exterior pelo cliente, não é entregue, é declarado.
O que acontece com os dados pessoais de um formulário?
São escritos num registo com adição, um objeto por linha, com direitos restritos sobre o ficheiro e a diretoria, antes de se tentar a entrega — para que um canal de notificações avariado não faça o pedido desaparecer. O endereço IP é truncado para o prefixo de rede antes da escrita. Os ficheiros mais antigos do que o prazo declarado são eliminados, com o número de dias retirado do mesmo valor que aparece na política publicada. E a linha do registo de processamento diz, para cada elemento, em que ficheiro do código está implementado.
Podem fazer autenticação com identidade eletrónica de Estado ou assinatura eletrónica?
O código existe e foi testado, mas não está ativado em lado nenhum em produção, e a diferença conta. Temos escrito um fornecedor de serviços para autenticação federada e um cliente de assinatura, ambos sem novas dependências, com as defesas específicas implementadas e com testes. O que falta não diz respeito ao código: contrato com a autoridade, certificado de sistema e registo do endereço de produção. Até lá, a variante que funciona hoje é aquela em que o cidadão assina no portal oficial e carrega o documento assinado de volta.
Que controlos normalmente colocam numa nova aplicação?
Cabeçalhos e política de conteúdo com valor único por resposta; limitação de taxa com a chave retirada corretamente de trás do proxy; separação por organização aplicada na base de dados, não apenas na aplicação; segredos encriptados e nunca em respostas ou registos; chaves de idempotência nos eventos de terceiros; autenticação em dois passos obrigatória para contas de pessoal; registo de auditoria com visibilidade separada para interno e público; e, para projetos públicos, uma lista branca de destinos de rede verificada automaticamente em cada entrega.
O que é que este serviço não cobre?
A segurança da rede corporativa, os equipamentos dos utilizadores, monitorização contínua do tipo centro de operações, resposta a incidentes 24/7, investigação forense e formação contra phishing. Não são coisas que fazemos mal — são coisas que não fazemos. O nosso domínio é a aplicação que construímos ou assumimos, mais os dados que passam por ela.
Antete pe producție: transport strict 63072000 s cu subdomenii și precarcare, tip de conținut nedeductibil, politică de referință restrânsă, politică de permisiuni care închide camera; încadrarea în cadru e refuzată complet pe rutele de interfață de programare și limitată la aceeași origine pe paginihttps://www.megapromoting.com/api/health/contact · 2026-09-06
22 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.