02 - POST - Envia Formulários

O Método POST é a operação fundamental do HTTP para o envio e processamento de dados que resultam em uma alteração de estado no servidor. Padronizado na RFC 2616 (obsoleta pela RFC 7231 e posteriormente pela RFC 9110), o POST é o motor por trás de todas as interações ricas da Web, desde a submissão de um simples formulário de login até o upload de arquivos complexos e a criação de registros em bancos de dados. Diferente do GET, o POST transporta suas informações de forma oculta da URL, permitindo o envio de volumes massivos de dados de forma estruturada e segura.

1. Características Técnicas: Não-Seguro e Não-Idempotente

Diferente dos métodos de leitura, o POST é classificado em categorias que exigem cuidado extremo por parte do desenvolvedor e do navegador:

• Método Não-Seguro: Por definição, o POST altera o estado do servidor (cria uma conta, processa um pedido, salva um comentário).
• Não-Idempotente: Se o usuário clicar no botão "Enviar" duas vezes em uma conexão instável, o servidor pode acabar processando a mesma ação duas vezes (ex: gerando duas cobranças). Por isso, navegadores exibem o famoso aviso "Confirmar reenvio de formulário" ao tentar recarregar uma página que foi carregada via POST.

2. Transporte de Dados no Corpo (Request Body)

Enquanto o GET usa a URL, o POST coloca seus dados após os cabeçalhos, no corpo da mensagem. Isso permite suportar diferentes formatos, cada um identificado pelo cabeçalho Content-Type:

application/x-www-form-urlencoded

Formato padrão de formulários HTML. Os dados são codificados como pares chave=valor separados por &, com caracteres especiais URL-encoded.

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

user=admin&pass=senha%40123

multipart/form-data

Utilizado para o Upload de Arquivos. Permite enviar dados binários e campos de texto em uma única requisição, separados por delimitadores de "boundary".

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="titulo"

Foto de perfil
------WebKitFormBoundary
Content-Disposition: form-data; name="arquivo"; filename="foto.jpg"
Content-Type: image/jpeg

<bytes binários do JPEG>
------WebKitFormBoundary--

application/json

O formato preferencial para APIs modernas e serviços em nuvem, oferecendo alta legibilidade para máquinas e suporte nativo em todas as linguagens modernas.

POST /api/usuarios HTTP/1.1
Content-Type: application/json
Content-Length: 52

{"nome": "Ana Costa", "email": "ana@exemplo.com"}

3. Resposta Padrão: 201 Created

Quando um POST resulta na criação de um novo recurso, a resposta semanticamente correta é 201 Created (e não 200 OK). O servidor deve ainda incluir o cabeçalho Location apontando para a URI do novo recurso:

HTTP/1.1 201 Created
Location: /api/usuarios/4587
Content-Type: application/json

{"id": 4587, "nome": "Ana Costa", "criado_em": "2024-01-15T10:30:00Z"}

4. O Padrão PRG (Post-Redirect-Get)

Para mitigar os problemas de não-idempotência e melhorar a experiência do usuário, arquitetos de web utilizam o padrão PRG:

1. POST: O cliente envia os dados (ex: Finalizar Compra).
2. Redirect: O servidor processa e responde com um 302 Redirect para uma página de sucesso.
3. GET: O navegador faz uma requisição GET automática para a página de sucesso.

Desta forma, se o usuário der "Refresh" na página de sucesso, ele apenas repetirá um GET seguro, e não o POST de compra.

5. Perspectiva de Cyber Security e Defesa de Dados

Para um analista de Cyber Security, as requisições POST são os maiores vetores de comprometimento de dados e contas.

Proteção Anti-CSRF (Cross-Site Request Forgery)

Como o navegador envia cookies em qualquer requisição, um site malicioso poderia forçar um POST contra um site de banco através de um formulário invisível.

• Defesa: Utiliza-se um Token CSRF (um código aleatório de uso único) embutido no formulário. O servidor só processa o POST se o token enviado bater com o esperado, garantindo que o envio partiu legitimamente do site oficial.

Injeção de Dados e Sanitização

Como o POST permite o envio de grandes volumes de texto, ele é a via preferencial para ataques de SQL Injection e XSS armazenado.

• Regra de Ouro: "Nunca confie na entrada do usuário". Toda requisição POST deve passar por camadas rigorosas de validação de tipo, limpeza de caracteres especiais e parametrização de consultas de banco de dados no backend.

Ataques Comuns via POST

• Mass Assignment: Envio de campos extras (ex: is_admin=true) para escalar privilégios.
• Replay Attack: Interceptação e reenvio de requisições POST autenticadas.
• JSON Bomb: Payload JSON aninhado que consome recursos ao ser parseado.

6. Auditoria Técnica e Diagnóstico de Requisições POST

Ao contrário de um GET, diagnosticar um POST exige a inspeção do corpo da mensagem:

# Enviando um formulario manual via curl
curl -X POST -H "Content-Type: application/x-www-form-urlencoded" \
     -d "user=admin&pass=123" https://site.com/login

# Inspecionando se o servidor respondeu com 201 Created (Sucesso em criacao)
curl -v -X POST -d '{"item":"nexus"}' \
     -H "Content-Type: application/json" \
     http://api.store.com/v1/items

# Upload de arquivo via multipart/form-data
curl -X POST -F "arquivo=@foto.jpg" -F "descricao=Perfil" \
     https://site.com/upload

# Enviando JSON com autenticacao Bearer
curl -X POST \
     -H "Authorization: Bearer eyJhbGciOiJIUzI1NiI..." \
     -H "Content-Type: application/json" \
     -d '{"titulo":"Novo Post","corpo":"Conteudo"}' \
     https://api.meusite.com/posts

7. Diferença Crítica entre POST e PUT

Um erro comum é confundir esses dois métodos.

• POST: O cliente envia dados para uma URI "coleção" (/comentarios) e o servidor decide onde salvar (criando um novo ID). Não é idempotente.
• PUT: O cliente envia dados para uma URI "específica" (/comentarios/123). O servidor substitui o recurso exatamente naquela posição. É idempotente.

8. Limites de Tamanho e Configuração

Diferente do GET (limitado pela URL), o POST permite enviar grandes volumes de dados. Porém, o servidor precisa ser configurado para aceitar esses tamanhos:

# NGINX: Aumentando o limite de upload para 50MB
client_max_body_size 50M;

# Apache: Limite de corpo da requisição
LimitRequestBody 52428800

// PHP: Configuração de upload
upload_max_filesize = 50M
post_max_size = 55M
max_execution_time = 300

9. Conclusão: O Motor da Interatividade Web

O método POST é o que transforma a Internet de um sistema de consulta passiva em uma ferramenta ativa de negócios e comunicação social. Sua capacidade de transportar dados estruturados, arquivos e interações de estado é o que sustenta a economia digital moderna. Dominar a gestão de tokens anti-CSRF, validar as entradas de dados, configurar adequadamente os limites de tamanho no servidor e entender a lógica da não-idempotência são as habilidades que garantem uma infraestrutura web robusta, confiável e resistente a ataques de manipulação de estados e injeção de dados.