Guias de Segurança
Senhas, MFA, dispositivos, Wi-Fi público, servidores, dependências, Git, ambientes expostos — guias práticos e orientados a objetivos sobre defesas que você pode aplicar hoje.
Como armazenar senhas com segurança — a forma certa de fazer hash e salt
Um guia prático para armazenar senhas com segurança no servidor. Entenda por que texto puro, criptografia e hashes crus falham e então convirja para uma resposta: um salt por usuário mais um hash deliberadamente lento (Argon2id recomendado, bcrypt/scrypt como alternativas). Não invente o seu — use a função padrão, eleve o custo com o tempo e migre hashes fracos refazendo o hash no login.
Segurança para a era da IA: os fundamentos para blindar agora (checklist por prioridade)
A IA em sua maior parte amplifica ataques sobre fraquezas EXISTENTES (CVEs sem correção, senhas reutilizadas, segredos expostos) em vez de inventar novas — encontradas de forma automática, rápida e em escala. Então a melhor preparação é blindar os fundamentos na ordem certa: correção de CVE + monitoramento de dependências, acabar com reutilização + MFA, remover segredos expostos, menor privilégio, reduzir a superfície pública, logs/IOCs, backups.
O que funciona (e o que não funciona) na segurança da era da IA — por que sites pequenos também são atingidos
Quatro mitos da era da IA corrigidos: (1) pequeno demais para ser alvo → a automação remove 'um humano te escolhe'; (2) precisa de um novo controle especial → o básico ainda vence; (3) um produto te deixa seguro → design de prevenção antes da detecção; (4) código de IA é rápido então é seguro → ele vem com vulnerabilidades, revise antes de publicar. O que funciona é o básico tedioso na ordem certa.
Um e-mail de phishing falsificou seu próprio domínio? Spoofing vs invasão, e como impedir
Um e-mail suspeito que parece vir do seu próprio domínio geralmente não é uma invasão — é um From falsificado, porque o SMTP deixa qualquer um escrever a linha From. Ler os headers (Authentication-Results, Received, Reply-To) distingue invasão de falsificação. A principal razão de ele chegar à caixa de entrada é uma política DMARC ausente. Corrija com SPF → DKIM → DMARC (p=none → reject).
Fundamentos de backup: a regra 3-2-1 e um plano de recuperação que sobrevive a ransomware
'Tenho um backup' não basta — só um backup que você verificou ser restaurável é real. O básico: a regra 3-2-1 (três cópias, dois tipos de mídia, uma fora do local). Para ransomware você também precisa de ao menos uma cópia 'offline ou imutável' — um backup sempre conectado é criptografado junto com o original. Sincronização na nuvem não é backup (ela replica exclusões e criptografia também). Versionamento e um teste de restauração periódico completam a prática.
Detenha segredos antes do commit com o gitleaks: pegue vazamentos de chave de API antes do push
Segredos não podem ser 'apagados depois que vazam'. Uma vez comitado, um segredo fica no histórico do Git, e uma vez enviado deve ser tratado como vazado — a chave precisa ser revogada/rotacionada. O gitleaks é uma ferramenta gratuita que varre todo o repo e o histórico de commits com regex/entropia para encontrar chaves de API, chaves privadas e tokens. O cerne da defesa são dois portões: um hook de pre-commit que o detém localmente antes do push e CI/cron que pega o que escapa. O .gitignore só evita novo rastreamento — ele não detecta, então você ainda precisa de um scanner.
Escolhendo MFA do jeito certo: o que significa 'resistente a phishing' e por que o SMS é fraco
MFA é uma segunda fechadura para que uma senha vazada sozinha não consiga entrar — mas o que você ativa muda sua força em três níveis. Códigos por SMS/e-mail caem diante de phishing por relay e SIM-swap; apps autenticadores (TOTP) ficam no meio; passkeys/chaves de segurança (FIDO2) não podem ser apresentados a um site falso de jeito nenhum — essa é a resistência a phishing. Prioridade máxima: coloque MFA resistente a phishing nas chaves do reino (e-mail, domínio, pagamentos). Guardar os códigos de recuperação e ter um fator de backup completam a configuração.
Ainda no Windows 10? Os riscos de segurança de usá-lo após o fim do suporte
O Windows 10 chegou ao fim do suporte em 14 de outubro de 2025. O risco central de continuar é que buracos recém-descobertos nunca são corrigidos (forever-days) e se acumulam, tornando a máquina um alvo preferido. O ESU para consumidores é um paliativo de um ano, só de segurança, até 13 de outubro de 2026 (existem rotas de inscrição gratuitas, mas o primeiro ano grátis da EEA não se aplica à maioria das regiões). A correção real é migrar para o Windows 11 ou trocar o hardware — use o ESU só como ponte até concluir essa migração.
BitLocker vs 'Criptografia de dispositivo' — a mesma tecnologia, versão completa vs versão automática leve
BitLocker e Criptografia de dispositivo compartilham o mesmo mecanismo de criptografia. Criptografia de dispositivo = a versão automática e leve que funciona no Home (liga sozinha com uma conta Microsoft, chave de recuperação custodiada automaticamente, opções mínimas). BitLocker = a versão completa no Pro+ (PIN de inicialização, criptografia de disco externo via To Go, controle fino). Para indivíduos, estar criptografado automaticamente mais saber onde está a chave de recuperação costuma bastar. O estado importa mais que o nome.
Corrigindo CVEs de dependências de verdade: varrer, corrigir, isolar e seguir vigiando
O trabalho de vulnerabilidade não termina quando você 'corrige'. Pronto = 1) varrer, 2) corrigir, 3) isolar/repassar, 4) monitorar. Até o monitoramento (detecção de mudança diária) estar no lugar, está incompleto — dependências voltam a ser vulneráveis amanhã. Uma correção perfeita que o próximo deploy sobrescreve vale zero. Equipes pequenas se mantêm seguras com duas disciplinas: detecção de mudança automatizada e 'local→push→deploy'.
Protegendo um laptop que você carrega — defesa contra roubo, perda e bisbilhotagem por cima do ombro
Carregar um laptop pressupõe que você vai perdê-lo ou ele vai ser roubado. A defesa de verdade é desenhada para que uma perda não vaze o conteúdo: criptografia de disco (BitLocker/FileVault), um login forte com um bloqueio automático curto e limpeza/localização remota. Com HTTPS em todo lugar, a interceptação em Wi-Fi público é de prioridade menor; as ameaças reais são pontos de acesso falsos, bisbilhotagem por cima do ombro e se afastar. Não confie demais numa VPN — endureça o dispositivo primeiro.
Instalando e usando o osv-scanner: encontre CVEs nas suas dependências
O osv-scanner escaneia lockfiles e containers para revelar CVEs nas suas dependências, de graça. Este guia percorre a instalação, a execução e a integração ao CI, além de quando usá-lo vs. npm/pnpm audit vs. Dependabot. A visão deste site: a ferramenta certa é decidida pela SUA configuração — use o osv-scanner em projetos multi-ecossistema ou sem GitHub, e o pnpm audit embutido para uma única árvore npm.
Gerenciadores de senhas são seguros? Como funcionam, nuvem vs. local e como escolher
Um gerenciador de senhas é mais seguro que reutilizar ou guardar em texto puro. A chave é a criptografia de conhecimento zero: sua senha-mestra descriptografa o cofre só no seu dispositivo, o provedor guarda apenas o texto cifrado, então uma invasão do provedor não expõe suas senhas. O ponto único real é sua senha-mestra mais o MFA do cofre. Escolha nuvem (Bitwarden/1Password) ou local (KeePass) pelo uso.
Os perigos do Wi-Fi público — o risco real não é 'sniffing', são os gêmeos malignos e os avisos de certificado ignorados
O 'sniffing' em Wi-Fi público é em grande parte mitigado pelo HTTPS e hoje é de baixa prioridade. Os riscos reais são (1) você mesmo se conectar a um ponto de acesso falso gêmeo maligno, (2) ignorar avisos de certificado e (3) expor seu dispositivo na rede compartilhada. A melhor correção é surpreendentemente simples — use o tethering do celular, confie no HTTPS e nos avisos de certificado, e não entre automaticamente em SSIDs desconhecidos. Uma VPN é a camada seguinte.
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Qualquer coisa no seu webroot pode ser baixada pela URL por qualquer um. Um JSON de token/credenciais esquecido, um .env ou um backup significam exposição instantânea — e se veio de um template compartilhado, todo site tem o mesmo buraco. Correção: coloque no diretório público só o que pode ser compartilhado, mantenha segredos fora do webroot com permissão 600 e, ao achar um, audite todos os sites e hosts.
A base de segurança para devs independentes e pequenos operadores: o conjunto-padrão completo
A base não é 'tudo igualmente importante'. A ordem de prioridade deste site: 1) chaves do reino (MFA, domínio, e-mail), 2) segredos e código, 3) o próprio app, 4) corrigir, detectar, recuperar. Com tempo finito, preencha de cima para baixo. A maioria das invasões sérias vem não de ataques inéditos, mas de uma falha nesta base.
A base de segurança para organizações de médio a grande porte: a fundação padrão para times
Em escala, a base muda de um 'checklist' para 'programas com responsáveis'. A ordem de prioridade espelha a versão independente: 1) identidade, 2) segredos e cadeia de suprimentos, 3) app e infra, 4) detectar e responder, mais uma camada transversal de pessoas e governança. A grande mudança: a principal causa de invasões passa de deslizes para pessoas, processo, acesso de ex-funcionários e terceiros.
Inventário de segurança — 7 verificações que quem roda vários servidores ignora
Para operadores solo/pequenos, incidentes vêm menos de controles ausentes do que de estado não rastreado. A fronteira é o PC que guarda suas chaves. Escalone o 2FA pela raiz de confiança, faça a matriz das chaves SSH para eliminar duplicatas/sem uso/órfãs, remova senhas em texto puro da nuvem, remedie de forma reversível uma de cada vez e mantenha segredos fora do registro. Inventarie antes de adicionar ferramentas.
Git auto-hospedado vs. GitHub: qual é de fato mais seguro?
Auto-hospedar o Git não te torna 'mais seguro' — realoca o risco. A classe de exposição pública acidental desaparece, mas aplicar patches no servidor, backups e detecção de segredos pré-commit passam para você. A escolha certa se você paga o preço; pior que o GitHub se você o negligencia. A visão deste site: a auto-hospedagem só funciona junto com seus controles compensatórios.
Fundamentos de segurança no smartphone — protegendo o dispositivo que reúne suas chaves, seu cofre e seu ID em um só
Um celular concentra 2FA, e-mail, banco e ID em um único ponto de falha. A defesa real não é um app de segurança: (1) um bloqueio forte + bloqueio automático curto (o código é a chave de criptografia); (2) atualizações automáticas de SO/apps; (3) loja oficial + revisão de permissões; (4) configure bloqueio/apagamento remoto com antecedência; (5) mantenha um backup do seu 2FA. iOS/Android já criptografam e isolam por padrão.
Não dê chaves de root a ambientes que podem ser comprometidos: menor privilégio para chaves SSH
Cadastrar uma chave de root em produção a partir de um ambiente efêmero e comprometível (pod de GPU, runner de CI, VM descartável) significa que, no momento em que o ambiente é comprometido, produção é tomada com root. Correção: sem chaves de root em ambientes efêmeros; remova chaves quando não usadas; se precisar de novo, use um usuário sem root mais uma chave restrita a comando que limita a chave a uma operação. Uma chave reutilizada é seu ativo mais crítico — nunca construa um cenário de 'um vazamento, tudo'.
Guardar suas senhas no Google Drive é seguro? Como mantê-las do jeito certo
Guardar senhas em um Documento/Planilha Google em texto puro é perigoso: uma conta Google vira o ponto único de falha para toda senha — sequestro de conta, um app conectado malicioso ou phishing vazam todas de uma vez. A correção é um gerenciador de senhas dedicado (o conteúdo fica criptografado mesmo quando sincronizado). Se você precisar usar o Drive, guarde só um arquivo de cofre criptografado e coloque MFA resistente a phishing na conta.
Por que uma conta da OpenAI é banida: chaves de API roubadas e a política de distilação
Quando uma chave de API roubada é abusada para 'distilação', até a conta da vítima pode ser suspensa automaticamente. Um guia defensivo e anonimizado sobre o mecanismo, a prevenção e os recursos.
O que é a falsificação de X-Forwarded-For (XFF) — a armadilha da configuração de proxy confiável
XFF é um cabeçalho forjável pelo cliente. Um scanner cego esconde sondagens de injeção em um XFF falsificado; 'confiar em todos os proxies (curinga)' o deixa passar. Patch = higienizar o cabeçalho de IP na fronteira; correção raiz = confiar nos proxies certos (ou em nenhum). Impacto zero ainda deixou uma configuração a corrigir.
Código escrito por IA vazou uma chave de API e gerou cobranças fraudulentas — a verdadeira causa foi um CVSS 10.0 sem correção
O pico na fatura era um sintoma. A causa real foi um RCE público CVSS 10.0 sem correção. Um caso anonimizado, destilado em lições defensivas.
Fundamentos de segurança: o que é de fato perigoso em .env e chaves de API
Comece por aqui. Entenda o que acontece quando .env e chaves de API vazam (chave reserva → personificação → cobrança fraudulenta), e então adote quatro hábitos hoje: não os exponha, não os comite, rotacione tudo se vazar e faça autoverificação.
O .env de apps Laravel era legível pelo mundo inteiro — o erro mais comum de hospedagem compartilhada
A causa: o app inteiro ficava sob a raiz web; só o public/ deveria estar visível. Corrija em três passos — primeiros socorros com .htaccess, rotacione chaves, reestruture — depois previna com processo.
Rodando Next.js com segurança: não ficar para trás nos CVEs publicados
O maior risco de framework são CVEs publicados e negligenciados. Defenda com quatro pilares: julgue pela versão em execução, monitore com Dependabot/osv-scanner, atualize rápido e rode com menor privilégio. A visão deste site: desenvolvedores indie perdem não por conhecimento, mas por continuidade operacional — vença com um sistema que não deixa escapar, não com velocidade.
Mantendo o .env fora da web pública em hospedagem compartilhada
A correção real: corpo do app fora do docroot, só public/ exposto. Estanque o sangramento com .htaccess, torne-o permanente reestruturando e então autoverifique. A visão deste site: isto não é o deslize de uma pessoa, mas um mau padrão padronizado pelo setor — corrija com processo, não com vigilância. bootstrap-redirect vence o symlink.