Questão de Segurança da Informação — Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.) — CESPE / CEBRASPE 2026
Segurança da Informação›Ataques a Aplicações Web (XSS, CSRF, SQL Injection etc.)
Código
ce390556
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2026
Cargo
AUFC ( )
A respeito de controles e testes de segurança para aplicações web, múltiplos fatores de autenticação e soluções para segurança da informação, julgue o item a seguir.
A validação de segurança realizada no cliente é suficiente para eliminar os riscos de injeção em aplicações web baseadas em APIs REST, desde que o tráfego esteja protegido por TLS.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Segurança em Aplicações Web: Validação no Cliente e TLS
❌ ERRADO. A validação de segurança realizada no cliente (navegador) é insuficiente para eliminar os riscos de injeção em APIs REST, mesmo com o tráfego protegido por TLS. A validação no cliente é apenas uma medida de usabilidade e conveniência, facilmente contornada por um atacante; a segurança efetiva contra injeção (SQL, XSS, etc.) exige validação e sanitização rigorosas no servidor, além de práticas como consultas parametrizadas. O TLS protege os dados em trânsito (confidencialidade e integridade), mas não impede que um atacante envie payloads maliciosos diretamente para a API, ignorando a interface do cliente.
A validação de entrada é um dos pilares da segurança de aplicações web. Ela consiste em verificar se os dados fornecidos pelo usuário estão dentro dos critérios esperados (tipo, tamanho, formato, faixa de valores) antes de processá-los. Essa validação pode ser feita em duas camadas: no cliente (front-end) e no servidor (back-end). A validação no cliente, geralmente implementada com JavaScript, oferece uma resposta imediata ao usuário, melhorando a experiência, mas não é uma medida de segurança confiável. Um atacante pode facilmente desabilitar o JavaScript, usar ferramentas como o Burp Suite para interceptar e modificar requisições, ou simplesmente enviar requisições HTTP diretamente para a API, sem passar pela interface web. Portanto, qualquer validação feita no cliente pode ser contornada.
A validação no servidor é a única camada que realmente protege a aplicação. Ela deve ser considerada a última linha de defesa e deve ser implementada de forma rigorosa, assumindo que todos os dados de entrada são potencialmente maliciosos. Para prevenir ataques de injeção, como SQL Injection, a prática recomendada é o uso de consultas parametrizadas (prepared statements), que separam os dados dos comandos SQL, impedindo que o atacante altere a estrutura da consulta. Além disso, a sanitização de entradas (escapar caracteres especiais) e a validação de tipos e formatos são essenciais.
O TLS (Transport Layer Security) é um protocolo criptográfico que garante a confidencialidade e a integridade dos dados em trânsito entre o cliente e o servidor. Ele protege contra ataques de interceptação (eavesdropping) e adulteração (tampering) dos dados durante a transmissão. No entanto, o TLS não tem nenhum papel na validação de entrada. Ele não impede que um atacante envie dados maliciosos para a API; apenas garante que esses dados trafeguem de forma criptografada. Um atacante pode usar o próprio TLS para enviar um payload de SQL Injection de forma segura, e o servidor, se não validar a entrada, processará o payload malicioso.
A confusão entre validação no cliente e segurança real é uma pegadinha clássica em provas. A banca tenta fazer o candidato acreditar que, com TLS e validação no cliente, a aplicação está segura. Na prática, a segurança de uma aplicação web depende de uma abordagem em camadas (defense in depth), onde a validação no servidor é obrigatória e a validação no cliente é apenas um complemento de usabilidade. O OWASP Top 10, referência em segurança de aplicações web, classifica a injeção como uma das vulnerabilidades mais críticas, e suas diretrizes de prevenção enfatizam a validação no servidor, o uso de consultas parametrizadas e a sanitização de entradas.
Guarde a fronteira entre o que o TLS protege (dados em trânsito) e o que a validação no servidor protege (processamento de dados): é exatamente nessa distinção que a assertiva se divide.
Validação de entrada: No cliente (front-end) (Usabilidade e conveniência, Facilmente contornável (Burp Suite, JS desabilitado)); No servidor (back-end) (Única camada de segurança real, Consultas parametrizadas, Sanitização de entradas); TLS (Protege dados em trânsito, Não impede payloads maliciosos)
Item — ❌ ERRADO
A afirmação de que a validação no cliente é suficiente para eliminar riscos de injeção, mesmo com TLS, é falsa. O erro central está em considerar a validação no cliente como uma medida de segurança eficaz. Ela é facilmente contornável e não substitui a validação no servidor. O TLS, por sua vez, protege apenas o canal de comunicação, não o processamento dos dados. Portanto, a assertiva está incorreta.