DevTools, acessibilidade, desempenho e segurança

Identificação

• Duração: 2 horas
• Tipo: auditoria guiada e correção
• Entrega: relatório de auditoria da landing page
• Lista de verificação: ../materiais/checklist-auditoria-web.md
• Auditoria de referência: ../exemplos/aula-1.5/relatorio-auditoria.md

Introdução

O que é DevTools?

DevTools é o conjunto de ferramentas de desenvolvimento incluído nos navegadores. Ele permite inspecionar o HTML renderizado, descobrir quais regras CSS foram aplicadas, acompanhar requisições, ler erros e depurar JavaScript.

Normalmente pode ser aberto pelo menu do navegador ou por um atalho de teclado. Ele não modifica permanentemente os arquivos do servidor: alterações feitas durante a inspeção são temporárias.

Qualquer pessoa pode abrir o DevTools?

Sim. O código enviado ao navegador pode ser observado pelo usuário. Por isso, nunca devemos considerar HTML, CSS ou JavaScript do front-end como secretos.

Uma chave de API colocada no JavaScript do navegador pode ser encontrada. Ocultar um botão com CSS também não substitui autorização no servidor.

Usar DevTools é “hackear”?

Inspecionar uma aplicação própria ou um ambiente autorizado faz parte do desenvolvimento. A ferramenta também pode ser usada para estudar problemas de acessibilidade, desempenho e segurança.

Ter acesso ao DevTools não concede autorização para atacar sistemas, acessar contas ou explorar serviços de terceiros.

O que significa segurança nesta aula?

Segurança significa reduzir riscos previsíveis:

• não expor credenciais;
• validar entradas;
• não confiar no navegador para autorização;
• evitar inserção insegura de conteúdo;
• controlar recursos carregados;
• registrar e corrigir falhas.

Acessibilidade, desempenho e segurança não são ajustes finais. São critérios de qualidade que acompanham todo o desenvolvimento.

Objetivos

Ao final da aula, o aluno deverá conseguir:

1. utilizar DevTools para investigar uma página;
2. identificar requisições, status e recursos;
3. analisar erros e avisos no console;
4. inspecionar elementos, estilos e acessibilidade;
5. testar navegação por teclado;
6. detectar rolagem horizontal;
7. reconhecer problemas básicos de desempenho;
8. identificar exposições comuns de dados e credenciais;
9. compreender a função inicial de uma Content Security Policy;
10. registrar evidências e priorizar correções.

Pré-requisitos

• landing page semântica;
• CSS responsivo;
• formulário controlado por JavaScript;
• noções de HTTP, DOM e eventos.

Pergunta orientadora

Como demonstrar, com evidências, que uma página funciona corretamente além de apenas “parecer pronta”?

Roteiro sugerido

1. Auditoria baseada em evidências

Uma revisão técnica não deve terminar em “funcionou para mim”.

Uma evidência pode ser:

• status HTTP;
• captura de tela;
• mensagem do console;
• sequência reproduzível;
• medida de largura;
• elemento do DOM;
• resultado de um teste;
• comparação antes e depois.

Cada achado deve responder:

1. o que foi observado;
2. como reproduzir;
3. qual é o impacto;
4. qual é a prioridade;
5. como corrigir;
6. como confirmar a correção.

2. Painéis principais do DevTools

Os nomes podem variar entre navegadores, mas os conceitos permanecem.

Ferramentas automatizadas ajudam a encontrar indícios. Elas não substituem testes com teclado, leitura do conteúdo e análise de risco.

3. Elements

Inspeção do DOM

Verifique:

• existe apenas um main;
• o título principal é coerente;
• IDs são únicos;
• rótulos estão associados aos campos;
• elementos interativos possuem nome acessível;
• estados ocultos utilizam o atributo correto;
• não existem elementos interativos aninhados.

Estilos calculados

Utilize a área de estilos para identificar:

• regra aplicada;
• regra sobrescrita;
• arquivo e linha de origem;
• herança;
• box model;
• dimensões finais.

Alterações temporárias

Modificar o CSS no DevTools é útil para experimentar, mas não altera o arquivo original. Registre a decisão e aplique-a no código.

4. Console

O console deve permanecer limpo durante o fluxo principal.

Problemas comuns:

• arquivo não encontrado;
• variável inexistente;
• seletor que retorna null;
• promessa rejeitada sem tratamento;
• política de segurança bloqueando recurso;
• uso de API obsoleta;
• erro provocado por extensão do navegador.

Diferencie origem

Antes de corrigir, confirme se a mensagem vem:

• do seu código;
• do navegador;
• de uma extensão;
• de um recurso de terceiro.

Não esconda erros com um try/catch vazio:

try {
  await operation();
} catch {
  // Nada acontece
}

Trate a falha e apresente uma resposta segura ao usuário.

5. Network

Recarregue a página com o painel aberto e observe:

• documento HTML;
• CSS;
• JavaScript;
• SVG;
• método;
• status;
• tipo;
• tamanho;
• tempo.

Perguntas

• algum recurso retornou 404?
• algum recurso foi redirecionado?
• existe arquivo que não é utilizado?
• recursos são carregados por HTTPS em produção?
• dados pessoais aparecem na URL?
• a página depende de domínio externo?
• o formulário realizou uma requisição inesperada?

Preserve registro

Quando uma navegação ou redirecionamento apagar a lista, utilize a opção de preservar o registro durante a investigação.

6. Depuração

Um breakpoint pausa a execução.

No envio do formulário:

1. abra main.js;
2. localize o evento submit;
3. adicione breakpoint;
4. preencha com dados fictícios;
5. envie;
6. observe formData, payload e o estado do botão;
7. continue a execução.

Não capture ou compartilhe valores pessoais durante uma depuração.

7. Acessibilidade por teclado

Teste:

1. recarregue a página;
2. pressione Tab;
3. utilize o link “Pular para o conteúdo”;
4. percorra a navegação;
5. abra e feche perguntas frequentes;
6. preencha o formulário;
7. envie com Enter;
8. identifique a mensagem de resultado.

Verifique:

• foco sempre visível;
• ordem de foco coerente;
• nenhum foco preso;
• todos os controles alcançáveis;
• conteúdo não depende apenas de hover;
• mensagem de resultado anunciável.

8. Zoom e redimensionamento

Teste:

• 200% de zoom;
• largura de 320 px;
• orientação vertical;
• textos maiores;
• conteúdo longo.

O objetivo não é manter a mesma composição visual, mas preservar:

• leitura;
• funcionalidade;
• ordem;
• foco;
• ausência de sobreposição;
• ausência de perda de conteúdo.

9. Árvore de acessibilidade

A árvore de acessibilidade é derivada do DOM.

Observe:

• papel;
• nome acessível;
• estado;
• descrição;
• relacionamento.

Exemplo:

button "Quero participar"
textbox "Nome"
textbox "E-mail profissional"
combobox "Qual opção representa melhor seu perfil?"
checkbox "Concordo em receber informações..."
status "Cadastro simulado com sucesso"

Se o elemento não possui nome compreensível, revise HTML, rótulo e atributos antes de adicionar ARIA.

10. Desempenho

Problemas iniciais comuns:

• imagens muito maiores que o espaço exibido;
• JavaScript que bloqueia a página;
• fontes externas desnecessárias;
• bibliotecas usadas para tarefas simples;
• layout que muda durante o carregamento;
• arquivos duplicados;
• animações excessivas.

Inspeção inicial

Registre:

• quantidade de requisições;
• tamanho aproximado;
• erros;
• recursos externos;
• estabilidade visual;
• capacidade de interação.

Regra prática

Não otimize sem evidência. Primeiro identifique o gargalo, depois faça uma alteração mensurável.

11. Segurança no front-end

O navegador é um ambiente controlado pelo usuário. Tudo que chega ao front-end pode ser observado.

Nunca coloque no código do navegador:

• chaves privadas;
• senha de banco;
• token administrativo;
• credencial de provedor de IA;
• regra de autorização considerada secreta;
• dado sensível desnecessário.

Validação

Validação no navegador melhora a experiência, mas pode ser alterada ou removida pelo usuário. O back-end deverá validar novamente.

Front-end valida para ajudar.
Back-end valida para proteger.

XSS

Evite inserir entrada externa com innerHTML.

status.textContent = message;

Quando HTML dinâmico for indispensável, será necessário um processo adequado de sanitização.

Dados em URLs

URLs podem aparecer em:

• histórico;
• registros;
• favoritos;
• analytics;
• cabeçalhos de referência.

Não coloque senha, token ou dado sensível em cadeias de consulta.

12. Content Security Policy

Uma Content Security Policy, ou CSP, restringe as origens autorizadas para recursos e execução.

Na página estática de laboratório:

<meta
  http-equiv="Content-Security-Policy"
  content="
    default-src 'self';
    img-src 'self';
    style-src 'self';
    script-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
  "
>

Essa versão:

• permite recursos da mesma origem;
• bloqueia plugins embutidos;
• impede alteração de URL base;
• restringe o destino do formulário.

Em produção, a política normalmente é enviada como cabeçalho HTTP. Uma política precisa ser adaptada aos recursos reais e testada antes de ser aplicada de forma restritiva.

13. Referrer Policy

A política de referência controla parte das informações enviadas ao navegar para outro endereço.

<meta name="referrer" content="strict-origin-when-cross-origin">

Ela não substitui a decisão de evitar dados sensíveis na URL.

14. Armazenamento do navegador

Inspecione cookies, localStorage e sessionStorage.

Pergunte:

• por que o dado está armazenado?
• por quanto tempo?
• quem consegue acessá-lo?
• ele é sensível?
• pode ser removido?

A Knowledge AI não grava nome ou e-mail no armazenamento local.

15. Auditoria da Knowledge AI

Execute:

Estrutura

• título e descrição;
• landmarks;
• hierarquia de títulos;
• rótulos;
• texto alternativo;
• idioma.

Interação

• envio inválido;
• sucesso;
• erro simulado;
• recuperação;
• teclado.

Responsividade

• 320 px;
• 375 px;
• 768 px;
• 1280 px;
• ausência de rolagem horizontal.

Recursos

• HTML;
• CSS;
• JavaScript;
• SVG;
• status HTTP;
• console.

Segurança

• ausência de credenciais;
• ausência de dados em registros;
• textContent;
• CSP inicial;
• destino de formulário restrito;
• sem armazenamento de dados pessoais.

16. Priorização

Utilize:

Corrija primeiro segurança e bloqueios de fluxo.

17. Modelo de achado

### A-01 - Foco invisível

- Prioridade: alta
- Área: acessibilidade
- Evidência: ao navegar com Tab, não é possível identificar o link ativo
- Impacto: usuários de teclado perdem a posição
- Correção: adicionar estilo para `:focus-visible`
- Validação: repetir o fluxo completo usando apenas teclado

18. Exercício de fixação

Audite uma página anterior ou outro pequeno projeto.

Registre no mínimo:

• um achado de acessibilidade;
• um achado de desempenho;
• um achado de segurança;
• uma evidência de funcionamento correto;
• prioridade;
• correção proposta.

19. Desafio individual

Remova temporariamente o arquivo main.js da referência no HTML.

Observe:

• Network;
• Console;
• comportamento do formulário;
• experiência do usuário.

Depois restaure o arquivo e documente:

1. como o problema foi detectado;
2. qual foi a evidência;
3. qual foi a causa;
4. como foi validada a correção.

Não deixe a referência removida na entrega final.

20. Erros comuns

Corrigir somente o sintoma

Um 404 não deve ser ocultado. Corrija o caminho ou remova a referência.

Confiar apenas em pontuação automática

Uma nota alta não garante usabilidade, segurança ou conteúdo correto.

Testar somente com mouse

Inclua teclado em todo fluxo.

Ignorar mensagens do console

Mesmo que a interface pareça funcionar, um erro pode indicar fluxo incompleto.

Aplicar CSP sem testar

Uma política incorreta pode bloquear CSS, JavaScript, imagens ou integrações legítimas.

Expor dados em captura

Utilize dados fictícios e revise evidências antes de compartilhá-las.

Otimizar sem medir

Registre o antes e o depois.

21. Lista de verificação de entrega

• O fluxo principal foi testado.
• O console não apresenta erros da aplicação.
• Todos os recursos retornam sucesso.
• A navegação funciona por teclado.
• O foco é visível.
• O formulário comunica sucesso e erro.
• Não existe rolagem horizontal em 320 px.
• A página funciona com zoom.
• Não existem credenciais no front-end.
• Dados pessoais não aparecem na URL ou console.
• O armazenamento do navegador foi inspecionado.
• A CSP foi compreendida e testada.
• Os achados possuem evidências.
• Correções foram revalidadas.

22. Critérios de aceite

A entrega será aceita quando:

1. apresentar um relatório reproduzível;
2. incluir evidências de rede e console;
3. testar teclado e responsividade;
4. classificar prioridades;
5. registrar correções;
6. repetir os testes após as correções;
7. não expor dados pessoais;
8. explicar por que a validação do front-end não protege o back-end;
9. explicar a finalidade de uma CSP;
10. demonstrar o fluxo principal sem erros.

23. Perguntas para revisão

1. Qual é a diferença entre DOM original e DOM renderizado?
2. O que deve ser observado no painel Network?
3. Como diferenciar um erro da aplicação de um erro de extensão?
4. Por que o teste por teclado é indispensável?
5. O que a árvore de acessibilidade representa?
6. Por que validação no navegador não é suficiente?
7. Qual risco existe ao utilizar innerHTML com entrada externa?
8. Para que serve uma CSP?
9. Por que dados sensíveis não devem aparecer em URLs?
10. O que torna um relatório de auditoria reproduzível?

Próxima aula

Na Aula 1.6, o projeto será versionado, documentado, publicado e apresentado. O aluno concluirá o primeiro módulo com uma entrega de portfólio.