1) Autenticação sem senha: WebAuthn e Passwordless

Em produção, a autenticação passwordless baseada em WebAuthn vem ganhando terreno por oferecer resistência a phishing e uma experiência de usuário mais fluida. Credenciais criptográficas, seja em hardware (security keys) ou authenticadores embutidos (platform authenticators), reduzem significativamente o risco de roubo de senhas.

O caminho típico de implementação envolve a configuração do Relying Party, geração de challenges provenientes do servidor e o armazenamento seguro de publicKeyCredential na base de dados. Boas práticas:

• Oferecer WebAuthn como opção principal, com fallback seguro para métodos equivalentes (passkeys) quando disponível.
• Armazenar apenas credentialId, publicKey e fontes de usuário, evitando armazenar senhas.
• Exigir verificação do usuário (UV) para operações sensíveis, quando apropriado.
• Validar attestation conforme o nível de confiança desejado, levando em conta a necessidade de interoperabilidade.

Perfomance e UX melhoram quando o fluxo de registro e login é simples e o site informa claramente as opções de autenticação.

// Pseudo fluxo WebAuthn (servidor)
const challenge = base64urlEncode(generateChallenge());
const credOptions = {
  challenge: challenge,
  rp: { name: "YuriDev" },
  user: { id: user.id, name: user.email, displayName: user.displayName },
  pubKeyCredParams: [{ type: "public-key", alg: -7 }, { type: "public-key", alg: -257 }],
  timeout: 60000,
  attestation: "direct",
  authenticatorSelection: { userVerification: "preferred" }
};

res.json(credOptions);

// No cliente: navigator.credentials.create(credOptions) e depois verifyAssertion no servidor

2) Zero Trust aplicado a aplicações web

O modelo Zero Trust coloca a identidade no centro de tudo e assume que não há perímetro seguro. Em vez de confiar apenas na sessão, adotamos verificação contínua de identidade, dispositivo e comportamento, com políticas granularizadas.

Princípios-chave que tenho aplicado:

• Autenticação multifator forte para qualquer acesso, com políticas de acesso mínimo necessário (least privilege).
• Verificação contínua de postura de dispositivo e contexto (local, rede, integridade de endpoints).
• Segmentation de recursos: recursos sensíveis isolados por identidade de usuário e função, com controles baseados em risco.
• Logs centralizados e correlacionamento de eventos para detecção de anomalias sem depender de perímetros fixos.

A adoção prática envolve integração com um Identity Provider (IdP) confiável, políticas de acesso dinâmicas e uma arquitetura que permita mudanças rápidas de contexto sem comprometer a experiência do usuário.

3) Conteúdo seguro no front-end: CSP, SRI e cookies

Proteger o conteúdo servido ao navegador exige uma abordagem de defesa em profundidade. Ferramentas como Content Security Policy (CSP), Subresource Integrity (SRI) e políticas de cookies têm se tornado parte essencial das melhores práticas.

• CSP forte com nonce ou hash para scripts críticos, permitindo controle granular sobre origens e dinamismo de scripts.
• SRI para garantir a integridade de recursos terceiros carregados pela página.
• Diretivas para evitar clickjacking (frame-ancestors) e proteção de tipo de conteúdo (X-Content-Type-Options).
• Políticas de cookies seguras: SameSite, HttpOnly e Secure, combinadas com HSTS para forçar HTTPS.
• Referrer-Policy para reduzir vazamento de dados sensíveis no cabeçalho Referer.

Observação prática: combine CSP com relatórios de violação (report-uri/report-to) para detectar falhas sem impactar o usuário final.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'nonce-xyz123';
  style-src 'self' 'nonce-xyz123';
  object-src 'none';
  connect-src 'self';
  img-src 'self' data:;
  base-uri 'self';
  frame-ancestors 'none';
  report-uri /csp-report;

4) Segurança de APIs, TLS 1.3 e mTLS

A proteção de APIs evoluiu com a adoção de TLS 1.3, que oferece handshake mais rápido e forte criptografia, aliada a práticas de segurança de API como mTLS, OAuth 2.1 (PKCE para clientes públicos) e validação de tokens com escopos e públicos.

• TLS 1.3 por padrão para todas as conexões; desabilite recursos legados desvantajosos, como 0-RTT quando necessário.
• Mutual TLS (mTLS) para serviço a serviço, com gestão de certificados e rotação de credenciais.
• Boas práticas de API security: validação de audience (aud), scopes, uso de registros de consentimento, e proteção com API gateway.
• Arquitetura centrada em identidade: autenticação e autorização consistentes entre clientes, proxies e serviços.

Prática recomendada: implemente rate limiting, logging abrangente, e validação de tokens em cada fronteira de API para reduzir superfícies de ataque.