Fundamentos de Testes de Segurança que Todo Engenheiro QA Deve Conhecer

Digitar uma aspa simples ' em qualquer campo de texto e observar se a aplicação retorna um erro de banco de dados é uma verificação básica de SQL injection. Leva dez segundos e não exige nenhuma ferramenta de segurança. Trocar o ID de recurso na URL para ver se você consegue acessar o recurso de outro usuário detecta autorização quebrada no nível do objeto (BOLA). É uma das vulnerabilidades de API mais comuns, e já está dentro do escopo do QA durante os testes funcionais.

O que engenheiros de QA podem testar sem ferramentas especializadas

Autenticação e gestão de sessão

Os bugs de segurança mais comuns estão nos fluxos de autenticação. Teste isso durante os testes funcionais regulares:

Autorização (controle de acesso)

É aqui que a maioria dos bugs sérios se esconde:

GET /api/orders/12345   ← pedido do usuário A

Faça login como usuário B e acesse a mesma URL. O que acontece?

Validação de input

Cada campo de formulário é um ponto potencial de injeção:

Esses testes manuais são rápidos e capturam o que está mais na superfície. Não substituem o scanning automatizado de segurança, mas valem ser executados em cada nova feature.

HTTPS e cookies

Verifique no DevTools do browser:

• O site é servido via HTTPS? HTTP redireciona para HTTPS?
• Os cookies de sessão estão marcados como HttpOnly (inacessíveis pelo JavaScript)?
• Os cookies de sessão estão marcados como Secure (enviados apenas via HTTPS)?
• O atributo SameSite está configurado como Strict ou Lax nos cookies de autenticação?

No Playwright:

test('cookie de auth tem flags de segurança', async ({ page, context }) => {
  await page.goto('/login');
  // ... realizar login
  
  const cookies = await context.cookies();
  const sessionCookie = cookies.find(c => c.name === 'session_token');

  expect(sessionCookie?.httpOnly).toBe(true);
  expect(sessionCookie?.secure).toBe(true);
  expect(sessionCookie?.sameSite).toMatch(/strict|lax/i);
});

Mensagens de erro e exposição de informações

Mensagens de erro excessivamente detalhadas são um problema de segurança:

• "Usuário não encontrado" vs "Credenciais inválidas": a primeira diz a atacantes quais contas existem
• Stack traces em respostas de produção
• Caminhos internos do servidor, nomes de banco de dados ou versões de bibliotecas em mensagens de erro
• Respostas de API que incluem campos como passwordHash, internalId ou flags de admin

Integrando segurança no processo de testes

Scan baseline com OWASP ZAP

O OWASP ZAP é gratuito e pode rodar como scanner passivo junto com os testes Playwright. O modo de scan baseline percorre a aplicação e sinaliza problemas óbvios:

# .github/workflows/security.yml
- name: ZAP Baseline Scan
  uses: zaproxy/action-baseline@v0.10.0
  with:
    target: 'https://staging.myapp.com'
    rules_file_name: '.zap/rules.tsv'

Isso captura coisas como headers de segurança ausentes, cookies inseguros e informações do servidor expostas, sem precisar escrever nenhum código de teste.

Verificação de security headers

Headers que sua aplicação deve enviar:

Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin

Teste no Playwright:

test('security headers estão presentes', async ({ request }) => {
  const response = await request.get('https://myapp.com');
  const headers = response.headers();

  expect(headers['x-content-type-options']).toBe('nosniff');
  expect(headers['x-frame-options']).toBe('DENY');
  expect(headers['strict-transport-security']).toContain('max-age=');
});

O que passar para especialistas de segurança

Alguns testes de segurança exigem habilidades e ferramentas especializadas:

• Testes de penetração completos
• Análise binária
• Revisão criptográfica
• Segurança de infraestrutura (configuração de cloud, segmentação de rede)
• Testes de engenharia social

Quando você encontrar um problema de segurança potencial durante os testes manuais, documente com clareza (passos de reprodução, impacto potencial) e escale para o time de segurança. Registre como um bug de alta severidade. Não tente provar a exploitabilidade por conta própria. Seu trabalho é encontrar, não explorar.

A melhor postura de segurança é defesa em profundidade: QA capturando os problemas óbvios no desenvolvimento, scanners automatizados cobrindo os sistemáticos no CI, e especialistas revisando antes dos releases principais.