Método POST

Fundamentos Security Notes Jan 9, 2026 HTTP
http http-methods create unsafe

Definición

POST es el método HTTP para crear nuevos recursos o enviar datos que causan efectos secundarios en el servidor. Cuando envías un formulario, subes un archivo, o creas un nuevo registro vía API, típicamente estás usando POST.

POST no es idempotente - enviar la misma petición POST dos veces podría crear dos recursos. Tampoco es safe - POST está explícitamente diseñado para modificar el estado del servidor. Los datos de la petición van en el body (no en la URL), permitiendo payloads grandes como imágenes, documentos o estructuras JSON complejas.

POST es el método HTTP más flexible. Aunque es principalmente para creación, POST puede manejar cualquier operación que no encaje en la semántica de otros métodos - búsquedas complejas, operaciones batch o flujos de trabajo que no mapean a CRUD simple.

Ejemplo

Registro de Usuario: Crear una nueva cuenta envía POST /users con nombre de usuario, email y contraseña en el body de la petición.

Creación de Post de Blog: Publicar un nuevo artículo es POST /posts con el título, contenido y metadatos.

Subida de Archivo: Subir una foto de perfil usa POST /users/123/avatar con el archivo de imagen en el body.

Envío de Formulario: El envío de un formulario de contacto envía POST /contact con nombre, email y mensaje.

Procesamiento de Pago: Cargar una tarjeta de crédito es POST /payments con cantidad, detalles de tarjeta e ID de cliente.

Ejemplo de Código

// POST para crear recurso
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 67

{
  "name": "Alice",
  "email": "[email protected]",
  "password": "hashed_password"
}

// Respuesta
HTTP/1.1 201 Created
Location: /api/users/123
Content-Type: application/json

{
  "id": 123,
  "name": "Alice",
  "email": "[email protected]",
  "created": "2026-01-09T10:30:00Z"
}

Notas de Seguridad

SECURITY NOTES

CRÍTICO - …

Configuración y Validación:

  • Valida todos los datos POST para prevenir ataques de inyección (SQL, XSS, command injection).
  • Usa HTTPS para cifrar datos sensibles en tránsito.
  • Implementa protección CSRF para operaciones que cambian estado.
  • Aplica rate limiting a endpoints POST para prevenir abuso y DoS.
  • Nunca confíes en IDs proporcionados por el cliente para creación.
  • Valida subidas de archivos (tipo, tamaño, contenido).

Monitoreo y Protección:

  • Sanitiza input de usuario antes de almacenar.
  • Usa autenticación fuerte para endpoints protegidos.
  • Implementa claves de idempotencia para operaciones críticas.
  • Verifica autorización antes de permitir creación de recursos.
  • Previene envíos duplicados con tokens.
  • Registra todas las operaciones POST para auditoría.

Mejores Prácticas

  1. Retorna 201 Created para creación exitosa de recursos
  2. Incluye header Location con URL del recurso recién creado
  3. Valida todos los datos de entrada exhaustivamente
  4. Implementa protección CSRF para formularios web
  5. Usa claves de idempotencia para operaciones críticas (pagos)
  6. Aplica rate limiting para prevenir abuso
  7. Retorna el recurso creado en el body de la respuesta
  8. Usa Content-Type apropiado (application/json, multipart/form-data)
  9. Implementa manejo de errores adecuado con mensajes descriptivos
  10. Considera usar 202 Accepted para procesamiento asíncrono

Errores Comunes

Retornar 200 OK en lugar de 201 Created, falta de header Location, no validar input, usar GET para operaciones que cambian estado, sin protección CSRF, permitir envíos duplicados, mensajes de error pobres, no sanitizar inputs, falta de rate limiting, registro inadecuado.

Estándares y RFCs

Términos Relacionados