Validar lo que entra en la frontera de la API

Validar en la frontera significa que todo lo que cruza hacia dentro se comprueba contra un esquema declarado: tipos, longitudes, rangos, valores permitidos y, sobre todo, qué campos se aceptan. La regla de diseño es preferir listas de lo permitido a listas de lo prohibido: lo que el esquema no nombra se rechaza.

Pero la frontera no sabe qué significa el dato para el negocio: puede comprobar que un valor asegurado es un número dentro de un rango, no que ese corredor puede cotizar ese ramo. Por eso la validación de forma va en la frontera y la de reglas de negocio va, además, en el servicio que usa el dato. Validar solo en el cliente no es una validación: el cliente lo controla quien llama.

Un servicio que copia al modelo interno todos los campos del cuerpo cuyo nombre coincida deja al llamante fijar valores que el diseño reservaba al servidor. El riesgo se llama asignación masiva y en el catálogo de OWASP de 2023 cae bajo la autorización rota a nivel de propiedad del objeto (API3:2023). Se cierra de dos formas, que conviene tener juntas: un esquema que rechaza campos no declarados y una lista de campos protegidos que el enlace nunca toca.

Abre diseno/esquema-cotizaciones.txt y diseno/modelo-interno.txt. Compara los campos que el esquema público declara con los del modelo y con la lista de campos protegidos.

El consumo de recursos también se diseña en la frontera. Un listado que acepta cualquier tamaño de página convierte una sola petición en una consulta enorme: la base de datos, la memoria del servicio y el ancho de banda pagan por ella. El riesgo está en el catálogo de OWASP como consumo de recursos sin restricción (API4:2023). Cada parámetro numérico necesita un máximo, y cada cliente, una cuota.

diseno/parametros-de-consulta.txt lista los parámetros del listado con su valor por defecto y su máximo.

El campo de adjunto del esquema es una dirección web que el servicio descarga para guardar una copia del documento del tomador. Cuando un servicio hace peticiones a donde le diga el llamante, el servicio actúa con los permisos de su propia red: llega a lugares que el llamante no alcanza. Es el riesgo de falsificación de peticiones del lado del servidor (API7:2023).

El diseño debe quitar la capacidad, no intentar adivinar qué direcciones son peligrosas: las listas de direcciones prohibidas se quedan cortas porque hay muchas formas de escribir la misma dirección. Se compara cuánto cuesta cada propuesta y qué riesgo deja.

Los límites de la puerta de entrada son la primera línea contra el consumo excesivo: tamaño del cuerpo, tiempo máximo y peticiones por minuto. Un límite que nadie conoce no se puede comparar con el uso real. Lee configuracion/gateway.conf y expresa el tamaño máximo del cuerpo en megabytes (1 MB son 1.024 KB).