• Implement a proper authorization mechanism that relies on the user policies and hierarchy. • Use an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database. • Prefer to use random and unpredictable values as GUIDs for records’ IDs. • Write tests to evaluate the authorization mechanism. Do not deploy vulnerable changes that break the tests.
• Implementar un mecanismo de autorización adecuado que se base en las políticas y la jerarquía del usuario. • Use un mecanismo de autorización para verificar si el usuario que inició sesión tiene acceso para realizar la acción solicitada en el registro en cada función que usa una entrada del cliente para acceder a un registro en la base de datos. • Preferentemente utilizar valores aleatorios e impredecibles como GUID para los ID de los registros. • Escribir pruebas para evaluar el mecanismo de autorización. No implemente cambios vulnerables que rompan las pruebas.
API2:2019 Broken User Authentication
• Make sure you know all the possible flows to authenticate to the API (mobile/ web/deep links that implement one-click authentication/etc.) • Ask your engineers what flows you missed. • Read about your authentication mechanisms. Make sure you understand what and how they are used. OAuth is not authentication, and neither is API keys. • Don't reinvent the wheel in authentication, token generation, password storage. Use the standards. • Credential recovery/forget password endpoints should be treated as login endpoints in terms of brute force, rate limiting, and lockout protections. • Use the OWASP Authentication Cheatsheet. • Where possible, implement multi-factor authentication. • Implement anti brute force mechanisms to mitigate credential stuffing, dictionary attack, and brute force attacks on your authentication endpoints. This mechanism should be stricter than the regular rate limiting mechanism on your API. • Implement account lockout / captcha mechanism to prevent brute force against specific users. Implement weak-password checks. • API keys should not be used for user authentication, but for client app/project authentication.
• Asegúrese de conocer todos los flujos posibles para autenticarse en la API (enlaces móviles / web / profundos que implementan la autenticación con un solo clic / etc.) • Pregunte a sus ingenieros qué flujos se perdió. • Lea acerca de sus mecanismos de autenticación. Asegúrese de comprender qué y cómo se usan. OAuth no es autenticación, ni claves de API. • No reinvente la rueda en autenticación, generación de tokens, almacenamiento de contraseñas. Utilice los estándares. • Los puntos finales de recuperación de credenciales / olvido de contraseña deben tratarse como puntos finales de inicio de sesión en términos de fuerza bruta, limitación de velocidad y protecciones de bloqueo. • Utilice la hoja de trucos de autenticación de OWASP. • Siempre que sea posible, implemente la autenticación multifactor. • Implemente mecanismos de fuerza bruta para mitigar el relleno de credenciales, el ataque de diccionario y los ataques de fuerza bruta en sus puntos finales de autenticación. Este mecanismo debería ser más estricto que el mecanismo de limitación de velocidad habitual de su API. • Implementar un mecanismo de bloqueo / captcha de cuenta para evitar la fuerza bruta contra usuarios específicos. Implementar comprobaciones de contraseñas débiles. • Las claves de API no deben usarse para la autenticación de usuarios, sino para la autenticación de proyectos / aplicaciones cliente.
API3:2019 Excessive Data Exposure
• Never rely on the client side to filter sensitive data. • Review the responses from the API to make sure they contain only legitimate data. • Backend engineers should always ask themselves "who is the consumer of the data?" before exposing a new API endpoint. • Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific properties you really want to return. • Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls returning such information to see if these responses pose a security issue. • Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism define and enforce data returned by all API methods, including errors.
• Nunca confíe en el lado del cliente para filtrar datos confidenciales.
• Revise las respuestas de la API para asegurarse de que solo contengan datos legítimos. • Los ingenieros de backend siempre deben preguntarse "¿quién es el consumidor de los datos?" antes de exponer un nuevo punto final de API. • Evite el uso de métodos genéricos como to_json () y to_string (). En su lugar, elija las propiedades específicas que realmente desea devolver. • Clasifique la información confidencial y de identificación personal (PII) que su aplicación almacena y con la que trabaja, revisando todas las llamadas a la API que devuelven dicha información para ver si estas respuestas representan un problema de seguridad. • Implementar un mecanismo de validación de respuesta basado en esquemas como una capa adicional de seguridad. Como parte de este mecanismo, defina y aplique los datos devueltos por todos los métodos de API, incluidos los errores.
API4:2019 Lack of Resources & Rate Limiting
• Docker makes it easy to limit memory, CPU, number of restarts, file descriptors, and processes. • Implement a limit on how often a client can call the API within a defined timeframe. • Notify the client when the limit is exceeded by providing the limit number and the time at which the limit will be reset. • Add proper server-side validation for query string and request body parameters, specifically the one that controls the number of records to be returned in the response. • Define and enforce maximum size of data on all incoming parameters and payloads such as maximum length for strings and maximum number of elements in arrays
• Docker facilita la limitación de la memoria, la CPU, el número de reinicios, los descriptores de archivos y los procesos. • Implementar un límite sobre la frecuencia con la que un cliente puede llamar a la API dentro de un período de tiempo definido. • Notifique al cliente cuando se exceda el límite proporcionando el número de límite y la hora en que se restablecerá el límite. • Agregue la validación adecuada del lado del servidor para la cadena de consulta y los parámetros del cuerpo de la solicitud, específicamente el que controla el número de registros que se devolverán en la respuesta. • Defina y aplique el tamaño máximo de datos en todos los parámetros entrantes y cargas útiles, como la longitud máxima de las cadenas y el número máximo de elementos en las matrices
API5:2019 Broken Function Level Authorization
• The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function. • Review your API endpoints against function level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy. • Make sure that all of your administrative controllers inherit from an administrative abstract controller that implements authorization checks based on the user’s group/role. • Make sure that administrative functions inside a regular controller implements authorization checks based on the user’s group and role.
• El (los) mecanismo (s) de aplicación deben denegar todo acceso por defecto, requiriendo concesiones explícitas a roles específicos para acceder a cada función. • Revise los puntos finales de su API para detectar fallas de autorización de nivel de función, teniendo en cuenta la lógica comercial de la aplicación y la jerarquía de grupos. • Asegúrese de que todos sus controladores administrativos hereden de un controlador abstracto administrativo que implemente verificaciones de autorización basadas en el grupo / rol del usuario. • Asegúrese de que las funciones administrativas dentro de un controlador regular implementen verificaciones de autorización basadas en el grupo y el rol del usuario.
API6:2019 Mass Assignment
• If possible, avoid using functions that automatically bind a client’s input into code variables or internal objects. • Whitelist only the properties that should be updated by the client. • Use built-in features to blacklist properties that should not be accessed by clients. • If applicable, explicitly define and enforce schemas for the input data payloads.
• Si es posible, evite el uso de funciones que enlacen automáticamente la entrada de un cliente en variables de código u objetos internos. • Incluya en la lista blanca solo las propiedades que el cliente debe actualizar. • Utilice funciones integradas para incluir en la lista negra las propiedades a las que los clientes no deben acceder. • Si corresponde, defina y aplique explícitamente esquemas para las cargas útiles de datos de entrada.
API7:2019 Security Misconfiguration
• A repeatable hardening process leading to fast and easy deployment of a properly locked down environment. • A task to review and update configurations across the entire API stack. The review should include: orchestration files, API components, and cloud services (e.g., S3 bucket permissions). • A secure communication channel for all API interactions access to static assets (e.g., images). • An automated process to continuously assess the effectiveness of the configuration and settings in all environments.
• Un proceso de endurecimiento repetible que conduce a una implementación rápida y sencilla de un entorno correctamente bloqueado. • Una tarea para revisar y actualizar configuraciones en toda la pila de API. La revisión debe incluir: archivos de orquestación, componentes de API y servicios en la nube (por ejemplo, permisos de bucket de S3). • Un canal de comunicación seguro para todas las interacciones de API, acceso a activos estáticos (por ejemplo, imágenes). • Un proceso automatizado para evaluar continuamente la efectividad de la configuración y los ajustes en todos los entornos.
API8:2019 Injection • Perform data validation using a single, trustworthy, and actively maintained library. • Validate, filter, and sanitize all client-provided data, or other data coming from integrated systems. • Special characters should be escaped using the specific syntax for the target interpreter. • Prefer a safe API that provides a parameterized interface. • Always limit the number of returned records to prevent mass disclosure in case of injection. • Validate incoming data using sufficient filters to only allow valid values for each input parameter. • Define data types and strict patterns for all string parameters.
• Realice la validación de datos utilizando una biblioteca única, confiable y mantenida activamente. • Validar, filtrar y desinfectar todos los datos proporcionados por el cliente u otros datos provenientes de sistemas integrados. • Los caracteres especiales deben escaparse utilizando la sintaxis específica del intérprete de destino. • Prefiera una API segura que proporcione una interfaz parametrizada. • Limite siempre el número de registros devueltos para evitar la divulgación masiva en caso de inyección. • Valide los datos entrantes utilizando filtros suficientes para permitir solo valores válidos para cada parámetro de entrada. • Defina tipos de datos y patrones estrictos para todos los parámetros de cadena.
API9:2019 Improper Assets Management
• Inventory all API hosts and document important aspects of each one of them, focusing on the API environment (e.g., production, staging, test, development), who should have network access to the host (e.g., public, internal, partners) and the API version. • Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and its sensitivity. • Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy and endpoints, including their parameters, requests, and responses. • Generate documentation automatically by adopting open standards. Include the documentation build in your CI/CD pipeline. • Make API documentation available to those authorized to use the API. • Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version. • Avoid using production data with non-production API deployments. If this is unavoidable, these endpoints should get the same security treatment as the production ones. • When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatib
• Hacer un inventario de todos los hosts de API y documentar los aspectos importantes de cada uno de ellos, centrándose en el entorno de API (por ejemplo, producción, preparación, prueba, desarrollo), quién debe tener acceso de red al host (por ejemplo, público, interno, socios) y la versión de API. • Hacer un inventario de los servicios integrados y documentar aspectos importantes como su función en el sistema, qué datos se intercambian (flujo de datos) y su sensibilidad. • Documente todos los aspectos de su API, como autenticación, errores, redireccionamientos, limitación de velocidad, política de intercambio de recursos de origen cruzado (CORS) y puntos finales, incluidos sus parámetros, solicitudes y respuestas. • Genere documentación automáticamente mediante la adopción de estándares abiertos. Incluya la compilación de documentación en su canalización de CI / CD. • Poner la documentación de la API a disposición de las personas autorizadas a utilizar la API. • Utilice medidas de protección externas como firewalls de seguridad API para todas las versiones expuestas de sus API, no solo para la versión de producción actual. • Evite el uso de datos de producción con implementaciones de API que no sean de producción. Si esto es inevitable, estos puntos finales deben recibir el mismo tratamiento de seguridad que los de producción. • Cuando las versiones más nuevas de las API incluyen mejoras de seguridad, realice un análisis de riesgo para tomar la decisión de las acciones de mitigación necesarias para la versión anterior: por ejemplo, si es posible respaldar las mejoras sin romper la compatibilidad de la API.
API10:2019 Insufficient Logging & Monitoring
• Log all failed authentication attempts, denied access, and input validation errors. • Logs should be written using a format suited to be consumed by a log management solution, and should include enough detail to identify the malicious actor. • Logs should be handled as sensitive data, and their integrity should be guaranteed at rest and transit. • Configure a monitoring system to continuously monitor the infrastructure, network, and the API functioning. • Use a Security Information and Event Management (SIEM) system to aggregate and manage logs from all components of the API stack and hosts. • Configure custom dashboards and alerts, enabling suspicious activities to be detected and responded to earlier.
• Registre todos los intentos fallidos de autenticación, acceso denegado y errores de validación de entrada. • Los registros deben escribirse en un formato adecuado para ser consumidos por una solución de administración de registros y deben incluir suficientes detalles para identificar al actor malintencionado. • Los registros deben manejarse como datos sensibles y su integridad debe garantizarse en reposo y tránsito. • Configurar un sistema de monitoreo para monitorear continuamente la infraestructura, la red y el funcionamiento de la API. • Utilice un sistema de administración de eventos e información de seguridad (SIEM) para agregar y administrar registros de todos los componentes de la pila de API y los hosts. • Configure paneles de control y alertas personalizados, permitiendo que las actividades sospechosas sean detectadas y respondidas antes.
