ByteHeavy
ByteHeavy
ByteHeavy
Segurança e confiança
A maioria das agências diz 'segurança de nível bancário' e para por aí. Preferimos mostrar os detalhes — incluindo as partes que ainda estão em andamento — porque uma promessa vaga vale menos do que uma que pode ser verificada.
Nosso sistema de tickets roda em PostgreSQL com Row-Level Security habilitado e forçado, conectado por meio de uma role de aplicação dedicada que deliberadamente não é superusuária. Isso significa que as regras de controle de acesso vivem dentro do próprio banco de dados, não apenas no código da aplicação. Testamos isso diretamente: uma sessão restrita ao e-mail de um cliente genuinamente não consegue ler os tickets de outro cliente, mesmo na mesma conexão e role de banco de dados. Se um futuro bug no nosso código de aplicação tentasse consultar os dados errados, o banco de dados recusa antes mesmo de a consulta ser executada — o isolamento não depende de nos lembrarmos de escrever a cláusula WHERE correta toda vez.
Toda resposta traz um Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, e uma Permissions-Policy restritiva — as defesas padrão contra clickjacking, ataques de MIME-sniffing e boa parte do XSS. As builds de produção são publicadas sem source maps, então a estrutura exata do nosso código-fonte não é entregue a quem abrir as ferramentas de desenvolvedor.
Todo endpoint de ticket e formulário de contato tem limitação de taxa por IP, e inclui um campo honeypot invisível para usuários reais, mas frequentemente preenchido automaticamente por bots — envios que ativam esse campo recebem uma resposta de sucesso falsa em vez de uma rejeição, para que abusos automatizados nem sequer descubram que foram bloqueados. Toda entrada de formulário é validada no servidor com um esquema rígido antes de sequer tocar no banco de dados, independentemente do que o frontend permitir passar.
Não vamos alegar que um recurso existe antes que ele exista. A autenticação de dois fatores (TOTP com QR code) e um serviço dedicado de autenticação/sessão baseado em Rust estão planejados e projetados, mas ainda não estão em produção — no momento, a busca de tickets é feita por correspondência de e-mail, o que é um mecanismo de conveniência, não um login com nível de senha. Anexos de arquivo em tickets ainda não são suportados intencionalmente, especificamente porque ainda não construímos a camada de verificação de malware que gostaríamos de ter antes deles. Preferimos lançar um recurso atrasado a lançá-lo inseguro.
Se você não consegue verificar uma alegação de segurança, é só marketing. Preferimos que você consiga.