Assumindo que as credenciais estão corretas, qual é a principal vulnerabilidade de segurança que esse código NÃO aborda ao interagir com o banco de dados?
AAusência de Prepared Statements para prevenir SQL Injection em consultas futuras.
BFalta de tratamento de erros na consulta SQL.
CCredenciais de banco de dados expostas no código.
DNÃO utilização de HTTPS para a conexão.
EFalta de validação de entrada de dados do usuário.
Revelar gabarito e comentário▾
GabaritoA — Ausência de Prepared Statements para prevenir SQL Injection em consultas futuras.
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”.
SQL Injection e a conexão PHP com MySQL
Gabarito: letra A. O código apresentado apenas estabelece a conexão com o banco de dados e a encerra, sem executar nenhuma consulta SQL. A principal vulnerabilidade que ele não aborda é a ausência de prepared statements (consultas parametrizadas) para prevenir SQL Injection em consultas futuras — exatamente o que a alternativa A afirma. As demais alternativas ou não se aplicam ao trecho (B, D) ou são problemas reais, mas não são o foco da pergunta (C, E).
O trecho de código PHP usa a extensão mysqli para conectar ao MySQL. Ele cria a conexão, verifica se houve erro e a fecha. Não há nenhuma consulta SQL sendo executada — não há SELECT, INSERT, UPDATE ou DELETE. Portanto, a questão pergunta qual vulnerabilidade o código não aborda ao interagir com o banco de dados, ou seja, qual falha de segurança permaneceria se, em seguida, o desenvolvedor fosse executar consultas.
A SQL Injection é um ataque que ocorre quando dados fornecidos pelo usuário são concatenados diretamente em uma consulta SQL, permitindo que o atacante manipule a query e acesse, modifique ou delete dados indevidos. A principal defesa contra esse ataque é o uso de consultas parametrizadas (prepared statements), que separam os dados dos comandos SQL. No código mostrado, não há nenhuma preparação para isso — não há uso de prepare(), bind_param() ou qualquer técnica de parametrização. Assim, se o desenvolvedor fosse escrever uma consulta como SELECT * FROM usuarios WHERE login = '$login', concatenando a variável $login diretamente, o código estaria vulnerável a SQL Injection.
O OWASP Top 10, referência mundial em segurança de aplicações web, classifica a Injeção como uma das categorias de risco mais críticas. As vulnerabilidades típicas incluem: dados fornecidos não validados, consultas dinâmicas não parametrizadas e dados hostis concatenados diretamente. A prevenção recomendada é justamente o uso de consultas parametrizadas, validação rigorosa de entrada e escape adequado de caracteres especiais.
A pegadinha desta questão está em distinguir o que o código faz (apenas conecta) do que ele deveria fazer (preparar-se para consultas seguras). As alternativas C e E apontam problemas reais, mas que não são o foco da pergunta: as credenciais expostas no código são um problema de configuração, e a falta de validação de entrada é uma prática geral, mas a questão especificamente pergunta sobre a interação com o banco de dados. A alternativa B (falta de tratamento de erros na consulta SQL) não se aplica porque não há consulta SQL no código. A alternativa D (não utilização de HTTPS) é irrelevante para a conexão com o banco de dados, que ocorre no servidor, não entre o cliente e o servidor web.
Guarde a distinção: o código conecta, mas não consulta. A vulnerabilidade que ele não aborda é a que apareceria quando uma consulta fosse feita — e aí a falta de prepared statements é a falha crítica.
1Cria conexão (mysqli)
2Verifica erro de conexão
3Fecha conexão
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
A alternativa A está correta porque o código não utiliza prepared statements (consultas parametrizadas) para prevenir SQL Injection. O trecho apenas cria a conexão com new mysqli(...) e a fecha com $conn->close(). Não há nenhuma preparação para executar consultas de forma segura. Se o desenvolvedor fosse executar uma consulta concatenando dados do usuário diretamente na string SQL, o código estaria vulnerável a SQL Injection. A ausência de prepare() e bind_param() é exatamente a falha que a alternativa aponta.
Alternativa B — ❌ Incorreta
A alternativa B está incorreta porque o código não executa nenhuma consulta SQL. O trecho apenas conecta ao banco e verifica se houve erro na conexão (if ($conn->connect_error)). Não há SELECT, INSERT, UPDATE ou DELETE para que se fale em "falta de tratamento de erros na consulta SQL". O tratamento de erros que existe é apenas para a conexão, não para consultas.
Alternativa C — ❌ Incorreta
A alternativa C está incorreta porque, embora as credenciais estejam de fato expostas no código (o que é uma má prática), a questão pergunta especificamente sobre a vulnerabilidade que o código não aborda ao interagir com o banco de dados. A exposição de credenciais é um problema de configuração/segurança do código-fonte, não uma vulnerabilidade na interação com o banco. Além disso, a pergunta é sobre a principal vulnerabilidade, e a ausência de prepared statements é mais diretamente relacionada à interação com o banco.
Alternativa D — ❌ Incorreta
A alternativa D está incorreta porque a conexão com o banco de dados MySQL ocorre no servidor, entre o PHP e o MySQL, não entre o cliente e o servidor web. O HTTPS protege a comunicação entre o navegador do usuário e o servidor web, não a comunicação entre o PHP e o banco de dados. Portanto, a não utilização de HTTPS não é uma vulnerabilidade na interação com o banco de dados.
Alternativa E — ❌ Incorreta
A alternativa E está incorreta porque, embora a falta de validação de entrada seja uma prática de segurança importante, a questão pergunta especificamente sobre a vulnerabilidade que o código não aborda ao interagir com o banco de dados. A validação de entrada é uma camada de defesa, mas a principal vulnerabilidade na interação com o banco é a ausência de prepared statements, que é o que a alternativa A aponta. Além disso, a validação de entrada não é uma defesa completa contra SQL Injection, pois muitos aplicativos exigem caracteres especiais.
NÃO CAIA NESSA!
A banca explora a confusão entre o que o código faz (apenas conecta) e o que ele deveria fazer (preparar-se para consultas seguras). As alternativas C e E apontam problemas reais, mas não são o foco da pergunta. A alternativa B não se aplica porque não há consulta SQL. A alternativa D é irrelevante para a conexão com o banco. A chave é perceber que a vulnerabilidade aparece quando uma consulta for feita — e aí a falta de prepared statements é a falha crítica.
PEGA ESSA DICA!
Em questões sobre SQL Injection, lembre-se sempre: a defesa principal é o uso de consultas parametrizadas (prepared statements). Quando o código não usa prepare() e bind_param(), ele está vulnerável. Validação de entrada é uma camada adicional, mas não substitui a parametrização.