Seguridad

Creemos que la privacidad es un derecho, no un privilegio, y está integrada en 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 las amenazas de seguridad, y compartimos la responsabilidad de proteger a las personas que usan X. En esta página se describen las expectativas en torno al desarrollo de aplicaciones seguras y a mantener los datos y el acceso lo más protegidos posible.

Ten en cuenta las tecnologías de seguridad disponibles para X Developer Platform, incluidas la autenticación, TLS y los permisos de la App, así como, desde la perspectiva del usuario de X, para usar aplicaciones y sesiones de terceros.

​

Reportar problemas de seguridad

Los usuarios de X Developer Platform deben notificar a X en un plazo no mayor a 48 horas desde la sospecha inicial de que se ha producido un incidente de seguridad, a través del programa de divulgació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 espacios de internet.

​

Seguridad desde el diseño

Considere contratar profesionales de seguridad para realizar un modelado de amenazas y/o una prueba de penetración. Una buena empresa de seguridad investigará a fondo para descubrir problemas. Lea más sobre cómo X ha adoptado esta mentalidad en esta entrada de nuestro blog.

Además, X responsabiliza a todos los socios de lo siguiente:

• Mantener el código en un repositorio seguro.
• Realizar análisis de riesgos a lo largo del ciclo de vida del 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 del proceso de SDLC.
• Garantizar que todos los defectos de prueba se corrijan, se vuelvan a probar y se cierren.

​

Supervisar y recibir 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. También puede crear un panel con métricas clave para ver de un vistazo si algo va mal.

​

Crear 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 de X y al data, 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, e incluyan fallas esperadas para escenarios de seguridad como el acceso no autorizado. Adopta la mentalidad de un atacante y configura pruebas de sistema que deban bloquear que un atacante obtenga acceso no autorizado a los datos de X o a funcionalidades autorizadas.

​

Protección de API keys and tokens

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 estar autenticadas usando OAuth con la API Key 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:

• Implementar una rotación de actualización de contraseñas/tokens.
• Cifrar siempre los datos sensibles según sea necesario y evitar descifrarlos demasiado upstream.
• Almacenar los Access Tokens de tus usuarios en un almacén cifrado.
• Regenerar o invalidar keys and tokens si crees que se han visto comprometidos.

Para 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 entrada

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

​

Comunicación cifrada

X requiere que todas las solicitudes a la API se realicen mediante 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 sensibles de X ni credenciales a través de 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 publicar 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 compilación e implementación. Además, si compartes trazas de pila o volcados de errores para generar informes, asegúrate de que los datos de usuarios privados de X estén anonimizados o redactados.

​

Entrada sin filtrar, salida sin escapar

Un enfoque fácil de recordar para la validación de entradas es FIEO: Filtra la entrada, escapa la salida.

Filtra todo lo que provenga del exterior de tu aplicación, incluidos los datos de la X API, los datos de cookies, la entrada de formularios proporcionada por el usuario, los parámetros de la URL, los datos de bases de datos, etc. Escapa toda la salida que envíe tu aplicación, incluidos el SQL enviado a tu servidor de bases de datos, el HTML que envías 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 medidas, 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, puede causar daños. Cualquier lugar donde almacenes y muestres datos no confiables proporcionados por el usuario debe ser verificado, depurado y con escape de HTML. Hacer esto correctamente es difícil, porque los atacantes tienen muchas formas de ejecutar ataques de 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; utilízalo.

​

Inyección SQL

Si su aplicación utiliza una base de datos, debe tener en cuenta la inyección SQL. Cualquier punto donde se acepte entrada es un objetivo potencial para que un atacante salga de su campo de entrada y acceda a su base de datos. Use bibliotecas de base de datos que protejan de forma sistemática contra la inyección SQL. Si se aparta de ese enfoque y escribe SQL personalizado, cree pruebas exhaustivas para asegurarse de no exponerse a este tipo de ataque. Los dos enfoques principales para defenderse de la inyección SQL son escapar antes de construir la sentencia SQL y usar parámetros para crear las sentencias. Se recomienda este último, ya que es menos propenso a errores de programación.

​

Falsificación de solicitudes entre sitios (CSRF)

¿Está seguro de que las solicitudes a su aplicación provienen de su propia aplicación? Los ataques de CSRF explotan esta falta de certeza al forzar a usuarios con sesión iniciada en su sitio a abrir, sin que lo perciban, URL que ejecutan acciones. En el caso de una App de desarrollador, esto podría significar que atacantes estén usando su App para obligar a los usuarios a publicar Tweets no deseados o a 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 mecanismos sistemáticos para manejar esto, e incluso podrían hacerlo de forma predeterminada si tiene suerte. Un paso preventivo sencillo (aunque no el único que debería tomar) es exigir que cualquier acción que cree, modifique o elimine data requiera una solicitud POST.

​

Falta de límite de tasa

Use 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.