Cabeçalhos HTTP são as linhas de informação que acompanham toda requisição e toda resposta na web. Eles não são o conteúdo da página — são o que descreve o conteúdo, quem está pedindo, e o que fazer com ele.
Você nunca os vê navegando, mas eles decidem coisas visíveis: se a página é cacheada, se o navegador confia no site, se um formulário de outro domínio pode enviar dados, e se uma imagem carrega ou não.
Este é o guia de referência: os principais cabeçalhos agrupados por função, os que todo site deveria enviar por segurança, os que vazam informação demais, e como ver os do seu site em dez segundos.
| O que são | Linhas de metadados que acompanham requisições e respostas |
| Formato | Nome: valor, uma por linha |
| Quantos existem | Mais de 100 registrados, e qualquer um pode criar os seus |
| Como ver os do meu site | curl -I https://seusite.com.br |
| Os mais importantes | Os de segurança — e a maioria dos sites não envia nenhum |
Conteúdo
O que é um cabeçalho HTTP
Toda mensagem HTTP tem duas partes: os cabeçalhos e o corpo.
O corpo é o conteúdo — o HTML da página, a imagem, o JSON da API.
Os cabeçalhos são a informação sobre esse conteúdo — o que ele é, quanto ocupa, por quanto tempo pode ser guardado, quem está pedindo.
O formato é sempre o mesmo:
Nome-Do-Cabeçalho: valor Uma por linha, e o nome não diferencia maiúsculas de minúsculas — Content-Type e content-type são o mesmo cabeçalho.
Requisição e resposta usam cabeçalhos diferentes
Essa é a distinção que resolve metade da confusão.
Os cabeçalhos de requisição são enviados pelo navegador. Eles dizem quem está pedindo, o que aceita receber, e em que idioma.
Os cabeçalhos de resposta vêm do servidor. Eles descrevem o que está sendo entregue, por quanto tempo vale, e que regras de segurança aplicar.
⚠️ Alguns aparecem nos dois, como Content-Type — na requisição, descreve o que você está enviando; na resposta, o que está recebendo.
Como ver os cabeçalhos do seu site
Antes das tabelas, vale testar no seu próprio site — os cabeçalhos ficam muito mais concretos quando você vê os seus.
Pelo terminal, a forma mais rápida:
curl -I https://seusite.com.br A opção -I pede apenas os cabeçalhos, sem baixar o conteúdo.
Pelo navegador, sem instalar nada: pressione F12, vá à aba Rede, recarregue a página e clique na primeira linha. Os cabeçalhos de requisição e de resposta aparecem separados.
E se quiser ver também os cabeçalhos que você envia:
curl -v https://seusite.com.br As linhas com > são o que sai; as com < são o que volta.
Uma requisição real, do começo ao fim
É assim que a conversa acontece de verdade.
O navegador envia:
GET /contato HTTP/1.1
Host: exemplo.com.br
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: pt-BR,pt;q=0.9
Accept-Encoding: gzip, deflate, br
Connection: keep-alive E o servidor responde:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4823
Content-Encoding: gzip
Cache-Control: max-age=3600
Strict-Transport-Security: max-age=31536000
Date: Wed, 10 Sep 2026 14:22:03 GMT ⚠️ Repare no Host. Ele é o único cabeçalho obrigatório no HTTP/1.1 — e sem ele não existiria hospedagem compartilhada. Voltaremos a isso.
Cabeçalhos de identificação
Enviados pelo navegador, dizem quem está do outro lado.
| Cabeçalho | O que informa |
|---|---|
Host | Qual site está sendo pedido. Obrigatório desde o HTTP/1.1 |
User-Agent | Navegador, versão e sistema operacional |
Referer | De qual página o visitante veio |
Accept-Language | Idiomas preferidos, em ordem |
X-Forwarded-For | O IP real do visitante, quando há proxy ou CDN no caminho |
Por que o Host mudou a internet
No HTTP/1.0, o cabeçalho não existia — e a consequência era grave: um endereço IP só podia servir um site.
O Host resolveu isso. Ao informar qual site está sendo pedido, ele permite que o servidor decida qual conteúdo entregar — e por isso um único IP hospeda centenas de domínios.
⚠️ A hospedagem compartilhada existe por causa desse cabeçalho. Sem ele, cada site precisaria de um IP próprio — e os endereços IPv4 teriam acabado décadas atrás.
E o Referer está escrito errado
Não é engano de digitação do artigo. A palavra correta em inglês é referrer, com dois erres — mas a especificação original, de 1996, saiu com um erre só.
Quando perceberam, já era tarde: corrigir quebraria todas as implementações existentes. O erro virou padrão, e está lá até hoje.
⚠️ Curiosamente, o cabeçalho moderno que controla seu comportamento — Referrer-Policy — usa a grafia correta. Os dois convivem.
Cabeçalhos de conteúdo
Descrevem o que está sendo enviado.
| Cabeçalho | O que informa |
|---|---|
Content-Type | O tipo do conteúdo: text/html, image/png, application/json |
Content-Length | O tamanho em bytes |
Content-Encoding | A compressão usada: gzip, br (Brotli) |
Content-Disposition | Se o arquivo deve ser exibido ou baixado |
Accept | Os tipos que o navegador aceita receber |
⚠️ O Content-Type é mais importante do que parece. Se ele estiver errado, o navegador pode exibir código-fonte em vez da página, ou baixar um arquivo que deveria abrir. E o charset=UTF-8 nele é o que faz os acentos aparecerem corretamente. Quando os acentos aparecem errados apesar do cabeçalho correto, o problema está na página ou no banco — nosso guia sobre caracteres especiais e acentos em HTML cobre os dois casos.
O Content-Disposition tem um uso prático: attachment; filename="relatorio.pdf" força o download em vez da exibição — útil em área de arquivos.
Cabeçalhos de cache
São os que mais afetam a velocidade do site, e os menos configurados.
| Cabeçalho | O que faz |
|---|---|
Cache-Control | Define as regras de cache. O principal |
ETag | Uma “impressão digital” do arquivo, para verificar se mudou |
Last-Modified | A data da última alteração |
Expires | Data de validade — formato antigo, substituído pelo Cache-Control |
Age | Há quanto tempo a resposta está no cache de um intermediário |
Cache-Control em detalhe
As diretivas mais usadas:
max-age=3600 — pode guardar por 3.600 segundos, ou uma hora.
public — qualquer cache pode guardar, incluindo CDNs e proxies.
private — só o navegador do visitante. Use para páginas com dados de conta.
no-store — não guarde em lugar nenhum, nunca.
immutable — o arquivo nunca muda; nem revalide.
⚠️ E a confusão mais comum do HTTP inteiro: no-cache não significa “não cacheie”.
Ele significa “guarde, mas revalide antes de usar”. O navegador armazena a resposta e, na próxima visita, pergunta ao servidor se ela ainda vale — se sim, recebe um 304 Not Modified e usa a cópia local.
Quem quer proibir o armazenamento usa no-store. São coisas diferentes, e trocá-las é o erro mais frequente em configuração de cache.
Nosso guia sobre cache explica como as camadas se encaixam.
Cabeçalhos de segurança
Esta é a seção mais acionável do artigo — e a maioria dos sites não envia nenhum deles.
| Cabeçalho | O que previne |
|---|---|
Strict-Transport-Security | Obriga o navegador a usar sempre HTTPS, mesmo se digitarem http:// |
Content-Security-Policy | Define quais scripts e recursos podem carregar. Barra ataques de XSS |
X-Frame-Options | Impede que seu site seja exibido dentro de um iframe alheio (clickjacking) |
X-Content-Type-Options | Impede o navegador de adivinhar o tipo do arquivo e executá-lo errado |
Referrer-Policy | Controla quanta informação sobre a origem do visitante é repassada |
Permissions-Policy | Define quais recursos do dispositivo a página pode usar — câmera, microfone, localização |
O conjunto mínimo, pronto para copiar
No .htaccess de um servidor Apache ou LiteSpeed:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule> ⚠️ Quatro cuidados antes de aplicar:
O Strict-Transport-Security só deve ser ativado com HTTPS funcionando em todo o site. Depois de enviado, o navegador se recusa a acessar por HTTP pelo tempo definido — e um ano é bastante tempo se algo der errado. Comece com max-age=300 e aumente depois de confirmar.
O includeSubDomains estende a regra a todos os subdomínios — inclusive os que você esqueceu que existem.
O X-Frame-Options: SAMEORIGIN permite iframe apenas do próprio site. Se você embute o seu conteúdo em outro domínio, isso quebra.
E o Content-Security-Policy não está na lista de propósito. Ele é o mais poderoso e o mais fácil de configurar errado — um CSP mal escrito quebra o site inteiro. Vale estudar antes de aplicar.
Como testar o resultado
Ferramentas gratuitas avaliam os cabeçalhos do seu site e dão uma nota. O securityheaders.com é o mais usado — cola a URL e ele lista o que falta.
Cabeçalhos de autenticação e sessão
| Cabeçalho | O que faz |
|---|---|
Authorization | Envia as credenciais: Bearer token, Basic usuário:senha |
WWW-Authenticate | O servidor informa qual autenticação espera. Acompanha todo erro 401 |
Cookie | O navegador devolve os cookies que recebeu |
Set-Cookie | O servidor define um cookie no navegador |
⚠️ E aqui está a causa mais comum do erro 431 Request Header Fields Too Large: cookies acumulados.
Cada cookie definido no domínio é reenviado em toda requisição. Um site com muitos plugins, ferramentas de análise e testes A/B pode acumular dezenas — e quando o total ultrapassa o limite do servidor, geralmente 8 KB, as requisições passam a falhar.
A solução é limpar os cookies do domínio, e do lado do servidor, revisar o que está sendo definido.
Cabeçalhos de CORS
CORS resolve um problema específico: por padrão, o navegador bloqueia requisições de um domínio para outro. É uma proteção — sem ela, qualquer site poderia ler dados da sua conta em outro.
Os cabeçalhos de CORS são como o servidor autoriza exceções.
| Cabeçalho | O que faz |
|---|---|
Access-Control-Allow-Origin | Quais domínios podem acessar. O principal |
Access-Control-Allow-Methods | Quais métodos são permitidos |
Access-Control-Allow-Headers | Quais cabeçalhos o cliente pode enviar |
Access-Control-Allow-Credentials | Se cookies podem ser enviados junto |
⚠️ Access-Control-Allow-Origin: * libera para qualquer domínio. É conveniente e quase sempre errado — especifique os domínios que precisam de acesso.
Os cabeçalhos que vazam informação
Alguns servidores anunciam mais do que deveriam.
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3 Essas duas linhas informam a versão exata do servidor e do PHP. Para quem procura alvos, é meio caminho andado — basta cruzar com a lista de vulnerabilidades conhecidas daquelas versões.
Como reduzir:
No Apache, ServerTokens Prod e ServerSignature Off.
No PHP, expose_php = Off no php.ini.
E no .htaccess, Header unset X-Powered-By.
⚠️ Isso não substitui manter tudo atualizado — é uma camada a menos de informação para quem varre a internet procurando versões vulneráveis. Manter atualizado continua sendo o que importa.
O prefixo X- e por que ele foi abandonado
Você vai encontrar muitos cabeçalhos começando com X- — X-Frame-Options, X-Forwarded-For, X-Powered-By.
A convenção era essa: cabeçalhos não oficiais deveriam usar o prefixo, para se distinguirem dos padronizados.
O problema apareceu na prática. Vários X- viraram tão usados que foram padronizados — e aí ficaram com um prefixo dizendo que não eram padrão. Renomear quebraria tudo.
⚠️ Em 2012, a RFC 6648 desaconselhou formalmente o prefixo. Mas os que já existiam ficaram, e continuam em uso.
Se você for criar um cabeçalho personalizado hoje, use um nome descritivo sem o X- — algo como Minha-Empresa-Versao.
Cabeçalhos e HTTP/3
No HTTP/1.1, os cabeçalhos são texto puro — é por isso que você consegue lê-los diretamente numa conexão.
No HTTP/2 e no HTTP/3, eles são comprimidos por HPACK e QPACK respectivamente. A economia é significativa: cabeçalhos repetidos entre requisições são enviados apenas uma vez.
Na prática, nada muda para você. O navegador e o servidor cuidam da compressão, e as ferramentas exibem os cabeçalhos já descomprimidos.
⚠️ Um detalhe visível: no HTTP/2 e HTTP/3, os nomes dos cabeçalhos são sempre minúsculos. Se você vir content-type em vez de Content-Type no DevTools, é sinal de que a conexão está usando uma dessas versões.
.htaccess mal escrito derruba o site inteiroEditar cabeçalhos exige acesso ao arquivo de configuração — e um erro de sintaxe ali gera erro 500 em todas as páginas. Na Homehost você tem gerenciador de arquivos com backup antes de editar, logs de erro à mão, e suporte em português quando algo não sobe. Servidores no Brasil, a partir de R$ 7,90/mês.
Ver planos de hospedagemPerguntas frequentes
O que são cabeçalhos HTTP?
São linhas de informação que acompanham toda requisição e resposta na web, no formato Nome: valor. Eles não contêm o conteúdo da página — descrevem o conteúdo, quem está pedindo, e as regras a aplicar: cache, segurança, tipo de arquivo e autenticação.
Como ver os cabeçalhos de um site?
Pelo terminal, com curl -I https://seusite.com.br, que mostra apenas os cabeçalhos de resposta. Ou pelo navegador: F12, aba Rede, recarregar a página e clicar na primeira linha. Para ver também o que você envia, use curl -v — as linhas com > são a requisição e as com < a resposta.
Qual a diferença entre cabeçalho de requisição e de resposta?
Os de requisição vêm do navegador e dizem quem está pedindo, o que aceita receber e em que idioma. Os de resposta vêm do servidor e descrevem o que está sendo entregue, por quanto tempo vale e que regras de segurança aplicar. Alguns, como o Content-Type, aparecem nos dois com significados espelhados.
Quais cabeçalhos de segurança devo usar?
Quatro cobrem a maioria dos casos: Strict-Transport-Security para forçar HTTPS, X-Content-Type-Options: nosniff para impedir que o navegador adivinhe tipos de arquivo, X-Frame-Options: SAMEORIGIN contra clickjacking, e Referrer-Policy para controlar o que é repassado. O Content-Security-Policy é o mais poderoso, e o mais fácil de configurar errado.
Qual a diferença entre no-cache e no-store?
no-cache não significa “não cacheie”. Ele manda guardar a resposta e revalidar com o servidor antes de usá-la. Já no-store proíbe o armazenamento em qualquer lugar. Trocar um pelo outro é o erro mais comum em configuração de cache.
Por que o cabeçalho Referer está escrito errado?
Porque a especificação original, de 1996, saiu com um erre em vez de dois — a grafia correta em inglês é referrer. Quando o erro foi percebido, corrigi-lo quebraria as implementações existentes, e ele virou padrão. Curiosamente, o cabeçalho moderno Referrer-Policy usa a grafia certa, e os dois convivem.
O que é o cabeçalho Host e por que ele importa?
Ele informa qual site está sendo pedido, e é o único obrigatório no HTTP/1.1. Sem ele, um endereço IP só poderia servir um site — e é por causa desse cabeçalho que a hospedagem compartilhada existe, com centenas de domínios num mesmo IP.
Por que aparece o erro 431 no meu site?
Porque os cabeçalhos ultrapassaram o limite do servidor, geralmente 8 KB. A causa quase sempre é cookie acumulado: cada cookie do domínio é reenviado em toda requisição, e sites com muitos plugins e ferramentas de análise acumulam dezenas. Limpar os cookies do domínio resolve para o visitante; do lado do servidor, vale revisar o que está sendo definido.
Devo esconder o cabeçalho Server?
É uma boa prática. Ele e o X-Powered-By informam a versão exata do servidor e do PHP, o que facilita para quem varre a internet procurando versões vulneráveis. Mas esconder não substitui atualizar — é uma camada a menos de informação, não uma proteção.
O que significa o prefixo X- nos cabeçalhos?
Era a convenção para cabeçalhos não oficiais. Ela foi desaconselhada pela RFC 6648, em 2012, porque vários X- acabaram padronizados e ficaram com um prefixo dizendo que não eram padrão. Os antigos continuam em uso; para criar um novo hoje, use um nome descritivo sem o prefixo.
Posso criar meus próprios cabeçalhos?
Pode. Qualquer aplicação pode definir cabeçalhos personalizados, e é comum em APIs para versionamento, chaves e identificadores de requisição. Use um nome descritivo e específico, para não conflitar com nenhum padrão presente ou futuro.
Os cabeçalhos mudam no HTTP/2 e HTTP/3?
O conteúdo não; a forma de transmitir sim. No HTTP/1.1 eles são texto puro; nas versões seguintes são comprimidos por HPACK e QPACK. Um detalhe visível: no HTTP/2 e HTTP/3 os nomes são sempre minúsculos — se você vir content-type em vez de Content-Type no DevTools, a conexão está usando uma dessas versões.
Conclusão
Cabeçalhos HTTP são a parte da web que ninguém vê e que decide quase tudo: se a página é guardada em cache, se o navegador confia no site, se os acentos aparecem certos, e se um script de outro domínio pode rodar na sua página.
Três coisas ficam deste guia. Os cabeçalhos de segurança são os mais importantes e os menos usados — quatro linhas no .htaccess cobrem a maior parte do risco. O no-cache não proíbe o cache — quem proíbe é o no-store, e confundir os dois é o erro mais comum da área. E o Host é o cabeçalho que tornou a hospedagem compartilhada possível.
E o teste que confirma tudo cabe numa linha:
curl -I https://seusite.com.brRode no seu site agora. O que aparecer ali é o que todo visitante recebe — e provavelmente há duas ou três linhas de segurança faltando.
