En la era moderna, las API REST se convirtieron en una parte integral de las aplicaciones. Al adoptar las API REST, puede exponer sus servicios a aplicaciones web o aplicaciones móviles y todas las demás plataformas digitales.
Las API REST deben construirse como un servicio sin estado. Las mejores prácticas de API REST merecen un artículo seperado. Este artículo se centra principalmente en las mejores prácticas de seguridad para las API REST.
A continuación se presentan los conceptos claves que se deben considerar al diseñar las API REST.
- Autenticación/Autorización
- Validación de ingresos
- Definir tipos de contenido
- Codificación de la salida
- Seguridad para datos en tránsito y almacenamiento
- Responder con los códigos de estado apropiados para evitar la ambiguedad.
Antes de profundizar en los detalles, primero comprendamos la autenticación y la autorización.
- Autenticación: La autenticación es el proceso de identificar si las credenciales pasadas juntos con la solicitud son válidas o no, aquí las credenciales se pueden pasar como ID de usuario y contraseña on un token asignado para la sesión de usuario.
- Autorización: La autorización es el proceso de identificar si la solicitud recibida puede acceder al punto final o método solicitado.
En la canalización del procesamiento de solicitudes, la autenticación viene primero y la autorización después. La autorización se produce solo después de la autenticación exitosa de la solicitud.
A continuación se muestran los tipos de autenticación más utilizados cuando se trata de API remotas (API REST / Servicios web).
La autenticación básica es la forma más sencilla de tratar con la autenticación en comparación con otras metodologías.
En la autenticación básica, el usuario debe enviar el ID del usuario y la contraseña en el formato userid:password codificado en formato base64. Este método se puede seleccionar sobre el protocolo https. No se aconseja utilizarlo sobre el protocolo HTTP, ya que las credenciales se transferirian en formato plano.
1 | Authorization: Basic base64(userid:password) |
La autenticación de token del portador también se conoce como autenticación basada en Token. Cuando el usuario inicia sesión en una aplicación utilizando las credenciales, el servidor de Autorización genera un token criptográfico para identificar al usuario de forma exclusiva. Las aplicaciones pueden usar el token para identificar al usuario después de un inicio de sesión exitoso, es decir, la aplicación debe enviar ese token al acceder a recursos protegidos.
1 | Authorization Bearer |
Los tokens API se usan ampliamente en la seguridad de los servicios web / API REST antes de la evaluación de los frameworks del lado del cliente. Aún así, muchas organizaciones usan los tokens API como medida de seguridad para las API. Esta es la forma más sencilla de implementar la seguridad en las API REST.
Esto se recomienda al proporcionar la comunicación entre las solicitudes de servidor a servidor. Se recomienda usar el registro de la dirección IP también cuando se usan las claves API, es decir, el token API se identifica de forma exclusiva junto con la dirección IP. No se recomienda su uso como metodología para la autenticación y autorización del usuario final.
La clave de API se puede enviar como parte de la cadena de consulta o token de autorización o encabezado personalizado o como parte de los datos .
OAuth2.0 es un framework de autorización que permite a los usuarios otorgar un sitio web o aplicación de terceros para acceder a los recursos protegidos del usuario sin revelar sus credenciales o identidad. Para ese fin, un servidor OAuth 2.0 emite tokens de acceso que las aplicaciones cliente pueden usar para acceder a recursos protegidos en nombre del propietario del recurso.
Probablemente vea esta opción en forma de ‘Iniciar sesión con Google’, ‘Iniciar sesión con Facebook’, ‘Iniciar sesión con Github’, etc.
Por defecto, OAuth genera los tokens de acceso en el formato de JWT (tokens web JSON). Los JWT contienen tres partes: un encabezado, una carga útil y una firma.
- Encabezado: metadatos sobre el token como algoritmos criptográficos utilizados para generar el token.
- Payload: la carga útil contiene el Asunto (generalmente identificador del usuario), claims (también conocidos como permisos o concesiones) y otra información como audiencia y tiempo de vencimiento, etc.
- Firma: utilizada para validar el token es confiable y no ha sido alterado.
A continuación se muestran los roles de OAuth que debe tener en cuenta al tratar con OAuth2.0
- Propietario del recurso : la entidad que puede otorgar acceso a un recurso protegido. Por lo general, este es el usuario final.
- Servidor de recursos: el servidor que aloja los recursos protegidos
- Cliente: la aplicación que solicita acceso a un recurso protegido en nombre del propietario del recurso.
- Servidor de autorización: el servidor que autentica al propietario del recurso y emite tokens de acceso después de obtener la autorización adecuada.
OAuth2.0 proporciona varios flujos o tipos de concesión adecuados para diferentes tipos de clientes API.
OIDC es una capa de identidad simple construida sobre OAuth2.0. OIDC define un flujo de inicio de sesión que permite que una aplicación cliente autentique a un usuario y obtenga información sobre ese usuario, como el nombre de usuario, correo electrónico, etc. La información de identidad del usuario está codificada en un token web JSON (JWT) seguro, denominado token de identificación.
Validación de Entrada
La validación de entrada se debe aplicar a los niveles sintáctico y semántico .
- Sintáctico: debe aplicar la sintaxis correcta de los campos estructurados (por ejemplo, SSN, fecha, símbolo de moneda).
- Semántico: debe exigir la corrección de sus valores en el contexto comercial específico (por ejemplo, la fecha de inicio es anterior a la fecha de finalización, el precio está dentro del rango esperado).
Pautas básicas de validación de entrada
- Defina una validación de entrada implícita utilizando tipos fuertes como números, booleanos, fechas, horas o rangos de datos fijos en los parámetros de la API.
- Restrinja las entradas de cadena con expresiones regulares.
- Use técnicas de listas blancas y listas negras
- Definir longitudes mínimas y máximas como obligatorio
Aplicar validaciones de entrada en el lado del cliente y del lado del servidor - Rechazar contenido inesperado / ilegal con mensajes de error válidos
Debemos definir los tipos de contenido permitidos explícitamente. Siempre es una buena práctica definir los tipos de contenido válidos y compartirlos con los accionistas requeridos. Al recibir un encabezado de tipo de contenido inesperado o faltante, la API debe responder con el estado de respuesta HTTP 406 Unacceptable o 415 Unsupported Media Type.
El contenido de los recursos dados debe ser interpretado correctamente por el navegador, el servidor siempre debe enviar el encabezado Content-Type con el Content-Type correcto, y preferiblemente el encabezado Content-Type debe incluir un juego de caracteres.
Los codificadores JSON deben usarse cuando se trata con datos JSON.
Limitadores de Velocidad
Los limitadores de velocidad le permiten proteger sus API de los ataques DDoS. Al exponer públicamente su API, debe definir los limitadores de velocidad. Si opta por las herramientas de un proveedor de la nube, estas proporcionan explícitamente las capacidades de limitación de velocidad a los recursos públicos. debe ajustar las configuraciones de acuerdo a sus necesidades.
Asegúrese de que los datos se envíen solo a través de HTTPS. Si algún usuario intenta acceder a través de HTTP, debe actualizarlo HTTPS y manejar la solicitud
Los datos almacenados deben protegerse utilizando las mejores prácticas de seguridad. Todos los proveedores de la nube le proporcionan la seguridad incorporada (cifrado) para sus copias de seguridad.
A continuación se muestran algunos códigos de estado comunes utilizados junto con las API REST.
- 201 – Creado
- 200 – OK
- 202 – Aceptado y en cola para procesamiento
- 204 – Sin contenido
- 304 – No modificado
- 400 Petición Incorrecta
- 401 – No autorizado
- 403 – Prohibido
- 404 No encontrado
- 405 – Método no permitido
- 406 – No aceptable (utilizado con tipos de contenido)
- 415 – Tipo de medio no compatible
- 429 – Dos muchas solicitudes
Si encuentra útil el artículo, compártalo.
El artículo se encuentra basado en Security Best Practices for REST APIs.
