OWASP API Security Top 10: lista de verificación con correcciones

API4:2023 Consumo de recursos sin restricciones

Las API que aceptan solicitudes ilimitadas permiten a los atacantes aumentar su factura de infraestructura y agotar la base de datos. conexiones o desencadenar una denegación de servicio. Esto se aplica a los límites de tasas faltantes y a las consultas ilimitadas. parámetros (por ejemplo, ?limit=1000000), cargas de archivos sin límite de tamaño y puntos finales que desencadenar costosos trabajos en segundo plano.

Escenario de ataque: Un punto final API genera informes en PDF. Un atacante envía 500 solicitudes simultáneas, cada una de las cuales solicita un informe de 200 páginas. Su grupo de trabajadores se está llenando y es legítimo los usuarios reciben errores 503 durante los próximos 20 minutos.

Arreglar: Agregue limitación de velocidad por usuario y por IP. Limitar los límites de paginación con el lado del servidor máximos. Establezca límites de tamaño de carga de archivos. Utilice el procesamiento basado en colas para operaciones costosas.

// Express rate limiter per user
import rateLimit from "express-rate-limit";

const apiLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 30,             // 30 requests per minute per IP
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: "Rate limit exceeded. Try again in 60 seconds." },
});

app.use("/api/", apiLimiter);

API5:2023 Autorización de nivel de función rota

Las fallas de autorización a nivel de función permiten a los usuarios habituales llamar a los puntos finales de administración. El patrón típico: un llamadas al panel de administración DELETE /api/admin/users/:id. La interfaz oculta el botón de usuarios que no son administradores, pero el punto final de la API en sí no verifica los roles. Cualquier usuario autenticado que descubre la URL puede eliminar cuentas.

Escenario de ataque: Un desarrollador encuentra /api/admin/export-all-users en el paquete de JavaScript. Lo llaman con su token de usuario habitual y descargan el usuario completo. base de datos.

Arreglar: Verifique la función del usuario en la capa API para cada punto final de administrador. No confíes en la interfaz para ocultar la funcionalidad. El administrador del grupo enruta detrás del middleware que verifica role === "admin" antes de procesar la solicitud.

API6:2023 Acceso sin restricciones a flujos comerciales sensibles

Algunos flujos de API son peligrosos a escala incluso cuando cada solicitud individual está autorizada. Comprando artículos de inventario limitado, creación de cuentas de prueba gratuitas, envío de códigos de referencia; estos flujos se rompe cuando está automatizado. Un bot registra 10.000 cuentas gratuitas o compra todos los boletos en una venta flash antes de que un usuario real cargue la página.

Escenario de ataque: Un revendedor de zapatillas escribe un bot que llama POST /api/checkout 500 veces en el primer segundo de una caída limitada. Cada par se vende a los robots. Los clientes humanos ven "agotado" antes de que la página termine de cargarse.

Arreglar: Agregue CAPTCHA o desafíos de prueba de trabajo a flujos de alto valor. Dispositivo de seguimiento Huellas dactilares para detectar automatización. Establece límites de compra por usuario. Utilice el acceso basado en colas para ventas flash en lugar de puntos finales por orden de llegada.

API7:2023 Falsificación de solicitudes del lado del servidor (SSRF)

SSRF ocurre cuando una API acepta una URL del cliente y la recupera del lado del servidor sin validando el objetivo. Un atacante proporciona http://169.254.169.254/latest/meta-data/ y su servidor devuelve las credenciales de la instancia de AWS. O apuntan http://localhost:6379/ e interactuar con su instancia de Redis.

Escenario de ataque: Una integración de webhook permite a los usuarios especificar una URL de devolución de llamada. Un atacante establece la devolución de llamada en http://169.254.169.254/latest/meta-data/iam/security-credentials/ y recibe las credenciales de la función IAM de su proveedor de nube en la carga útil del webhook.

// Block internal network requests
const BLOCKED_RANGES = [
  /^10\\./, /^172\\.(1[6-9]|2\\d|3[01])\\./, /^192\\.168\\./,
  /^127\\./, /^0\\./, /^169\\.254\\./,
  /^localhost$/i, /^\\[::1\\]$/,
];

function isSafeUrl(urlString) {
  try {
    const url = new URL(urlString);
    const hostname = url.hostname;
    return !BLOCKED_RANGES.some((re) => re.test(hostname));
  } catch {
    return false;
  }
}

app.post("/api/fetch-url", async (req, res) => {
  const { url } = req.body;
  if (!isSafeUrl(url)) {
    return res.status(400).json({ error: "URL targets a blocked network range" });
  }
  // proceed with external fetch
});

Arreglar: Validar y incluir en la lista de direcciones URL de destino permitidas. Bloquear rangos de IP privados y nube puntos finales de metadatos. Resuelva DNS antes de realizar la solicitud para evitar que se vuelva a vincular DNS. correr hacia afuera solicitudes de un segmento de red aislado.

API8:2023 Mala configuración de seguridad

La mala configuración es la categoría de riesgo más amplia. Incluye restricciones CORS faltantes, error detallado mensajes que filtran rastros de pila, credenciales predeterminadas en los paneles de administración, métodos HTTP innecesarios habilitados, TLS no se aplica y faltan encabezados de seguridad. Cualquier mala configuración crea un punto de entrada.

Escenario de ataque: Una API devuelve seguimientos completos de la pila en respuestas de error de producción. un El atacante desencadena errores a propósito, lee los seguimientos de la pila, identifica el ORM y la versión de la base de datos. luego crea una carga útil de inyección basada en las vulnerabilidades conocidas en esa versión.

Arreglar: Elimine los rastros de la pila de las respuestas de producción. Configure CORS para permitir solo sus dominios. Deshabilite los métodos HTTP que no utilice. Aplique TLS en todas partes. Ejecute comprobaciones automáticas de encabezados de seguridad. Desinfecte toda la salida HTML para evitar XSS.

La API de desinfección HTML publicada tiras etiquetas y atributos maliciosos de HTML proporcionado por el usuario:

curl -s -X POST https://api.botoi.com/v1/html-sanitize \\
  -H "Content-Type: application/json" \\
  -d '{
    "html": "<p>Hello</p><script>document.cookie</script><img onerror=alert(1) src=x>"
  }'

Respuesta:

{
  "success": true,
  "data": {
    "sanitized": "<p>Hello</p><img src=\\"x\\">"
  }
}

La <script> etiqueta y el onerror Se eliminan los atributos. El HTML seguro es devuelto. Llame a este punto final antes de almacenar o representar cualquier HTML proporcionado por el usuario.

API9:2023 Gestión inadecuada del inventario

Las versiones antiguas de API, los puntos finales de preparación olvidados y las rutas no documentadas crean una superficie de ataque para usted. no monitorear. Los atacantes buscan /v1/, /v2/, /api-dev/, y /internal/ caminos. Encuentran un punto final obsoleto que carece de controles de seguridad que agregaste a la versión actual.

Escenario de ataque: Tu equipo enviado /v2/users con acceso basado en roles controlar. Pero /v1/users todavía funciona en producción sin ninguna autorización. un atacante descubre la ruta v1 a través de un archivo Swagger público y extrae toda la tabla de usuarios.

Arreglar: Mantener un inventario API completo. Desmantelar versiones antiguas; no los dejes ejecutando "por si alguien todavía los usa". Controle cada versión detrás del mismo middleware de autenticación. Escanear su propia infraestructura para caminos expuestos en un horario regular.

API10:2023 Consumo inseguro de API

Su API llama a servicios de terceros: procesadores de pagos, proveedores de correo electrónico, API de codificación geográfica. si tu Confíe en sus respuestas sin validación, un tercero comprometido o malicioso puede inyectar datos. en su sistema. Esto incluye confiar en las URL de redireccionamiento, analizar JSON no validados o almacenar respuestas de terceros sin higienización.

Escenario de ataque: Su aplicación obtiene datos de la empresa de una API de enriquecimiento de terceros y almacena el company_name campo directamente en su base de datos. La API de enriquecimiento obtiene comprometido y el atacante inyecta <script> etiquetas en nombres de empresas. cada El usuario que ve el perfil de una empresa en su panel ejecuta el script.

Arreglar: Validar y desinfectar todas las respuestas de terceros antes de almacenarlas o renderizarlas. ellos. Utilice la validación de esquema en los datos entrantes. Establecer tiempos de espera en llamadas externas. Aplicar la misma entrada validación de datos de terceros que usted aplica a la entrada del usuario.

Detecte la exposición de datos confidenciales en sus respuestas API

Los riesgos API1 y API3 a menudo resultan en que datos confidenciales abandonen su API. El API de detección de PII de botoi escanea texto para Números de seguro social, números de tarjetas de crédito, direcciones de correo electrónico, números de teléfono, direcciones IP y fechas de nacimiento. Ejecútelo en los cuerpos de respuesta de su API en pruebas de integración para detectar accidentes. fugas de datos antes de la implementación.

curl -s -X POST https://api.botoi.com/v1/pii/detect \\
  -H "Content-Type: application/json" \\
  -d '{
    "text": "Customer SSN is 123-45-6789 and card is 4111111111111111"
  }'

Respuesta:

{
  "success": true,
  "data": {
    "found": true,
    "count": 2,
    "findings": [
      {
        "type": "ssn",
        "value": "123-45-6789",
        "start": 17,
        "end": 28,
        "masked": "***-**-6789"
      },
      {
        "type": "credit_card",
        "value": "4111111111111111",
        "start": 42,
        "end": 58,
        "masked": "************1111"
      }
    ]
  }
}

Si la respuesta de su API genera hallazgos, su punto final está devolviendo datos que el cliente no debería ver. Corrija la consulta o DTO para excluir esos campos.

Cifrar datos confidenciales en reposo

Cuando su API almacene configuraciones, tokens o credenciales confidenciales, cifrelos antes de escribir a la base de datos. El API de cifrado botoi proporciona cifrado AES-256-CBC:

curl -s -X POST https://api.botoi.com/v1/encrypt/encrypt \\
  -H "Content-Type: application/json" \\
  -d '{
    "text": "sensitive-api-token-abc123",
    "password": "your-secret-key"
  }'

Respuesta:

{
  "success": true,
  "data": {
    "encrypted": "U2FsdGVkX1+abc...encrypted_output_here",
    "algorithm": "aes-256-cbc"
  }
}

Almacene la salida cifrada. Descifrar con /v1/encrypt/decrypt sólo cuando el valor es necesario. Esto limita el radio de explosión si un atacante obtiene acceso de lectura a su base de datos a través de un Vulnerabilidad de inyección BOLA o SQL.

La lista de verificación de los 10 principales aspectos de seguridad de API de OWASP

Imprima esta tabla o agréguela a su plantilla de revisión de seguridad. Verifique cada elemento antes de cualquier lanzamiento de API.

A dónde ir desde aquí

La documentación completa de OWASP API Security Top 10 se encuentra en owasp.org/API-Security. Cada página de riesgo incluye métodos de detección, ejemplos de escenarios de ataque y referencias a CWE.

Para verificaciones automatizadas, integre los puntos finales de botoi anteriores en su canal de CI. Ejecutar detección de PII contra accesorios de respuesta API. Desinfecta el HTML almacenado al escribir. Verifique los correos electrónicos de nuevos usuarios contra violaciones bases de datos durante el registro. Estas son pequeñas adiciones a su conjunto de pruebas que detectan los escáneres de riesgos. señorita.