APIs y GraphQL

Una API web permite que software solicite datos u operaciones. Navegadores, aplicaciones móviles y servicios pueden ser clientes. HTTP y JSON son opciones habituales, pero las API abarcan más que ambos. La decisión de seguridad pertenece al servicio, sea cual sea la interfaz del cliente.

Tres preguntas de permisos

La autorización de objetos determina qué registro puede usar el solicitante. La de funciones determina qué operación puede invocar. La de propiedades establece qué campos puede leer o cambiar. La asignación masiva es una forma de fallo: el enlace automático acepta valores del cliente para estado sensible.

Un campo JSON inesperado no demuestra por sí solo un problema. Importa si el servicio lo acepta, le da significado sensible e incumple la política. Listas, búsquedas, exportaciones y lotes también deben conservar las fronteras entre objetos y organizaciones.

Escenario: el servicio de reservas

Un viajero puede consultar su viaje y modificar una dirección. Un agente de soporte puede emitir ciertos reembolsos según otra política. El servidor controla precio y aprobación; esos campos no se vuelven editables porque el cliente los envíe.

Los reintentos complican el reembolso. Una clave de idempotencia necesita alcance, propietario, duración y relación con la solicitud definidos. Ayuda a evitar duplicados, pero no sustituye autorización ni garantiza ejecución exactamente una vez en cualquier sistema distribuido.

Los esquemas describen, no conceden acceso

OpenAPI describe interfaces HTTP. GraphQL ofrece un modelo tipado con consultas, mutaciones y posibles suscripciones. La introspección es una función del esquema, no una vulnerabilidad por sí misma. Decide qué documentación puede publicarse y aplica permisos independientemente de su visibilidad.

Las comprobaciones GraphQL deben cubrir toda ruta hacia datos sensibles, incluidos campos anidados. Limitar profundidad ayuda, pero una consulta poco profunda puede ser costosa. Considera coste, tamaños de colecciones y lotes, plazos y cancelación, además del número de solicitudes.

Interfaces distintas, principios compartidos

JSON-RPC define llamadas a procedimientos por nombre; no es simplemente otra forma de escribir REST. SOAP y gRPC tienen modelos y herramientas propios. Las preguntas de permisos y fronteras de datos siguen siendo familiares.

La validación de tokens debe considerar emisor, destinatario, propósito y significado confiable de las declaraciones. Un esquema, intermediario API o política CORS no aporta automáticamente todas las reglas de negocio.

Revisa el contrato completo

Documenta clientes, operaciones y campos permitidos, propiedad, sensibilidad, presupuesto de recursos y reintentos. Aceptar páginas grandes invita a revisar límites reales; no demuestra automáticamente una caída. Separa el control ausente observado del impacto sustentado.

Convierte una descripción API en reglas aplicables

El equipo ficticio de reservas entrega este contrato. Un viajero puede leer su reserva y cambiar la dirección de contacto. Un agente de soporte asignado a esa reserva puede solicitar un reembolso. El servidor decide precio y estado de aprobación. Los reembolsos usan una clave de idempotencia limitada al solicitante y a la operación.

El contrato distingue recurso, operación y propiedades modificables. Una sesión válida, JSON bien formado y un endpoint documentado son datos útiles, pero no establecen los tres permisos.

PrediceSe reintenta un reembolso sin cambios, con la misma clave y solicitante. ¿Debe la clave considerarse permiso para emitir otro reembolso?

La clave relaciona el reintento con la operación anterior según el contrato. La autorización sigue aplicándose. El servicio debe conservar el tratamiento de duplicados definido y rechazar o tratar una petición cambiada con esa clave según sus reglas documentadas.

El coste también necesita contrato. Supón que una petición puede seleccionar hasta veinte registros y dispone de cincuenta unidades de coste. La estimación aportada es tres unidades por registro. Veinte registros cumplen el límite de cantidad, pero cuestan sesenta unidades y superan el presupuesto. Son unidades ficticias para el ejercicio; una estimación real necesita calibrarse con el trabajo realizado.

Un límite de cantidad de peticiones en la pasarela no expresa el coste de cada campo anidado ni la propiedad de cada reserva. Aplica las reglas en componentes que las comprendan y registra cómo reintentos, fallos parciales y cancelación afectan estado y consumo.

La verificación debe comparar operaciones permitidas con alternativas rechazadas usando registros de prueba aportados. Incluye lotes y exportaciones: una respuesta individual correcta no establece que cada registro de una colección reciba la misma protección.