Saltar al contenido principal
Tus API Key y keys and tokens deben protegerse con sumo 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 maliciosos 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 hacer que alcanzaras límites de tasa inesperados, consumieras tu asignación de acceso de pago o incluso que tu App de desarrollador fuera suspendida. Las siguientes secciones incluyen prácticas recomendadas que deben tenerse en cuenta al gestionar tus API Key y keys and tokens.

​
Regenerar API keys and tokens

Si crees que tus API keys 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 ícono “Keys and tokens” (🗝 ) junto a la App correspondiente.
  3. Haz clic en el botón “Regenerate” junto al conjunto de keys and tokens que deseas regenerar.
Si prefieres regenerar tus Access Tokens o Bearer Tokens de forma programática, puedes hacerlo usando nuestros endpoints de autenticación.

​
Contar con un archivo central para tus secretos

Tener un archivo como un .ENV o cualquier otro tipo de archivo .yaml para almacenar tus secretos puede ser útil, pero asegúrate de contar con un archivo .gitignore sólido que impida que los incluyas accidentalmente en un repositorio de Git. 

​
Variables de entorno

Escribir código que utilice variables de entorno puede ser útil.  Un ejemplo de esto es el siguiente, escrito en Python: 
import os

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

consumer_secret = os.environ.get("CONSUMER_SECRET")
En tu terminal, querrás 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 keys and tokens de la 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 de acceso público. Este error ocurre con tanta frecuencia en repositorios públicos que existen bots lucrativos que rastrean en busca de API Keys.
  • Usa variables de entorno del servidor. Al almacenar API Keys en variables de entorno, las mantienes fuera de tu código y del control de versiones. Esto también te permite usar diferentes keys para distintos entornos con facilidad.
  • Usa un archivo de configuración excluido del control de versiones. Agrega el nombre del archivo a tu archivo .gitignore para excluirlo del seguimiento por el control de versiones.
  • Si eliminas las API Keys de tu código después de haber usado control de versiones, es probable que las API Keys sigan siendo accesibles al consultar versiones anteriores de tu base de código. Regenera tus API Keys, como se describe en la siguiente sección.

​
Bases de datos

Si necesitas almacenar tus access tokens en una base de datos, ten en cuenta lo siguiente:
  • Restringe el acceso a la base de datos de modo que los access tokens solo sean legibles por el propietario del token.
  • Restringe los permisos de edición/escritura en la tabla de base de datos para access tokens; esto debe automatizarse con el sistema de gestión de claves.
  • Cifra los access tokens antes de almacenarlos en cualquier almacén 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 keys and tokens en un lugar seguro. Tal vez debas evitar compartirlos dentro de una herramienta de gestión de contraseñas compartida por el equipo.

​
Almacenamiento web y 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 almacenamiento web es mucho mayor que la de las cookies. Sin embargo, cada una de estas opciones de almacenamiento tiene diferentes ventajas y desventajas.   Almacenamiento web: LocalStorage Todo lo que se almacena 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 considerarse positivo. No obstante, debes ser cuidadoso al usar LocalStorage, ya que cualquier cambio o adición a los datos estará disponible en todas las visitas futuras a la página web 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 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) que se utilizó para escribir 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 cuando se piensa en términos de seguridad. Al igual que con LocalStorage, las ventajas de la política de mismo origen y la reducción del tráfico cliente-servidor también se aplican a SessionStorage.   Cookies Las cookies son la forma más tradicional de almacenar datos de sesión. Puedes establecer una fecha de caducidad para cada cookie, lo que permite revocarlas y restringir el acceso con mayor facilidad. Sin embargo, el tráfico cliente-servidor aumentará al usar cookies, ya que los datos se envían 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 forzar HTTPS para proteger tus datos en tránsito. Esto proporcionará confidencialidad, integridad (de los datos) y autenticación. Sin embargo, si tu aplicación o sitio web está disponible tanto por HTTP como por HTTPS, también querrás usar la marca “Secure” en la cookie. Esto evitará que los 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 realizar cualquier acción de alto impacto. Otra marca a considerar para mejorar la seguridad de tus cookies es “HttpOnly”. Esta marca 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á prohibido por esta marca, ayudando así a proteger contra la mayoría de los ataques de cross-site scripting (XSS).
⌘I