Cómo mejorar la seguridad de tu API 
Tags: security, api, node, spanish
Published: 2021-08-06 15:47:14

## Como mejorar la seguridad de tu API ##

Existen en el mercado muchísimas herramientas que te ayudan a incrementar la seguridad de tu API, comenzando a bajo nivel mediante la revisión de vulnerabilidades de las librerías que emplea tu framework de desarrollo favorito hasta simulaciones de intentos de romper la API una vez publicada. 

Hoy nos centraremos en estas últimas pero empleandolas en las primeras fases del desarrollo. 

![Stackhawk Logo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dhalpg076cructhohdeg.png)

Usaremos [**stackhack**](https://stackhawk.com) , un servicio cloud que nos permite escanear nuestra API mediante fuerza bruta para identificar ciertas vulnerabilidades que podrían ser aprovechadas por un atacante que cuando la API esté publicada y expuesta al público.

## Accediendo al servicio 

Darse de alta en stackhawk.com es muy sencillo y en pocos minutos nos habrá proporcionado una cuenta para desarrolladores con 15 días de prueba. 
Es importante que en el proceso de registro y mientras seguimos la guía guardemos el token de acceso que nos proporciona en un lugar seguro y además lo añadamos al fichero de configuración según los pasos que se indica. 

Ya en el último paso nos indicará que descarguemos una plantilla del fichero de configuración.

## Cómo funciona stackhawk

El funcionamiento es bien sencillo , pero no exento de cumplir unas mínimas reglas. 

Dispondremos en su página web de un espacio de trabajo donde se representarán los "entornos" y se asociarán los resultados de las revisiones de nuestra aplicación. 

Las revisiones se ejecutarán en nuestro equipo local mediante un contenedor de docker, por ello es importante que tengamos -docker- funcionando correctamente en nuestro equipo. En todo momento la url donde se encuentre publicada la API debe ser accesible desde nuestro equipo, en nuestro caso la API corre en *http://localhost:3000* , por lo que no habrá ningún problema.

Cada vez que revisamos la API desde la línea de comando recibiremos un informe y este será remitido al espacio de trabajo de __stackhawk__ por lo que podremos consultar los distintos informes y ver cómo afectan los cambios incorporados.

## Por dónde comenzamos ##

El primer punto es configurar mediante la plantilla unos parámetros mínimos. 

```yaml
app:
  applicationId: XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX # (required)
  env: Development # (required)
  host: 'http://localhost:3000/'
  api: './openapi.json'
```

Habremos recibido una applicationId que representa la aplicación que vamos a testear. Podemos obtener uno desde el espacio de trabajo al pulsar sobre "Add an APP" aunque por estar en la versión demo solo podremos tener una aplicación.

Es importante indicar un entorno, ya que todas las ejecuciones se agrupan por este campo. 

Indicaremos el **host** , sin indicar la ruta a la API, pero si el puerto. 
(*) Recordar en todo momento emplear las comillas simples de lo contrario obtendréis un mensaje como este:

```shell
Error: HawkScan is unable to continue.
Please check the target host configuration -
		host: "http://localhost:3000/",
Be sure to include any additional host paths with their respected keys.
(e.g. `loginPath` or `schemaPath`) 
```
Ahora quizás lo más complicado es que debemos disponer de la especificación **openapi** o **swagger** de nuestra API en formato .json o .yaml 

Y debemos revisar que los recursos se correspondan con el uri completo. 
En mi ejemplo la api se encuentra en __/api__ , y el recurso es __/qrisk2__ , por ello en la definición de la api se modificar por :
```yaml
    "paths": {
        "/api/qrisk2": {
            "get": {
                "responses": {
                    "200": {
```

## Arrancamos  

Bien con esto preparado es el momento de recibir nuestro primer resultado, para ello ejecutamos el contenedor con la siguiente línea de comandos:

```shell
$ source ~/.hawk/hawk.rc ; \
docker run -e API_KEY=${HAWK_API_KEY} --rm -v $(pwd):/hawk:rw \
-it stackhawk/hawkscan:latest
```
La primera vez que ejecutemos tardará un momento en descargar la imagen y una vez que comience la ejecución nos aparecerá algo similar a ...

{% asciinema 429282 %}

Bien , ya tenemos nuestro primer informe. Veamos que podemos mejorar.

Al acceder al espacio de trabajo vemos nuestro entorno ![Environment in StackHawk](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/he7bul6v4xloropnlhse.png)
 
Si pulsamos sobre el símbolo __" &#8942; "__ , podemos seleccionar __View Scans__ . 

![Lastest Scans](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9pwu9vdxu8li7zjleiln.png)
Vemos al última ejecución y nos encontramos con **6** incidencias de importancia media y otras **6** de carácter __Low__ , si las revisamos nos damos cuenta pronto que en realidad una la podemos descartar porque hace referencia a que NO disponemos de un endpoint accessible mediante __https__ , lógico estamos en local. 

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m3u9a3emni637mszspgr.png)


## Como eliminar la primera incidencia de seguridad ##

Veamos otro de los aspectos que debemos revisar en nuestro desarrollo, nos centraremos en los de nivel __Low__ , vemos que las **6** hacen referencia al mismo problema en diferentes rutas. 

Esta indica que mediante el uso de la cabecera "X-Powered-By" un atacante puede identificar el framework que emplea nuestra API y puede focalizar el ataque en el o identificar una vulnerabilidad de último día que pueda afectarla. En este caso lo que debemos hacer es no aportar esta información. 

Mi API usa [Node.js]( https://nodejs.org/es/) y [Express](https://expressjs.com/es/) , por lo que para solventar este inconveniente puedo apoyarme en un módulo que me facilitará mucho el trabajo , llamado [**helmet**]( https://helmetjs.github.io/). 

Lo instalamos en el proyecto. 
```shell
npm install helmet
```

He iremos a la sección de nuestro código donde configuramos el servidor express, importamos el módulo y hacemos uso de él.

```javascript
const helmet = require('helmet');

// Hide the X-Powered-By header
server.use(helmet.hidePoweredBy());
```

Y voilá... 
Arrancamos de nuevo nuestra api y lanzamos de nuevo el scanner desde la línea de comando.

Volvemos al espacio de trabajo y podremos observar que ya no aparecen los **6** fallos de tipo __Low__ 

![Scanned](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/act1aiuzv41y4tjm6khv.png)

## Conclusiones ##

Una herramienta de estas características nos permitirá revisar que mantenemos en nuestro desarrollo un cierto nivel de control sobre la seguridad. Con el tiempo y solventando las incidencias iremos incorporando de forma continua a nuestras aplicaciones __buenas prácticas__ que eviten exponer información comprometida a terceros o que facilite el acceso no autorizado a nuestros servicios.

Evidentemente, nunca podremos estar 100% seguros pero es un paso en la buena dirección.

La plataforma de [**stackhack**](https://stackhawk.com) permite la integración con la mayoría de soluciones de gestión de código y de despliegue, de modo que podemos validar nuestra API antes de publicarla e incluso modificando el fichero de configuración cuando esta esté publicada en su URL final.