Saltar al contenido principal
Tus claves y tokens de API deben protegerse con mucho cuidado. Estas credenciales están vinculadas directamente a tu App de desarrollador y a las cuentas de X que te han autorizado a realizar solicitudes en su nombre. Si tus claves se ven comprometidas, actores malintencionados podrían usarlas para realizar solicitudes a los endpoints de X en nombre de tu App de desarrollador o de sus usuarios autorizados, lo que podría ocasionar que alcances límites de frecuencia inesperados, agotes tu cupo de acceso de pago o incluso que tu App de desarrollador sea suspendida. Las siguientes secciones incluyen prácticas recomendadas que se deben considerar al gestionar tus claves y tokens de API.

​
Regenerar claves y tokens de la API

Si crees que tus claves de API se han expuesto, debes regenerarlas siguiendo estos pasos:
  1. Ve a la página «Projects and Apps» del Portal de desarrolladores.
  2. Haz clic en el icono «Keys and tokens» (🗝) junto a la App correspondiente.
  3. Haz clic en el botón «Regenerate» junto al conjunto de claves y tokens que deseas regenerar.
Si prefieres regenerar tus Access Tokens o tu Bearer Token de forma programática, puedes hacerlo usando nuestros endpoints de Autenticación.

​
Contar con un archivo central para tus secretos

Usar un archivo como .env o algún .yaml para almacenar tus secretos puede ser útil; solo asegúrate de tener un .gitignore sólido que evite que los subas por accidente a un repositorio de Git. 

​
Variables de entorno

Puede ser útil escribir código que utilice variables de entorno. Un ejemplo de esto en Python es el siguiente: 
import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")
En tu terminal, deberías escribir algo como esto: 
export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'

​
Código fuente y control de versiones

Los errores de seguridad más comunes que cometen los desarrolladores consisten en tener claves y tokens de API incluidos en el código fuente dentro de sistemas de control de versiones accesibles como GitHub y Bitbucket. Muchos de estos repositorios de código son públicos. Este error ocurre con tanta frecuencia en repositorios públicos que existen bots rentables que rastrean claves de API.
  • Usa variables de entorno del servidor. Al almacenar las claves de API en variables de entorno, las mantienes fuera de tu código y del control de versiones. Esto también te permite usar distintas claves para diferentes entornos con facilidad.
  • Usa un archivo de configuración excluido del control de versiones. Agrega el nombre del archivo a tu .gitignore para excluirlo del seguimiento por el control de versiones.
  • Si eliminas las claves de API de tu código después de haber usado control de versiones, es probable que sigan siendo accesibles al consultar versiones anteriores de tu base de código. Regenera tus claves de API, como se describe en la siguiente sección.

​
Bases de datos

Si necesitas almacenar tus tokens de acceso en una base de datos, ten en cuenta lo siguiente:
  • Restringe el acceso a la base de datos de manera que los tokens de acceso solo sean legibles por el propietario del token.
  • Restringe los privilegios de edición y escritura en la tabla de la base de datos que almacene tokens de acceso; esto debe automatizarse con el sistema de gestión de claves.
  • Cifra los tokens de acceso antes de almacenarlos en cualquier sistema de almacenamiento de datos.

​
Herramientas de gestión de contraseñas

Las herramientas de gestión de contraseñas, como 1Password o LastPass, pueden ayudarte a mantener tus claves y tokens en un lugar seguro. Quizá prefieras evitar compartirlos en una herramienta de gestión de contraseñas compartida por el equipo.

​
Almacenamiento web & cookies

Hay dos tipos de almacenamiento web: LocalStorage y SessionStorage. Estos se crearon como mejoras respecto al uso de cookies, ya que la capacidad de almacenamiento del web storage es mucho mayor que la de las cookies. Sin embargo, cada una de estas opciones de almacenamiento tiene distintos pros y contras.   Almacenamiento web: LocalStorage Todo lo que se guarda en el almacenamiento web local es persistente. Esto significa que los datos permanecerán hasta que se eliminen explícitamente. Dependiendo de las necesidades de tu proyecto, esto puede ser positivo. No obstante, debes ser prudente al usar LocalStorage, ya que cualquier cambio o adición a los datos estará disponible en todas las visitas futuras a la página en cuestión. Por lo general, no recomendamos usar LocalStorage, aunque puede haber algunas excepciones. Si decides usar LocalStorage, es útil saber que respeta la política de mismo origen, por lo que todos los datos almacenados aquí solo estarán disponibles desde el mismo origen. Una ventaja adicional de rendimiento al usar LocalStorage es la disminución del tráfico cliente-servidor, ya que los datos no tienen que enviarse de vuelta al servidor en cada solicitud HTTP.   Almacenamiento web: SessionStorage SessionStorage es similar a LocalStorage, pero la diferencia clave es que SessionStorage no es persistente. Una vez que se cierra la ventana (o pestaña, según el navegador que estés usando) con la que se escribió en SessionStorage, los datos se perderán. Esto es útil para restringir el acceso de lectura a tu token dentro de una sesión de usuario. Usar SessionStorage suele ser preferible a LocalStorage en términos de seguridad. Al igual que LocalStorage, SessionStorage también se beneficia de la política de mismo origen y de la reducción del tráfico cliente-servidor.   Cookies Las cookies son la forma más tradicional de almacenar datos de sesión. Puedes establecer un tiempo de expiración para cada cookie, lo que facilita la revocación y la restricción de acceso. Sin embargo, el tráfico cliente-servidor aumentará al usar cookies, ya que los datos se envían de vuelta al servidor en cada solicitud HTTP. Si decides usar cookies, debes protegerte contra el secuestro de sesión. De forma predeterminada, las cookies se envían en texto plano a través de HTTP, lo que hace que su contenido sea vulnerable al sniffing de paquetes y/o a ataques de intermediario (man-in-the-middle) en los que los atacantes pueden modificar tu tráfico. Siempre debes exigir HTTPS para proteger tus datos en tránsito. Esto proporcionará confidencialidad, integridad (de los datos) y autenticación. No obstante, si tu aplicación web o sitio está disponible tanto por HTTP como por HTTPS, también deberías usar la marca “Secure” en la cookie. Esto evitará que atacantes puedan enviar a un usuario enlaces a la versión HTTP de tu sitio y escuchar la solicitud HTTP resultante. Otra defensa adicional contra el secuestro de sesión al usar cookies es volver a validar la identidad del usuario antes de ejecutar cualquier acción de alto impacto. Otra marca a considerar para mejorar la seguridad de tus cookies es “HttpOnly”. Esta marca le indica al navegador que la cookie en cuestión solo será accesible desde el servidor especificado. Cualquier intento realizado por scripts del lado del cliente quedará bloqueado por esta marca, lo que ayuda a proteger contra la mayoría de los ataques de cross-site scripting (XSS).