AfterPack
Ver como Markdown

Una clave de API que tienes que publicar en el navegador

Restríngela, ponla detrás de un proxy, rótala y después ofusca lo que quede. Qué aporta realmente codificar una credencial en tu bundle y dónde se queda corto.

A veces una clave o un token tiene que estar en el bundle del cliente porque el navegador hace la llamada directamente. La ofuscación cambia una parte de ese problema y no el resto.

A una clave legible la encuentran los bots, no las personas

Una clave que está en el JavaScript publicado como texto legible está a un grep de distancia de cualquiera que la busque. Los escáneres de secretos que rastrean la web la encuentran sin que una persona llegue a abrir tu sitio, y ese descubrimiento automatizado es un camino habitual desde una clave publicada hasta una clave explotada.

Nadie tiene que interesarse por tu producto para que esto ocurra. Un bot revisa cada bundle público al que puede llegar en busca de una cadena con forma de credencial, y el tuyo está en la cola con los demás.

Qué aporta codificar la clave y dónde se queda corto

strings.encode está activado con cualquier objetivo de complexity positivo, así que los literales de cadena de tu código fuente se codifican en la salida en lugar de publicarse como texto. Un escáner que busca con grep cadenas con forma de credencial en el bundle no encuentra la clave de esa manera.

Merece la pena tenerlo, y es todo lo que es. La ofuscación oculta cómo se usa un valor. No oculta el valor: cualquier cosa que el navegador necesite para ejecutar tu código se puede alcanzar ejecutando ese código. Una clave sellada no es una clave segura.

Restringe, usa un proxy, rota y después ofusca

Haz estas cuatro cosas, en orden, y trata la ofuscación como la última:

  1. Restringe la clave en el proveedor al alcance, los orígenes y la cuota más estrechos que ofrezca.
  2. Traslada la autoridad detrás de tu propio endpoint, para que el navegador nunca tenga la credencial real.
  3. Rota la clave que ya se publicó. Da por hecho que está comprometida desde el momento en que salió.
  4. Ofusca lo que de verdad no pueda trasladarse al servidor.

Para ese último paso, el build por defecto ya la codifica. Para establecer una barrera de build en CI:

{
  "strings": {
    "leaks": {
      "max": 0
    }
  }
}

Una directiva eleva un valor por encima del resto del programa, en builds Pro.

const apiKey = /* @afterpack preset=extreme */ "YOUR_SECRET";

Haz fallar el build si sobrevive un literal

--strings.leaks.max=0 hace fallar el build en cuanto sobrevive un literal legible, indicando DIAG_SURVIVING_READABLE_LITERAL. Intégralo en la CI para que no sea una comprobación que haces a ojo. Para ver qué expone ahora mismo un sitio desplegado, ejecuta npx afterpack@latest audit contra él.

Una clave publicada sigue siendo una clave publicada

La codificación eleva el coste de encontrar la clave leyendo el archivo publicado, y un build que supera la barrera de filtraciones es un resultado real. No es una prueba de que la clave esté fuera de alcance: el valor sigue en la salida, codificado, y se reconstruye en el momento en que tu código lo usa, así que cualquiera que ejecute la página en un navegador que controle puede volver a leerlo. Rotar la clave y trasladar la autoridad a tu propio servidor son los pasos que cierran la exposición.

Siguiente