Amenazas, fallos de autorización, abuso de negocio y controles técnicos para proteger APIs corporativas
Edición en profundidad - material de estudio y consulta profesional
Por João Ricardo Dutra••Material integral
Security Top 10: riesgos relacionados con el ciclo completo de
Figura de apertura: Los diez riesgos representan clases de fallas que abarcan el diseño, la implementación, la y la operación.
Principio central
La reduce la exposición, pero la autorización y la lógica segura deben existir en todas las capas.
Edición en profundidad: material de estudio y consulta profesional.
Presentación del capítulo
El capítulo anterior detalló Azure Management y mostró cómo las aplican políticas, límites, autenticación, enrutamiento y observabilidad. Este capítulo amplía la visión: la seguridad de la no es una funcionalidad exclusiva de la . La puede estar perfectamente protegida por y aun así permitir que un usuario autenticado lea objetos de otro cliente, modifique campos prohibidos o realice una operación administrativa incorrecta.
El Security Top 10 organiza los riesgos más relevantes para las en un lenguaje práctico. La edición 2023 destaca fallas de autorización en objetos sensibles, autenticación, propiedades, funciones y flujos; consumo irrestricto de recursos; ; configuraciones inseguras; inventario inadecuado; y dependencia excesiva de de terceros. Estas categorías ayudan a los equipos de productos, arquitectura, desarrollo, seguridad y operaciones a desarrollar un vocabulario común.
El objetivo no es transformar el Top 10 en una lista de control superficial. Cada riesgo representa una familia de causas, condiciones de operación e impactos. Para comprenderlos es necesario relacionar identidad, autorización, esquemas, límites operativos, comportamiento empresarial, topología de red, dependencias externas y ciclo de vida. El capítulo también diferencia los controles preventivos, de detección y de respuesta, mostrando el papel específico de , , y procesos de gobernanza.
Los ejemplos utilizan escenarios corporativos y bancarios sin exponer entornos reales. El lector debería poder reconocer patrones vulnerables, formular hipótesis de ataque, proponer controles en múltiples capas y transformar los hallazgos en requisitos de ingeniería verificables.
Cómo estudiar este capítulo
Para cada categoría, separe cuatro dimensiones: activo protegido, condición vulnerable, acción del atacante y control verificable. Luego, identifique qué parte pertenece a la , cuál pertenece al y cuál depende de la gobernanza o del proceso.
Objetivos de aprendizaje
Explique el propósito y las limitaciones de Security Top 10.
Identifique las diferencias entre autorización de objeto, y rol.
Reconozca fallas de autenticación y administre , sesiones y credenciales.
Diseñar límites contra el consumo irrestricto de recursos y el abuso de los flujos de negocios.
Comprenda , configuraciones inseguras, inventario inadecuado y de .
Relacione cada riesgo con controles en código, , , red, identidad y observabilidad.
Aplique modelos de amenazas, pruebas de seguridad y evidencia de CI/CD al ciclo de vida.
Construir estrategias de hardening, seguimiento, respuesta y mejora continua.
Estructura del capítulo
25.1 Los 10 principales modelos de seguridad y uso responsable
25.2 API1: Autorización a nivel de objeto roto
25.3 API2: autenticación rota
25.4 API3: Autorización de nivel de de objeto roto
25.5 API4: Consumo de recursos sin restricciones
25.6 API5: Autorización de nivel de función rota
25.7 API6: Acceso sin restricciones a flujos comerciales confidenciales
25.8 API7: falsificación de solicitudes del lado del servidor
25.9 API8: Configuración incorrecta de seguridad
25.10 API9: Gestión de inventario inadecuada
25.11 API10: de
25.12 Controles de y defensa en profundidad
25.13 Pruebas, observabilidad y respuesta
25.14 Estudios de casos y laboratorios
Resumen, lista de verificación, ejercicios, glosario y referencias.
25.1 Los 10 principales modelos de seguridad y uso responsable
El Top 10 es un documento de concientización y priorización, no una especificación de seguridad completa. Una puede ser vulnerable a riesgos que no aparecen en la lista, y la ausencia de hallazgos en el Top 10 no demuestra seguridad. El uso correcto combina , requisitos de protección, arquitectura, pruebas, revisión de código, gestión de dependencias, telemetría y respuesta a incidentes.
Las exponen operaciones que el software puede consumir directamente. Esto aumenta la automatización de los atacantes, la velocidad de enumeración y la capacidad de encadenar fallas. Los identificadores en rutas, consultas y cargas útiles se pueden cambiar a gran escala; los esquemas permiten explorar propiedades imprevistas; y se puede abusar de las transmisiones legítimas sin cargas útiles con formato incorrecto. Por lo tanto, la seguridad de la requiere observar la intención y el contexto, no solo la sintaxis.
La defensa en profundidad distribuye responsabilidades. reduce el tráfico malicioso conocido; la pasarela valida , cuotas y contratos; el aplica autorización vinculada al dominio; el banco limita el acceso; y la observabilidad detecta patrones anómalos.
Ninguna de estas capas reemplaza a las demás. El tráfico interno puede eludir un control perimetral, mientras que un fallo empresarial puede parecer perfectamente válido para un filtro genérico.
Defensa en profundidad para
Figura 1: Security es un sistema de controles complementarios, no un producto aislado.
Tabla 1: Cada capa protege un conjunto diferente de decisiones.
capa
Control de características
Limitación
WAF/borde
Reputación, firmas, protección volumétrica.
Poco contexto de dominio y propiedad.
API Gateway
Token, esquema, cuotas, enrutamiento y auditoría.
No conoces todas las reglas del negocio.
backend
Autorización fina, invariantes y validaciones.
Puede depender de la identidad y el contexto correctos.
Datos/terceros
Mínimo privilegio y restricción de salida.
No reemplaza los controles de la aplicación.
25.2 API1: Autorización a nivel de objeto roto -
La autorización a nivel de objeto roto ocurre cuando una operación recibe un identificador de objeto y no verifica si el sujeto autenticado tiene permiso sobre ese objeto específico. El atacante no necesita romper la autenticación: usa su propia cuenta, cambia una identificación e intenta acceder a una cuenta, contrato, documento, pedido o recurso que pertenece a otra persona u organización.
El error común es interpretar la autenticación como autorización. Saber quién realizó la llamada no responde si esa persona puede leer o modificar el objeto solicitado. Los y los identificadores aleatorios reducen la previsibilidad, pero no son control de acceso. Las identificaciones pueden aparecer en registros, enlaces, respuestas, dispositivos o integraciones, y la autorización debe aplicarse independientemente de lo difícil que sea adivinar.
La defensa más fuerte es vincular la búsqueda al contexto autorizado. En lugar de cargar un objeto solo por ID y verificarlo más tarde, el repositorio puede buscar por ID, tenant y sujeto autorizado, devolviendo ausencia cuando la relación no existe. Las políticas centralizadas ayudan, pero es necesario darles atributos suficientes. Las pruebas deben variar el usuario, el tenant, la función, el objeto y el método para encontrar inconsistencias.
Figura 2: La verificación debe relacionar el objeto con el sujeto y el tenant, no solo validar el .
Ejemplo conceptual de autorización por objeto
// Patrón vulnerable
cuenta = repositorio.buscarPorId(idDeSolicitud)
return cuenta
// Patrón defensivo
cuenta = repositorio.buscarPorIdYTitular(idDeSolicitud, subjectDelToken)
if cuenta == null: denegarAcceso()
25.3 API2: autenticación rota
La autenticación rota reúne fallas que le permiten asumir o mantener la identidad de otro usuario, aplicación o carga de trabajo. Los ejemplos incluyen credenciales débiles, de inicio de sesión sin protección de automatización, predecibles, validaciones o de firmas incompletas, recuperación de contraseñas inseguras, sesiones que no caducan y reutilizables sin detección.
En las modernas, la autenticación suele implicar más de un sistema: cliente, authorization server, y . La validación debe confirmar el algoritmo, la firma, el issuer, la audience, la caducidad, el type y el contexto de uso. Aceptar un donde se espera un , ignorar a la audience o confiar en claves obtenidas de una fuente no validada son fallas de diseño, no solo fallas de implementación.
Los controles incluyen para operaciones adecuadas, , rotación de , protección de credential stuffing, limitación de intentos, revocación, detección de anomalías, almacenamiento secreto seguro y proof-of-possession cuando el riesgo lo justifica. Los mensajes de error deben impedir la enumeración de cuentas y los flujos de recuperación deben tener una seguridad equivalente al inicio de sesión principal.
Tabla 2 - La autenticación segura depende del protocolo y de su funcionamiento completo.
fracaso
Impacto
controlar
Emisor o audience no validados
Se acepta token de otro contexto.
Estricta validación y configuración por entorno.
Actualizar token sin rotación
El robo mantiene el acceso prolongado.
Detección de rotación y reutilización.
Iniciar sesión sin protección
Relleno y adquisición de credenciales.
Limitación de tarifas, MFA y detección de riesgos.
Secreto en código o registro
Compromiso del cliente.
Salto, rotación y enmascaramiento.
25.4 API3: Autorización de nivel de de objeto roto
Esta categoría reúne fallas de autorización a nivel de las propiedades de un objeto. Al leer, la puede devolver campos que el usuario no debería ver. Por escrito, puede aceptar propiedades que el consumidor no debe controlar. La edición de 2023 combina problemas históricamente descritos como exposición excesiva de datos y .
Un ejemplo de lectura insegura es devolver el objeto de entidad completo y esperar que el front-end oculte el CPF, el límite interno, las señales de fraude o los datos administrativos. El consumidor controla la solicitud y puede observar la respuesta en bruto. Por escrito, vincular automáticamente el recibido a una entidad permite que aquellos que no tienen autorización cambien campos como rol, estado, ID de propietario o aprobado.
La solución utiliza modelos de entrada y salida específicos, listas de campos permitidos, autorización de , serialización contextual y validación de esquemas. requiere atención especial porque pueden existir campos confidenciales en el esquema y requerir su propia autorización. En la , la validación y la transformación ayudan, pero el debe controlar la verdad del dominio.
Carga útil que requiere una lista permitida de propiedades editables
Nunca exponga ni acepte automáticamente todas las propiedades de una entidad persistente. Los contratos de deben ser proyecciones explícitas, basadas en casos de uso y niveles de autorización.
25.5 API4: Consumo de recursos sin restricciones
Las consumen CPU, memoria, subprocesos, conexiones, almacenamiento, ancho de banda y servicios que se cobran por uso. Cuando no hay límites coherentes, un atacante puede provocar indisponibilidad o costos excesivos al enviar muchas solicitudes, grandes cargas útiles, consultas complejas, cargas, exportaciones u operaciones que activan costosas acciones de terceros.
La limitación de tarifas por solicitud es solo una parte. Es necesario controlar el tamaño del cuerpo y la respuesta, la profundidad de , la duración, la concurrencia, la paginación, la cantidad de elementos, la compresión, la cantidad de conexiones y el costo acumulado por operación. Una llamada de informe puede costar miles de veces más que una sola lectura, por lo que los límites uniformes pueden proteger mal el sistema.
El diseño debe combinar cuotas por identidad e tenant, tiempos de espera, mamparos, contrapresión, colas, límites de conexión y disyuntores. Las métricas deben distinguir el rechazo protector del error interno. En la nube, las alertas de costos y los presupuestos también integran protección, ya que el abuso puede aparecer primero en la factura antes de causar una indisponibilidad visible.
Tabla 3 - El consumo debe medirse por el costo real de la operación.
Característica
Posible abuso
control técnico
procesador/memoria
Consulta compleja, expresión regular costosa, bomba de descompresión.
Complejidad, tamaño y tiempo de espera.
Conexiones
Enchufes persistentes o piscina agotada.
Límite de concurrencia y tiempo de espera de inactividad.
Almacenamiento
Cargas y registros excesivos.
Cuota, retención y tamaño máximo.
Servicio pago
SMS, mapas, IA o antifraude.
Presupuesto, tarifa por flujo y aprobación.
25.6 API5: Autorización de nivel de función rota
La autorización de nivel de función rota ocurre cuando un usuario logra invocar una función que debería estar restringida a otro rol, grupo o contexto. La diferencia para es el enfoque: pregunta si el usuario puede acceder a ese objeto; pregunta si puede realizar esa función, independientemente del objeto.
Los administrativos ocultos, los cambios de métodos y las rutas predecibles son vectores comunes. Un usuario puede intercambiar por , llamar a /admin, reutilizar una operación observada en el portal o invocar directamente una función que la interfaz visual no muestra. Ocultar el botón o el no es autorización.
Los controles incluyen denegación predeterminada, matriz de permisos por rol, pruebas negativas, separación de superficies administrativas y validación consistente en todos los métodos. La puede aplicar y roles, pero las decisiones de dominio pueden depender del estado, la autoridad, el valor de la transacción o la segregación de funciones, lo que requiere una evaluación en el o PDP.
Tabla 4 - Los tres niveles de autorización deben probarse por separado.
Objeto de la decisión
Pregunta
Ejemplo
Objeto - BOLA
¿Puede este tipo acceder a esta cuenta?
OBTENER /cuentas/123
Función - BFLA
¿Este tipo puede cerrar cuentas?
ENVIAR /cuentas/123/cerrar
Propiedad - BOPLA
¿Este tema puede cambiar este campo?
Rol o límite de PATCH
25.7 API6: Acceso sin restricciones a flujos comerciales confidenciales
Algunas transmisiones son técnicamente legítimas pero valiosas para el abuso automatizado. Los bots pueden explotar a escala la compra de boletos, la creación de cuentas, la solicitud de crédito, el canje de beneficios, el envío de códigos, las reservas y los comentarios, incluso si cada solicitud tiene un esquema válido y un usuario autenticado.
El problema requiere modelar la intención y la economía del flujo. Un límite genérico por puede fallar cuando el atacante distribuye solicitudes. La protección puede requerir un fuerte vínculo de identidad, límites por persona y dispositivo, detección de comportamiento, colas, pasos adelante, prueba de humanidad, reglas antifraude y restricciones específicas por paso.
No existe un control universal. El equipo necesita identificar flujos sensibles durante el , estimar cómo generan valor para el atacante y definir signos de abuso. Los registros comerciales, las tasas de conversión, los intentos por entidad y los patrones temporales son más útiles que las métricas técnicas.
Diferencia esencial
El abuso del flujo de negocios puede utilizar solicitudes perfectamente válidas. La validación de esquemas y rara vez es suficiente; El control necesita comprender el propósito de la operación y la identidad económica del actor.
25.8 API7: Falsificación de solicitudes del lado del servidor -
ocurre cuando la recupera un recurso remoto utilizando una o un destino influenciado por el usuario sin las restricciones adecuadas. El servidor tiene una conectividad e identidad diferentes a las del cliente y puede acceder a metadata de la nube, paneles internos, servicios administrativos, loopback o redes privadas inaccesibles directamente para el atacante.
Los casos comunes incluyen importación de , , validación de imágenes, conversión de documentos y devoluciones de llamadas. Validar el esquema por sí solo no lo resolverá: los nombres pueden resolverse en direcciones privadas, las redirecciones pueden cambiar el destino y las representaciones de alternativas pueden eludir filtros ingenuos. La nueva vinculación de y las diferencias entre validación y conexión aumentan el riesgo.
La defensa preferida es incluir en la lista de destinos y rutas de salida específicos. Cuando se necesiten arbitrarias, utilice resolución controlada, bloqueo de rangos privados y especiales, revalidación después de redireccionamientos, protección de cambios de , de salida e identidad mínima. La respuesta remota debe ser limitada en tamaño, tipo y tiempo.
Ejemplo conceptual del intento de la
POST /importar-documento
{
"url": "http://169.254.169.254/metadata/..."
}
# La entrada parece una URL, pero el destino alcanzado por el servidor
# puede exponer servicios internos o credenciales de infraestructura.
25.9 API8: Configuración incorrecta de seguridad
La configuración incorrecta de seguridad cubre configuraciones inseguras en cualquier capa: permisivo, débil, de depuración, mensajes detallados, credenciales predeterminadas, faltantes, servicios innecesarios, permisos excesivos, depósitos públicos, administración expuesta y políticas inconsistentes en todos los entornos.
Las se componen de muchos componentes y el riesgo surge de las interacciones. Una puede validar correctamente, pero confiar en un encabezado de identidad enviado por el cliente. Un se puede proteger en el borde y exponer directamente desde otra dirección. Puede existir una política segura en producción, pero no en el espacio de trabajo u operación específica debido a una herencia incorrecta.
La solución depende de líneas base versionadas, infraestructura como código, revisión de cambios, escáneres de configuración, separación de entornos, gestión de secretos y pruebas posteriores a la implementación. Los errores deben estandarizarse sin rastros de pila ni detalles internos. Los recursos administrativos necesitan su propia red e identidad.
Tabla 5: Se debe verificar la configuración efectiva, no solo el archivo deseado.
Área
Ejemplo de mala configuración
evidencia
TLS
Versión o cifrado inapropiado.
Configuración de protocolo de enlace y escucha.
CORS
Origen reflejado con credenciales.
Headers de políticas y de verificación previa.
API Gateway
Cabecera interna confiada sin remoción.
Seguimiento y configuración efectiva.
backend
Endpoint directo público.
DNS, escaneo autorizado y firewall.
25.10 API9: Gestión de inventario inadecuada
El inventario inadecuado ocurre cuando la organización no sabe qué , versiones, hosts, entornos, operaciones y dependencias están activos. Las ocultas, las versiones antiguas, los de prueba y la documentación divergente mantienen las superficies vulnerables fuera del proceso de gobernanza.
El inventario debe incluir el propietario, la clasificación de los datos, los consumidores, la versión, el entorno, el nombre de host, el , la autenticación, la fecha de depreciación y la telemetría. El descubrimiento de tráfico puede complementar el catálogo, ya que la documentación no prueba que solo sean accesibles los conocidos. El , el ingreso, las , los repositorios y la observabilidad deben estar correlacionados.
Las versiones retiradas deben retirarse en toda la cadena. Mantener la versión 1 sin soporte por temor a arruinar a los consumidores acumula riesgos. Una política de ciclo de vida con desaprobación, extinción, comunicación, evidencia de uso y apagado controlado reduce las superficies huérfanas.
Figura 3: La seguridad acompaña a la desde su diseño hasta su retiro, con el inventario como eje de gobernanza.
25.11 API10: de
Una aplicación puede aplicar una validación estricta a clientes externos y depender excesivamente de las de socios, proveedores o servicios internos. El de ocurre cuando los datos y comportamientos provenientes de estas dependencias se tratan como seguros, lo que permite la inyección, indirecta, corrupción de datos, indisponibilidad o compromiso de la cadena.
La comunicación autenticada y cifrada solo prueba el canal y la identidad del par; no garantiza que la respuesta sea correcta o sin grants. Las respuestas de terceros necesitan esquema, límites de tamaño, tiempo de espera, validación semántica, manejo seguro de redirecciones y codificación. Las bibliotecas de clientes, los certificados, el y la configuración de también integran la superficie.
Las arquitecturas resilientes utilizan salida controlada, listas permitidas, disyuntores, aislamiento, contratos, observabilidad de dependencia y least privilege. Los secretos enviados al socio deben ser específicos y rotativos. Los datos devueltos nunca deben concatenarse en SQL, comandos, plantillas o sin el tratamiento adecuado.
Tabla 6: Las dependencias deben tratarse como límites de confianza.
dependencia
Riesgo
controlar
API de socio
Respuesta maliciosa o inesperada.
Esquema, validación y aislamiento.
Webhook recibido
Origen y replay falsificados.
Firma, marca de tiempo e idempotencia.
SDK/biblioteca
Comportamiento o cadena comprometidos.
SBOM, fijación y actualización controlada.
Servicio interno
Confianza implícita lateral.
mTLS, política de autorización y salida.
25.12 Controles de y defensa en profundidad
es una capa privilegiada para aplicar controles uniformes: autenticación, validación de , esquema, límite de carga útil, cuotas, , eliminación de , enrutamiento, , observabilidad y bloqueo de versiones. También proporciona un punto de contención para la respuesta a incidentes. Sin embargo, no debería transformarse en el único mecanismo de autorización de dominio.
, autorización por y flujos confidenciales generalmente requieren datos que solo el conoce. La puede validar y , pero la , la autoridad, el estado del objeto y la segregación de roles deben evaluarse en el servicio o en un PDP con suficiente contexto. La política debe negar por defecto y propagar la identidad de forma no falsificable.
Los controles también deben preservar los diagnósticos. Los rechazos deben registrar la regla, la identidad, la operación, el tenant y la correlación sin exponer secretos. Las métricas para 401, 403, 429, violaciones de esquema y bloqueos ayudan a detectar ataques, pero deben contextualizarse para diferenciar el abuso del error de integración.
Tabla 7: La API Gateway es importante, pero no reemplaza la seguridad de las aplicaciones.
Riesgo
API Gateway contribuye
El backend/proceso debe garantizar
API1 / API3 / API5
Identidad, scopes y contrato.
Titularidad, rol y propiedades autorizadas.
API4/API6
Límites, cuotas y telemetría.
Costo real y reglas de negocio.
API7
Política de salida y política de URL cuando sea compatible.
Validación y aislamiento de objetivos.
API8/API9
Línea base y publicación controlada.
Inventario, ciclo de vida y configuración completa.
API10
mTLS, lista de permitidos y tiempo de espera.
Validación de respuesta y confianza mínima.
25.13 Pruebas, observabilidad y respuesta
Las pruebas de seguridad deben explorar el contexto, no sólo las cargas útiles. Para la autorización, utilice matrices con usuarios, roles, tenants, objetos, propiedades, estados y métodos. Para la autenticación, pruebe los caducados, el issuer incorrecto, la audience diferente, los algoritmos y la revocación. Para los umbrales, mida el comportamiento en condiciones de concurrencia, grandes cargas útiles y operaciones costosas en un entorno autorizado.
La automatización de CI/CD puede realizar linting , SAST, SCA, pruebas de contratos, escáneres DAST y políticas de infraestructura. Aún así, los hallazgos automáticos necesitan validación. Las herramientas identifican patrones, pero difícilmente comprenden todos los flujos sensibles y las relaciones de . Las revisiones manuales y el siguen siendo necesarios.
La observabilidad debe capturar señales técnicas y comerciales: identidad, tenant, operación, objeto lógico, estado, latencia, tamaño, costo, rechazo, y correlación. Las alertas deben buscar anomalías como enumeración de ID, picos 403, creación acelerada de cuentas o llamadas a destinos inusuales. El plan de respuesta debe permitirle revocar credenciales, bloquear rutas, reducir límites y preservar pruebas.
Pruebas responsables
Las pruebas ofensivas solo deben realizarse en entornos y explícitamente autorizados. Utilice datos sintéticos, límites controlados y un plan de reversión para evitar impactos en los usuarios y los sistemas de producción.
25.14 Estudios de casos y laboratorios
Estudio de caso 1: en Open Finance: un consulta el consentimiento por identificador. El es válido, pero el servicio no verifica que el consentimiento pertenezca al cliente y participante correcto. La corrección incluye consultas por ID de consentimiento, tema y organización, además de pruebas cruzadas y registros de decisiones.
Estudio de caso 2: Abuso de flujo: un de simulación de crédito llama a servicios pagos y permite un gran volumen de cuentas recién creadas. La limitación de tarifas por no va en contra de la distribución. La defensa combina límite por persona, dispositivo, tenant, coste por operación, detección de comportamiento y colas.
Estudio de caso 3: de socio: un servicio de documentos acepta externa y sigue redirecciones. Un dominio permitido redirige a una dirección privada. La solución utiliza de salida, resolución y validación de final, bloqueo de redes especiales, límite de redireccionamiento y respuesta máxima.
Laboratorios sugeridos
1) Construir una matriz de autorización para objeto, rol y . 2) Modelo de límites de costos para tres operaciones. 3) Revisar una especificación para campos confidenciales y huérfanos. 4) Diseñar una arquitectura de salida segura para . 5) Cree alertas de enumeración, abuso y aumento de rebotes.
Resumen del capítulo
El Security Top 10 2023 organiza los riesgos que aparecen de forma recurrente en las . Las primeras categorías resaltan que la autenticación y la autorización deben operar en diferentes niveles: objeto, , función y flujo de negocios. Otros riesgos tienen que ver con el consumo de recursos, , configuración, inventario y dependencias externas.
La protección eficaz combina controles en el borde, la , el , los datos y los procesos. El portal estandariza las políticas y reduce la exposición, pero no es el único que conoce la , el estatus y la intención comercial. El desarrollo seguro, el , el inventario y la observabilidad son esenciales.
El Top 10 debería guiar las preguntas y prioridades, no servir como un certificado de seguridad. Una plataforma madura transforma cada riesgo en requisitos, pruebas, métricas, evidencia y planes de respuesta, manteniendo la protección durante todo el ciclo de vida de la .
Siguiente paso del curso
El siguiente capítulo profundiza en , CSP, y otros , mostrando cómo las políticas de transporte y navegador complementan la seguridad de las y las aplicaciones web.
Lista de verificación de seguridad
Cada operación que recibe una identificación verifica la , el tenant y el contexto de autorización.
La entrada y la salida utilizan modelos explícitos y listas de propiedades permitidas.
Los se validan por firma, issuer, audience, hora y tipo.
Las funciones administrativas tienen y pruebas negativas.
Las operaciones tienen límites de tamaño, tiempo, simultaneidad, costo y paginación.
Los flujos sensibles tienen protección contra la automatización y el abuso económico.
Las llamadas salientes utilizan listas permitidas, salida controlada y bloqueo de red especial.
La configuración efectiva se versiona, revisa y prueba después de la implementación.
El inventario contiene propietario, versión, entorno, datos, consumidores y fecha de retiro.
Las respuestas de terceros se validan y se tratan como no confiables.
Los registros y seguimientos preservan la correlación sin registrar credenciales ni datos confidenciales.
Existe un proceso de revocación, bloqueo, reducción de límites y respuesta a incidencias.
Ejercicios
Diferenciar , y autorización por con ejemplos.
Explique por qué no es control de autorización.
Enumere las validaciones necesarias para un .
Límites de diseño para una operación de exportación de informes.
Describir cómo los bots pueden abusar de un flujo técnicamente válido.
Proponer controles contra en una funcionalidad de importación de .
Identifique los riesgos de confiar en un encabezado de identidad del cliente.
Cree un inventario mínimo para las empresariales.
Describir cómo validar las respuestas de una de socio.
Cree una estrategia de telemetría para detectar la enumeración de objetos.
Glosario
Tabla 8 - Vocabulario esencial del capítulo.
Término
Definición
BOLA
Autorización a nivel de objeto roto; falla de autorización en un objeto específico.
BFLA
Autorización de nivel de función rota; acceso indebido a una función u operación.
BOPLA
Autorización a nivel de propiedad de objeto roto; exposición indebida o alteración de propiedades.
Relleno de credenciales
Uso automatizado de credenciales filtradas en otros servicios.
Denegar por defecto
Principio de denegar el acceso cuando no existe un permiso explícito.
control de salida
Control de destinos a los que puede acceder una aplicación.
asignación masiva
Vinculación automática de campos de entrada a propiedades internas.
Propiedad
Relación que determina quién puede acceder o modificar un objeto.
Limitación de velocidad
Restricción de frecuencia de llamadas en una ventana.
Flujo de negocios sensible
Flujo legítimo que produce valor y del que se puede abusar a escala.
API sombra
API activa fuera del inventario o gobierno oficial.
SSRF
Falsificación de solicitudes del lado del servidor; inducir al servidor a acceder a destinos inapropiados.
Modelado de amenazas
Análisis estructurado de activos, amenazas, superficies y controles.
Consumo inseguro
Dependencia excesiva de los datos y el comportamiento de las API dependientes.
Referencias técnicas
Proyecto de seguridad . Top 10 de seguridad de de - 2023.
. API1:2023: autorización a nivel de objeto roto.
. API2:2023: autenticación rota.
. API3:2023: Autorización a nivel de de objeto roto.
. API4:2023 - Consumo de recursos sin restricciones.
. API5:2023 - Autorización de nivel de función rota.
. API6:2023: acceso sin restricciones a flujos comerciales confidenciales.
. API7:2023: falsificación de solicitudes del lado del servidor.
. API8:2023: configuración incorrecta de seguridad.
. API9:2023 - Gestión inadecuada del inventario.
. API10:2023 - de .
Estándar de verificación de seguridad de aplicaciones y serie de hojas de referencia.
. Marco de desarrollo de software seguro - SSDF.
. 9110 - Semántica .
Nota de actualización
Este capítulo utiliza la edición 2023 de Security Top 10, publicado por el proyecto oficial. La lista debería revisarse cuando se publiquen nuevas ediciones, sin abandonar los controles derivados de riesgos que siguen siendo relevantes.
