Seja o seguinte cabeçalho HTTP de uma requisição a um web service baseado em REST.Assinale a alternativa correta a respeito.
A é um bearer token.
BO nome de usuário sendo utilizado é e sua senha é
C codifica um nome de usuário e senha.
DO valor de deve corresponder ao tamanho da string usada em Nesse caso,
EO fato de corresponder a uma senha forte dispensa o uso de HTTPS na requisição, podendo-se usar HTTP, sem criptografia, com boa segurança.
Revelar gabarito e comentário▾
GabaritoC — [imagem] codifica um nome de usuário e senha.
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”.
Autenticação HTTP Basic em Web Services REST
Gabarito: letra C. O cabeçalho HTTP mostrado na figura é o Authorization: Basic <credenciais>, onde <credenciais> é a codificação em Base64 de usuário:senha. A alternativa C afirma exatamente isso: o valor codifica um nome de usuário e senha. As demais alternativas confundem o mecanismo Basic com bearer token, expõem credenciais em texto puro ou sugerem que senha forte dispensa HTTPS — todas incorretas.
A autenticação HTTP Basic é um dos mecanismos mais antigos e simples de controle de acesso em serviços web. Ela funciona assim: o cliente envia uma requisição com o cabeçalho Authorization, cujo valor começa com a palavra Basic seguida de um espaço e de uma string codificada em Base64. Essa string é exatamente a concatenação do nome de usuário, dois-pontos (:) e a senha, codificados em Base64. Por exemplo, se o usuário é alice e a senha é segredo, a string original é alice:segredo, que em Base64 vira YWxpY2U6c2VncmVkbw==. O servidor, ao receber, decodifica a string, separa no primeiro : e obtém as credenciais.
É fundamental entender que Base64 não é criptografia — é apenas uma codificação que transforma bytes em caracteres ASCII legíveis. Qualquer pessoa que intercepte a requisição pode decodificar a string e ler usuário e senha em texto puro. Por isso, o HTTP Basic deve ser usado exclusivamente sobre HTTPS, que criptografa a conexão e protege o cabeçalho contra interceptação. Usar HTTP sem criptografia, mesmo com senha forte, expõe as credenciais a qualquer atacante na rede.
A alternativa E tenta explorar exatamente essa confusão: achar que uma senha forte compensa a falta de HTTPS. Isso é falso — a segurança da transmissão não depende da força da senha, mas do canal seguro. A alternativa B, por sua vez, sugere que o cabeçalho contém o nome de usuário e a senha separados, o que não ocorre: eles vêm concatenados com : e codificados. A alternativa A confunde com bearer token, que é um mecanismo diferente (token de acesso, geralmente JWT, enviado como Authorization: Bearer <token>). A alternativa D fala em tamanho da string, o que não tem relação com o mecanismo.
A pegadinha central desta questão é reconhecer o formato do cabeçalho Authorization: Basic e saber que ele codifica credenciais em Base64. A banca explora a confusão entre os diversos esquemas de autenticação HTTP (Basic, Bearer, Digest) e a falsa sensação de segurança que a codificação Base64 pode transmitir. Guarde a regra: Basic = Base64(usuário:senha), e sempre exige HTTPS.
Autenticação HTTP Basic: Cabeçalho Authorization (Basic + Base64(usuário:senha), Ex.: alice:segredo → YWxpY2U6c2VncmVkbw==); Base64 ≠ criptografia (Decodificável por qualquer um, Exige HTTPS obrigatório); Outros esquemas (Bearer (token, OAuth 2.0), Digest)
Alternativa A — ❌ Incorreta
Afirma que o valor é um bearer token. Bearer token é um mecanismo de autenticação baseado em token de acesso (comum em OAuth 2.0), enviado como Authorization: Bearer <token>. O cabeçalho da figura usa Basic, que é o esquema de autenticação HTTP Basic, não bearer. A confusão está em não distinguir os esquemas de autenticação do cabeçalho Authorization.
Alternativa B — ❌ Incorreta
Diz que o cabeçalho contém o nome de usuário e a senha separados. No HTTP Basic, as credenciais são concatenadas com : (usuário:senha) e depois codificadas em Base64. Não há separação explícita no cabeçalho — o servidor é quem decodifica e separa no primeiro :. A alternativa descreve um formato que não existe no mecanismo.
Alternativa C — ✅ Correta ⟵ GABARITO
O valor do cabeçalho Authorization: Basic é a codificação em Base64 de usuário:senha. Isso é exatamente o que a alternativa afirma: o valor codifica um nome de usuário e senha. É a definição do mecanismo HTTP Basic Authentication.
Alternativa D — ❌ Incorreta
Menciona que o valor deve corresponder ao tamanho da string usada em outra parte, o que não faz sentido no contexto. O HTTP Basic não impõe nenhuma relação de tamanho entre o valor codificado e qualquer outra string. A alternativa parece inventar uma regra que não existe.
Alternativa E — ❌ Incorreta
Afirma que senha forte dispensa HTTPS. Isso é um erro grave de segurança: a codificação Base64 não é criptografia, e qualquer interceptação revela as credenciais. O HTTPS é indispensável para proteger a transmissão, independentemente da força da senha. A alternativa tenta justificar o uso de HTTP sem criptografia, o que é sempre inseguro para autenticação.
Gabarito: letra C — o cabeçalho Authorization: Basic codifica usuário e senha em Base64.
Assinale a alternativa correta a respeito.
é um bearer token.
e sua senha é 
codifica um nome de usuário e senha.
deve corresponder ao tamanho da string usada em 
Nesse caso, 
corresponder a uma senha forte dispensa o uso de HTTPS na requisição, podendo-se usar HTTP, sem criptografia, com boa segurança.