¿Cómo asegurarías una API REST expuesta públicamente?
Respuesta breve
Forzar TLS en todas partes, autenticar cada solicitud (p. ej. tokens OAuth2/OIDC) y autorizar por objeto para que los usuarios solo alcancen sus propios datos. Añade validación de entradas, limitación de tasa y cuotas, validación de esquema y registro exhaustivo. El fallo de API más común es la autorización a nivel de objeto rota, así que comprueba la propiedad en cada acceso a un recurso.
Asegurar una API consiste en controlar quién puede llamarla, qué pueden hacer y qué pueden enviar — en cada solicitud, porque una API es sin estado y cada solicitud debe sostenerse por sí misma.
Autenticación vs autorización
Son distintas y ambas necesarias. La autenticación demuestra quién es el llamante — normalmente un token bearer de corta duración de OAuth2/OIDC, validado en cada solicitud (firma, expiración, audiencia). La autorización decide qué puede hacer ese llamante autenticado. El fallo de API más común y dañino es la autorización a nivel de objeto rota (BOLA/IDOR): el código autentica al usuario pero luego devuelve el objeto /orders/123 sin comprobar que el pedido 123 realmente le pertenece. Verifica siempre la propiedad del recurso específico, no solo que alguien haya iniciado sesión.
Transporte y entradas
- TLS en todas partes — nunca aceptes texto plano, y no pongas secretos o tokens en query strings donde acaban en los registros.
- Valida y restringe las entradas del lado del servidor contra un esquema estricto; rechaza campos inesperados y cargas útiles sobredimensionadas. Nunca confíes en la validación del lado del cliente.
- Parametriza las consultas y codifica la salida para bloquear inyecciones.
Abuso y visibilidad
- La limitación de tasa y las cuotas protegen contra la fuerza bruta, el scraping y la denegación de servicio; ajústalas de forma distinta para llamantes autenticados vs anónimos.
- El registro y la monitorización de fallos de autenticación y patrones de acceso anómalos permiten detectar ataques en curso.
- Minimiza la exposición de datos — devuelve solo los campos que el cliente necesita, para que la API no filtre datos internos mediante respuestas demasiado amplias.
Qué buscan los entrevistadores
Los candidatos que solo dicen «usar claves de API» se pierden lo esencial. La buena respuesta separa la autenticación de la autorización, señala los controles de acceso a nivel de objeto (BOLA/IDOR) como el principal riesgo del mundo real, y lo completa con TLS, validación de entradas y limitación de tasa.
Posibles preguntas de seguimiento
- ¿Qué es BOLA / IDOR y cómo se previene?
- ¿Por qué es mala idea poner una clave de API en una query string?
- ¿Cómo manejarías la limitación de tasa para usuarios autenticados vs anónimos?