Saltar al contenido principal
Creemos que la privacidad es un derecho, no un privilegio, y forma parte de los cimientos de nuestra empresa. Al usar la plataforma para desarrolladores de X y cumplir nuestra política para desarrolladores, desempeñas un papel fundamental para garantizar que la plataforma sirva a la conversación pública en X y proteja nuestro compromiso con la privacidad. Queremos recordarte la importancia de desarrollar de forma segura para proteger tanto tus propios datos como los de los usuarios de tus Apps. Es tu responsabilidad protegerte contra la amenaza de violaciones de seguridad, y compartimos la responsabilidad de proteger a las personas que usan X. Esta página describe las expectativas sobre el desarrollo de aplicaciones seguras y cómo mantener los datos y el acceso lo más seguros posible.
Ten en cuenta las tecnologías de seguridad disponibles para la X Developer Platform, incluidas la Autenticación, TLS y los permisos de Apps, así como, desde la perspectiva del usuario de X, para usar aplicaciones y sesiones de terceros.

​
Notificación de problemas de seguridad

Los usuarios de X Developer Platform deben notificar a X, a más tardar 48 horas después de la sospecha inicial de que se ha producido un incidente de seguridad, a través del programa de notificación de vulnerabilidades de X.

​
Mejores prácticas de seguridad

Téngalas en cuenta al desarrollar en la plataforma para desarrolladores de X y en otros lugares de internet.

​
Seguridad desde el diseño

Considere contratar profesionales de seguridad para realizar un análisis de modelo de amenazas y/o una prueba de penetración. Una buena firma de seguridad profundizará para descubrir problemas. Lea más sobre cómo X ha adoptado esta mentalidad en esta entrada de nuestro blog. Además, X exige a todos los socios lo siguiente:
  • Mantener el código en un repositorio seguro.
  • Realizar análisis de riesgos a lo largo de todo el ciclo de vida de desarrollo de sistemas (SDLC).
  • Garantizar que los problemas de seguridad se identifiquen y mitiguen durante todo el SDLC.
  • Garantizar la segregación de entornos a lo largo de todo el proceso del SDLC.
  • Garantizar que todos los defectos detectados en pruebas se corrijan, se vuelvan a probar y se cierren.

​
Supervise y reciba alertas

Si sospecha que hay un problema con su aplicación web, ¿cómo puede confirmarlo? Asegúrese de mantener buenos registros y de recibir notificaciones sobre excepciones y errores críticos. Quizás quiera configurar un panel con estadísticas clave para poder detectar de un vistazo si algo va mal.

​
Cree un canal de reporte

Facilite que sus usuarios se pongan en contacto con usted sobre posibles problemas de seguridad que hayan experimentado con su App. Si se descubre un problema que afecta a usuarios y datos de X, también es su responsabilidad reportar este problema a X. Tenga preparado un plan o proceso de acción para notificar a los usuarios afectados en caso de que ocurra un incidente de seguridad.

​
Pruebas adecuadas

Asegúrate de que tus pruebas de extremo a extremo sean exhaustivas y estén actualizadas, y de incluir fallos esperados en escenarios de seguridad como el acceso no autorizado. Adopta la mentalidad de un atacante y configura pruebas de sistema que estén diseñadas para bloquear que un atacante obtenga acceso no autorizado a los datos de X o a funcionalidades autorizadas.

​
Protección de claves y tokens de la API

Como desarrollador en la plataforma X, tienes acceso programático tanto a tus datos como a los datos de tus usuarios almacenados por X, siempre que hayan autorizado tu App de desarrollador. Todas las solicitudes a la API deben autenticarse mediante OAuth con la clave y el secreto de tu App de desarrollador y, en algunos casos, con los access tokens del usuario que autoriza. Es tu responsabilidad mantener tus credenciales seguras. Algunas prácticas recomendadas incluyen lo siguiente:
  • Establece una rotación de actualización de contraseñas/tokens.
  • Cifra siempre los datos sensibles según sea necesario y evita descifrarlos demasiado pronto en el flujo.
  • Almacena los access tokens de tus usuarios en un almacén cifrado.
  • Regenera o invalida las claves y los tokens si crees que se han visto comprometidos.
Para obtener más información sobre depuración y desarrollo con OAuth para X, visita la categoría de seguridad del foro de la comunidad.

​
Validación de entradas

No asumas que tus usuarios te proporcionarán datos válidos y confiables. Depura todos los datos provenientes de tus usuarios que puedan terminar en solicitudes a la X API. Define una lista de permitidos con los tipos de entrada que acepta tu aplicación y descarta todo lo que no esté en esa lista.

​
Comunicación cifrada

X exige que todas las solicitudes a la API se realicen a través de TLS. La comunicación con tus propios servidores también debe cifrarse siempre que sea posible.

​
Información de depuración expuesta

Asegúrate de no exponer datos o credenciales sensibles de X en pantallas o registros de depuración. Algunos frameworks web facilitan el acceso a información de depuración si tu aplicación no está configurada correctamente. Para desarrolladores de escritorio y móviles, es fácil distribuir por accidente una compilación con indicadores o símbolos de depuración habilitados. Incorpora comprobaciones de compilación para estas configuraciones en tu proceso de despliegue/compilación. Además, si compartes rastreos de pila o volcados de errores para informes, asegúrate de anonimizar los datos de usuarios privados de X.

​
Entrada sin filtrar, salida sin escapar

Un enfoque fácil de recordar para la validación de entrada es FIEO: filtrar la entrada, escapar la salida. Filtre todo lo que provenga del exterior de su aplicación, incluidos los datos de la X API, los datos de cookies, la información de formularios proporcionada por el usuario, los parámetros de URL, los datos de bases de datos, etc. Escape toda la salida que envíe su aplicación, incluidos el SQL enviado a su servidor de bases de datos, el HTML que envía a los navegadores de los usuarios, la salida JSON enviada a otros sistemas y los comandos enviados a programas de shell.

​
Cross-site scripting (XSS)

Los ataques de XSS son, según la mayoría de las métricas, la forma más común de problema de seguridad en la web. Si un atacante logra inyectar su propio código JavaScript en tu aplicación, podrá hacer cosas maliciosas. Cualquier lugar donde almacenes y muestres datos no confiables proporcionados por el usuario debe comprobarse, depurarse/sanearse y aplicar escape de HTML. Hacer esto correctamente es difícil, porque los atacantes tienen muchas formas de llevar a cabo ataques XSS. Es probable que tu lenguaje o framework de desarrollo web cuente con un mecanismo popular y bien probado para defenderse del cross-site scripting; por favor, utilízalo.

​
Inyección SQL

Si tu aplicación utiliza una base de datos, debes tener en cuenta la inyección SQL. Cualquier punto donde aceptes datos de entrada es un objetivo potencial para que un atacante se salga de su campo de entrada y acceda a tu base de datos. Utiliza bibliotecas de base de datos que protejan contra la inyección SQL de forma sistemática. Si te apartas de ese enfoque y escribes SQL personalizado, crea pruebas rigurosas para asegurarte de no exponerte a este tipo de ataque. Los dos enfoques principales para defenderse de la inyección SQL son realizar el escape antes de construir la instrucción SQL y utilizar parámetros para crear las instrucciones. Se recomienda este último, ya que es menos propenso a errores del programador.

​
Falsificación de solicitud en sitios cruzados (CSRF)

¿Está seguro de que las solicitudes a su aplicación provienen realmente de su aplicación? Los ataques de CSRF aprovechan esta falta de certeza obligando a usuarios con sesión iniciada en su sitio a abrir en silencio URL que ejecutan acciones. En el caso de una App para desarrolladores, esto podría significar que atacantes usen su App para obligar a los usuarios a publicar Tweets no deseados o seguir cuentas de spam. La forma más rigurosa de abordar CSRF es incluir un token aleatorio en cada formulario y almacenarlo en un lugar de confianza; si un formulario no tiene el token correcto, genere un error. Los frameworks web modernos tienen maneras sistemáticas de manejar esto, e incluso podrían hacerlo de forma predeterminada si tiene suerte. Un paso preventivo sencillo (aunque de ningún modo el único que debería tomar) es exigir una solicitud POST para cualquier acción que cree, modifique o elimine datos.

​
Falta de limitación de solicitudes

Utilice CAPTCHAs cuando corresponda para frenar a posibles spammers y atacantes.
Si ha descubierto un problema de seguridad que afecta directamente a X, contamos con un programa de recompensas por vulnerabilidades.