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 aquellas cuentas de X que te hayan 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 hacer que dichas solicitudes te lleven a alcanzar límites de tasa inesperados, agotar tu cuota de acceso de pago o incluso provocar que tu App de desarrollador sea suspendida. Las siguientes secciones incluyen prácticas recomendadas que se deben considerar al administrar tus claves y tokens de API.

​
Regenerar claves y tokens de API

En caso de que creas que tus claves de API se han expuesto, debes regenerarlas siguiendo estos pasos:
  1. Ve a la página “Apps” de la Consola de desarrollador.
  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 Bearer Tokens de forma programática, puedes hacerlo usando nuestros endpoints de autenticación.

​
Tener un archivo central para tus secretos

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

​
Variables de entorno

Escribir código que haga uso de variables de entorno puede ser útil.  Un ejemplo de esto, escrito 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 lo siguiente: 
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 de API y tokens 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 se comete tan a menudo en repositorios de código públicos que existen bots muy rentables que rastrean claves de API.
  • Usa variables de entorno en el 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 fácilmente claves diferentes para distintos entornos.
  • Usa un archivo de configuración excluido del control de versiones. Agrega el nombre del archivo a tu archivo .gitignore para excluirlo de ser rastreado por el control de versiones.
  • Si quitas las claves de API de tu código después de haber usado el control de versiones, es probable que las claves de API sigan siendo accesibles al consultar versiones anteriores de tu repositorio 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 forma que los tokens de acceso solo sean legibles por el propietario del token.
  • Restringe los privilegios de edición/escritura en la tabla de la base de datos que almacena los tokens de acceso; esto debería automatizarse mediante el sistema de gestión de claves.
  • Cifra los tokens de acceso 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 ser útiles para mantener tus claves y tokens en un lugar seguro. Es posible que quieras evitar compartirlas en 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 una mejora frente al uso de cookies, ya que la capacidad de almacenamiento del almacenamiento web es mucho mayor que la del almacenamiento mediante 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 se conservarán hasta que se eliminen explícitamente. Dependiendo de las necesidades de tu proyecto, podrías ver esto como algo positivo. Sin embargo, debes ser cuidadoso al usar LocalStorage, ya que cualquier cambio o adición de datos estará disponible en todas las visitas futuras a la página web en cuestión. Normalmente no recomendamos usar LocalStorage, aunque puede haber algunas excepciones a esto. Si decides usar LocalStorage, es importante saber que admite la política de mismo origen, por lo que todos los datos almacenados aquí solo estarán disponibles a través del mismo origen. Una ventaja adicional de rendimiento al usar LocalStorage sería la disminución del tráfico cliente-servidor, ya que no es necesario enviar los datos de vuelta al servidor para 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 LocalStorage, las ventajas de la política de mismo origen y la disminució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 un tiempo de expiración para cada cookie, lo que permite revocarlas y restringir el acceso con mayor facilidad. Sin embargo, el tráfico cliente-servidor definitivamente aumentará al usar cookies, ya que los datos se envían de vuelta al servidor para cada solicitud HTTP. Si decides usar cookies, necesitas protegerte contra el secuestro de sesión (session hijacking). De forma predeterminada, las cookies se envían en texto plano sobre 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 hacer cumplir el uso de 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 mediante HTTP como mediante HTTPS, también querrás usar la bandera “Secure” en la cookie. Esto evitará que los atacantes puedan enviar enlaces a la versión HTTP de tu sitio a un usuario e interceptar la solicitud HTTP resultante que se genere. Otra defensa secundaria contra el secuestro de sesión al usar cookies sería volver a validar la identidad del usuario antes de que se lleven a cabo acciones de alto impacto. Otra bandera a considerar para mejorar la seguridad de tus cookies sería la bandera “HttpOnly”. Esta bandera 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 será bloqueado por esta bandera, ayudando así a proteger contra la mayoría de los ataques de cross-site scripting (XSS).