Las APIs se han convertido en un estándar de facto en el mundo de IT, por ello debemos garantizar que esta puerta expuesta desde la Organización esta asegurada. El proyecto de seguridad de las API de OWASP busca proporcionar valor a los desarrolladores de software y a los evaluadores de seguridad, subrayando los riesgos potenciales de las API inseguras, e ilustrando cómo estos riesgos pueden ser mitigados. Para facilitar este objetivo, el Proyecto de Seguridad de API de OWASP creará y mantendrá un documento de los 10 principales riesgos de seguridad de API, así como un portal de documentación para las mejores prácticas al crear o evaluar APIs.

Asegurar cada dimensión

Autenticación

No te comuniques con extraños. Para aumentar la complejidad de la piratería de su dispositivo, conozca siempre quién llama a sus API, utilizando una simple autenticación de acceso (usuario/contraseña) o una clave de API (clave asimétrica).

OAuth y OpenID Connect

Delegue todas las responsabilidades. Un buen gerente asume la responsabilidad, y un fantástico API también lo hace. La autorización y/o autenticación de sus APIs debe ser delegada.

OAuth es un mecanismo mágico que evita que tengas que recordar 10.000 contraseñas. En lugar de crear una cuenta en un sitio web, puedes conectarte mediante credenciales de otro proveedor, como Facebook o Google. Esto funciona de la misma manera para las API: el proveedor de la API depende de un servidor de terceros para manejar los permisos. El usuario no proporciona sus credenciales pero luego le da un token al servidor de terceros. Esto protege al usuario porque no revela sus contraseñas, y el proveedor de la API no tiene que preocuparse de proteger los datos sobre la autorización, porque solo recoge tokens.

OAuth es un protocolo de delegación ampliamente utilizado para reenviar autorizaciones. Puedes añadir una capa de identidad encima para proteger aún más tus APIs y añadir autenticación: este es el estándar Open I d Connect que extiende OAuth 2.0 con tokens de identificación.

Auditabilidades: Monitorización, Registro o Logs y Versionado

En caso de un error, hay que estar preparado para solucionarlo: auditar y registrar la información relevante en el servidor. Además, mantenga ese historial mientras sea razonable en términos de capacidad para sus servidores en producción. En caso de cualquier accidente, puede convertir sus registros en herramientas de depuración. Los tableros de seguimiento también son recursos muy recomendables para supervisar el uso de la API.

No olvide añadir la versión a todas las API, idealmente en la dirección de la API, para dar varias API con diferentes versiones funcionando simultáneamente, y para poder borrar y depreciar una versión sobre otra.

Confidencialidad

Exponer lo mínimo posible

Para la seguridad de la API, está bien ser paranoico y mostrar muy poca información, sobre todo en los mensajes de error. Limite el contenido y los asuntos de los correos electrónicos a mensajes predefinidos no personalizables. Ya que puede enviar ubicaciones a las direcciones IP, guárdalas. Para limitar el acceso a las cuentas, utilice la lista blanca (preferiblemente) y la lista negra (una opción mejor que nada) de IP siempre que sea posible. También puede comprobar su dirección IP simplemente buscando cuál es mi IP y obtendrá los detalles. Limite el número de administradores, divida el acceso en diversos roles y oculte la información sensible en todas sus interfaces.

Cifrado

Solo sé críptico. Para la correspondencia interna o externa nada debe estar al descubierto.
Usted y sus socios pueden cifrar todas las transferencias TLS (el sucesor de SSL), ya sea un cifrado unidireccional (también llamado TLS estándar unidireccional) o incluso mejor, un cifrado compartido (TLS bidireccional).
Utilizando las nuevas versiones de TLS para bloquear el uso de las suites de cifrado más débiles.

Disponibilidad

Protección del sistema con limitaciones y cuotas

Mantén el control. Para proteger el ancho de banda de su red de backend según la capacidad de los servidores, puede restringir el acceso a su dispositivo a un número limitado de mensajes por segundo.

También puede limitar el acceso de la API y del usuario (o de la aplicación) para asegurarse de que nadie, en particular, pueda hacer un mal uso del programa o de cualquier API.

Los umbrales y cuotas de restricción - si están bien definidos - son esenciales para evitar que los ataques de diferentes fuentes abrumen la red con numerosas solicitudes (Ataque de denegación de servicio distribuido por DDOS).

Otras medidas (que implican varias dimensiones)

Validación de datos

Sé minucioso y rechaza lo que no cumpla el formato esperado. Debes verificar que tu servidor no acepte cualquier cosa. Hay que estar atento para rechazar cualquier contenido que se añada, datos que sean demasiado pesados, y también pruebe la información que le dan los clientes. Utilice la validación de esquemas XML o JSON para verificar si sus restricciones son las que deberían ser (enteros, cadenas, no permitir entidades externas...) para evitar todo tipo de explosión XML e inyección SQL.

Infraestructura

Mantente al día las versiones de todos los componentes. Para ser estable y seguir beneficiándose de las últimas actualizaciones de seguridad, una buena API debe contar con una buena red de seguridad, infraestructura y actualización.

OWASP top 10

Evita las vulnerabilidades más obvias. El top 10 del OWASP (Open Web Application Security Project) es una lista de las diez peores vulnerabilidades, medidas por su capacidad de explotación y efecto. Además de lo anterior, asegúrese de haber revisado todos los errores en OWASP para comprobar el programa.

Recomendamos que visite este enlace

https://owasp.org/www-project-api-security/