Métodos de Requisição HTTP (HTTP Methods)

Os Métodos de Requisição (HTTP Methods), frequentemente chamados de "verbos HTTP", definem a ação técnica que o cliente deseja realizar sobre um recurso identificado por uma URL. Padronizados originalmente na RFC 2616 (1999) e expandidos em documentos posteriores (RFC 5789, RFC 9110, RFC 9111), os métodos conferem uma semântica clara e rigorosa à comunicação Web, permitindo que servidores e intermediários (proxies, firewalls, caches) compreendam a natureza da transação sem precisar analisar o corpo da mensagem. Dominar a distinção entre métodos seguros, idempotentes e de modificação de estado é essencial para arquitetos de APIs REST e auditores de segurança cibernética.

1. Classificação Semântica dos Métodos

Para garantir a previsibilidade da rede, os métodos são classificados em duas grandes categorias técnicas:

1.1 Métodos Seguros (Safe Methods)

São métodos que, por definição, não causam efeitos colaterais no servidor. São destinados apenas à leitura de dados.

• Exemplos: GET, HEAD, OPTIONS.
• Implicação: como não alteram dados, o navegador pode realizar essas requisições automaticamente para fins de prefetching ou caching. Bots de buscadores não devem seguir apenas links seguros.
• Cabeçalho relacionado: Cache-Control (caches podem armazenar respostas de métodos seguros sem invalidação).

1.2 Métodos Idempotentes (Idempotent Methods)

Garantem que múltiplas requisições idênticas produzam o mesmo resultado final no servidor que uma única requisição.

• Exemplos: PUT, DELETE, GET, HEAD, OPTIONS.
• Importância: se uma conexão cair durante uma requisição PUT, o cliente pode retransmiti-la sem o risco de criar dados duplicados. O método POST, ao contrário, não é idempotente — retransmitir um POST pode resultar em duas compras em um cartão de crédito.

Tabela de Classificação

2. Os Principais Verbos da Web Moderna

2.1 GET

Solicita a representação de um recurso específico. É o método mais usado da Internet. Os parâmetros são enviados visíveis na URL (Query String), com limite prático de 2048 caracteres na maioria dos navegadores.

GET /api/usuarios?pagina=2&limite=50 HTTP/1.1
Host: api.exemplo.com
Accept: application/json

2.2 POST

Envia dados para serem processados pelo recurso identificado. É usado para submeter formulários, uploads de arquivos e criações de novos registros em bancos de dados. Os dados viajam no corpo (Body) da mensagem.

POST /api/usuarios HTTP/1.1
Host: api.exemplo.com
Content-Type: application/json
Content-Length: 62

{"nome":"João Silva","email":"joao@exemplo.com","idade":30}

2.3 PUT vs PATCH

• PUT: substitui integralmente o recurso de destino pelos dados enviados. Se campos não forem informados, são sobrescritos com valor padrão (ou nulo). Idempotente — reenviar a mesma requisição produz o mesmo estado final.
• PATCH: aplica modificações parciais a um recurso existente, economizando banda e processamento. Não é estritamente idempotente (depende da implementação).

2.4 DELETE

Solicita a remoção permanente do recurso no servidor de origem. Idempotente: deletar o recurso inexistente retorna 404, mas o estado final (recurso inexistente) é o mesmo.

3. Métodos Auxiliares e de Diagnóstico

• HEAD: idêntico ao GET, mas o servidor envia apenas os cabeçalhos, sem o corpo. Útil para verificar se um arquivo mudou (via ETag/Last-Modified) ou se um link ainda é válido, sem consumir banda de download do recurso completo.
• OPTIONS: retorna quais métodos o servidor suporta para aquele recurso específico (cabeçalho Allow). É o motor por trás do mecanismo CORS Preflight — antes de enviar uma requisição POST cross-origin com cabeçalhos customizados, o navegador envia um OPTIONS para verificar permissões.

OPTIONS /api/usuarios HTTP/1.1
Origin: https://www.exemplo.com
Access-Control-Request-Method: POST

Resposta esperada:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.exemplo.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 86400

4. Perspectiva de Cyber Security: Métodos Perigosos

Para um analista de segurança, os métodos HTTP são vetores de ataque que devem ser restringidos via hardening.

4.1 Riscos do Método TRACE (Cross-Site Tracing — XST)

O método TRACE instrui o servidor a ecoar de volta a requisição exata que recebeu. Um atacante pode usar scripts maliciosos (XSS) para forçar o navegador a enviar uma requisição TRACE. A resposta conterá cabeçalhos sensíveis, incluindo cookies de sessão protegidos por HttpOnly, burlando defesas modernas do navegador. Recomendação: desativar TRACE globalmente no Apache (TraceEnable off) e Nginx.

4.2 Abuso de CONNECT e Cross-Protocol Attacks

O método CONNECT é usado para criar túneis TCP (HTTPS via proxy). Se mal configurado, um atacante pode usar o servidor da empresa como proxy de anonimato para atacar outros sites, escondendo seu IP real atrás da infraestrutura legítima. Também pode ser usado para SSRF (Server-Side Request Forgery) ao conectar em serviços internos como Redis, MongoDB e metadados de cloud (169.254.169.254).

4.3 PUT/DELETE Habilitados sem Autenticação

Se um servidor web como Apache ou Nginx tiver módulos mod_dav (WebDAV) habilitados sem autenticação adequada, atacantes podem sobrescrever páginas (PUT /shell.php) ou apagar conteúdo (DELETE /index.html). Auditorias de hardening sempre verificam:

# Verificando se PUT/DELETE estao habilitados
curl -X OPTIONS -v https://www.alvo.com | grep -i allow

# Testando upload de arquivo arbitrario
curl -X PUT -d "<?php system(\$_GET['c']); ?>" \
     https://www.alvo.com/shell.php

5. Auditoria Técnica e Diagnóstico de Métodos

Para verificar quais ações um servidor permite em sua infraestrutura:

# Consultando os metodos permitidos (OPTIONS)
curl -X OPTIONS -v https://www.meuservidor.com

# Testando se metodos perigosos estao ativos (Auditoria de Hardening)
curl -X TRACE -v http://www.alvo.com
curl -X PUT -v http://www.alvo.com/teste.txt

# Forcando um metodo customizado (API REST)
curl -X PATCH -H "Content-Type: application/json-patch+json" \
     -d '[{"op":"replace","path":"/email","value":"novo@x.com"}]' \
     https://api.exemplo.com/usuarios/1

Hardening Recomendado (Nginx)

if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$ ) {
    return 405;
}

Hardening Recomendado (Apache)

<LimitExcept GET HEAD POST PUT PATCH DELETE OPTIONS>
    Require all denied
</LimitExcept>

TraceEnable Off

Observação: o WebDAV (RFC 4918) estende HTTP com métodos como PROPFIND, MKCOL, COPY, MOVE, LOCK/UNLOCK. Se seu servidor não utiliza WebDAV, bloqueie esses métodos explicitamente.

6. Mapeamento REST para Operações CRUD

O estilo arquitetural REST (RFC 9110) mapeia métodos HTTP para operações CRUD (Create, Read, Update, Delete) de forma intuitiva:

Códigos de Status Comuns por Método

• 200 OK — sucesso genérico
• 201 Created — recurso criado (POST/PUT)
• 204 No Content — sucesso sem corpo (DELETE/PATCH)
• 400 Bad Request — sintaxe inválida
• 401 Unauthorized — falta autenticação
• 403 Forbidden — autenticado, mas sem permissão
• 404 Not Found — recurso inexistente
• 405 Method Not Allowed — método não suportado para o recurso
• 409 Conflict — conflito de estado (POST duplicado)
• 415 Unsupported Media Type — Content-Type não suportado
• 429 Too Many Requests — rate limit excedido

7. Conclusão

Os Métodos de Requisição são a linguagem de comando do HTTP. Eles permitem que a Web seja mais do que uma galeria de imagens estáticas, transformando-a em uma plataforma interativa de manipulação de dados em tempo real. Dominar a semântica de cada verbo (seguro vs idempotente), implementar restrições rigorosas contra métodos desnecessários (TRACE, CONNECT, WebDAV), aplicar o mapeamento REST correto para operações CRUD e validar a idempotência em suas APIs são competências fundamentais para garantir que a infraestrutura seja lógica, performática e, acima de tudo, resistente a manipulações maliciosas.