Zum Hauptinhalt springen
Wir sind der Überzeugung, dass Privatsphäre ein Recht und kein Privileg ist, und sie ist fest in den Grundlagen unseres Unternehmens verankert. Durch die Nutzung der X Developer Platform und die Einhaltung unserer Entwicklerrichtlinie spielen Sie eine entscheidende Rolle dabei, sicherzustellen, dass die Plattform der öffentlichen Konversation auf X dient und unser Engagement für den Datenschutz gewahrt bleibt. Wir möchten Sie an die Bedeutung sicheren Entwickelns erinnern, um sowohl Ihre eigenen Daten als auch die Daten der Nutzer Ihrer Apps zu schützen. Es liegt in Ihrer Verantwortung, Sicherheitsverletzungen vorzubeugen, und wir tragen gemeinsam Verantwortung dafür, die Menschen zu schützen, die X nutzen. Auf dieser Seite werden die Erwartungen an das Erstellen sicherer Anwendungen sowie daran beschrieben, Daten und Zugriffe so gut wie möglich zu schützen.
Bitte beachten Sie die für die X Developer Platform verfügbaren Sicherheitstechnologien, einschließlich Authentication, TLS und App-Berechtigungen, sowie aus der Perspektive von X Nutzern Hinweise zum Verwenden von Anwendungen und Sitzungen von Drittanbietern.

​
Sicherheitsprobleme melden

Nutzer der X Developer Platform müssen X spätestens 48 Stunden nach dem ersten Verdacht auf einen Sicherheitsvorfall über das Programm zur Meldung von Sicherheitslücken von X informieren.

​
Sicherheitsbewährte Praktiken

Bitte berücksichtigen Sie diese, wenn Sie auf der X Developer Platform und anderswo im Internet entwickeln.

​
Security by design

Erwägen Sie, Sicherheitsexperten mit einem Threat-Modeling-Audit und/oder einem Penetrationstest zu beauftragen. Ein gutes Sicherheitsunternehmen wird gründlich prüfen, um Probleme aufzudecken. Lesen Sie mehr darüber, wie X diese Denkweise übernommen hat, hier in unserem Blogbeitrag. Außerdem nimmt X alle Partner für Folgendes in die Pflicht:
  • Code in einem sicheren Repository pflegen.
  • Risikoanalysen während des gesamten Systems Development Life Cycle (SDLC) durchführen.
  • Sicherstellen, dass Sicherheitsprobleme während des SDLC identifiziert und behoben werden.
  • Sicherstellen, dass Umgebungen während des SDLC-Prozesses strikt voneinander getrennt sind.
  • Sicherstellen, dass alle Testmängel behoben, erneut getestet und abgeschlossen werden.

​
Überwachen und Alarmieren

Wenn Sie vermuten, dass es ein Problem mit Ihrer Web-App gibt, wie finden Sie es zuverlässig heraus? Führen Sie unbedingt aussagekräftige Logs und stellen Sie sicher, dass Sie über kritische Ausnahmen und Fehler benachrichtigt werden. Eventuell möchten Sie ein Dashboard mit wichtigen Kennzahlen einrichten, damit Sie auf einen Blick erkennen, ob etwas schiefläuft.

​
Erstellen Sie einen Meldekanal

Machen Sie es Ihren Nutzern leicht, Sie wegen potenzieller Sicherheitsprobleme zu kontaktieren, die sie mit Ihrer App festgestellt haben. Wenn ein Problem entdeckt wird, das X-Nutzer und data betrifft, sind Sie zudem dafür verantwortlich, dieses Problem an X zu melden. Halten Sie einen Maßnahmenplan/Prozess bereit, um betroffene Nutzer im Falle eines Sicherheitsvorfalls zu benachrichtigen.

​
Angemessene Tests

Stellen Sie sicher, dass Ihre End-to-End-Tests gründlich sind und aktualisiert werden, um erwartete Fehlerszenarien für Sicherheitssituationen wie unbefugten Zugriff abzudecken. Versetzen Sie sich in die Rolle eines Angreifers und richten Sie Systemtests ein, die verhindern sollen, dass ein Angreifer unbefugten Zugriff auf X data oder auf autorisierte Funktionen erlangt.

​
Schutz von API Keys und Tokens

Als Entwickler auf der X‑Plattform haben Sie programmgesteuerten Zugriff sowohl auf Ihre data als auch auf die data Ihrer Nutzer, die von X gespeichert werden, vorausgesetzt, diese haben Ihre Developer-App autorisiert. Alle API-Anfragen müssen mithilfe von OAuth mit dem Key und Secret Ihrer Developer-App und in einigen Fällen mit den Access Tokens eines autorisierenden Nutzers authentifiziert werden. Es liegt in Ihrer Verantwortung, Ihre Zugangsdaten sicher zu verwahren. Empfohlene Best Practices umfassen unter anderem:
  • Richten Sie eine regelmäßige Passwort-/Token-Rotation ein.
  • Verschlüsseln Sie sensible data stets bedarfsgerecht und entschlüsseln Sie data nicht zu früh im Upstream.
  • Speichern Sie die Access Tokens Ihrer Nutzer in einem verschlüsselten Speicher.
  • Generieren Sie Keys und Tokens neu oder machen Sie sie ungültig, wenn Sie vermuten, dass sie kompromittiert wurden.
Für weiterführende Diskussionen zu Debugging und Entwicklung mit OAuth für X besuchen Sie bitte die Sicherheitskategorie des Community-Forums.

​
Eingabevalidierung

Gehen Sie nicht davon aus, dass Ihre Nutzer Ihnen gültige, vertrauenswürdige Daten liefern. Bereinigen Sie alle Daten aus Nutzereingaben, die in X API-Anfragen verwendet werden können. Verwenden Sie eine Allowlist mit zulässigen Eingabetypen für Ihre Anwendung und verwerfen Sie alles, was nicht auf der Allowlist steht.

​
Verschlüsselte Kommunikation

X verlangt, dass alle API-Anfragen über TLS erfolgen. Die Kommunikation mit Ihren eigenen Servern sollte nach Möglichkeit ebenfalls verschlüsselt werden.

​
Offen gelegte Debug-Informationen

Stellen Sie sicher, dass Sie keine sensiblen X-Daten oder Anmeldeinformationen über Debug-Bildschirme oder -Protokolle preisgeben. Einige Webframeworks ermöglichen den einfachen Zugriff auf Debug-Informationen, wenn Ihre Anwendung nicht ordnungsgemäß konfiguriert ist. Für Desktop- und Mobile-Entwickler ist es leicht, versehentlich einen Build mit aktivierten Debug-Flags oder -Symbolen auszuliefern. Integrieren Sie Prüfungen für diese Konfigurationen in Ihren Bereitstellungs- bzw. Build-Prozess. Wenn Sie zudem Stacktraces oder Crash-Dumps zu Berichtszwecken weitergeben, stellen Sie sicher, dass private Daten von X-Nutzern geschwärzt sind.

​
Ungefilterte Eingabe, nicht maskierte Ausgabe

Ein leicht zu merkender Ansatz zur Eingabevalidierung ist FIEO: Filter Input, Escape Output Filtern Sie alles, was von außerhalb Ihrer Anwendung stammt, einschließlich X API data, Cookie-Daten, vom Nutzer bereitgestellter Formulareingaben, URL-Parameter, Daten aus Datenbanken usw. Maskieren (escapen) Sie sämtliche Ausgaben, die von Ihrer Anwendung gesendet werden, einschließlich SQL, das an Ihren Datenbankserver gesendet wird, HTML, das Sie an die Browser der Nutzer senden, JSON-Ausgaben, die an andere Systeme gesendet werden, und Befehle, die an Shell-Programme gesendet werden.

​
Cross-Site Scripting (XSS)

XSS-Angriffe sind nach den meisten Maßstäben die häufigste Form von Sicherheitsproblemen im Web. Wenn ein Angreifer eigenen JavaScript-Code in Ihre Anwendung einschleusen kann, kann er Schaden anrichten. Überall dort, wo Sie nicht vertrauenswürdige, von Nutzern bereitgestellte Daten speichern und anzeigen, muss geprüft, bereinigt und HTML-escaped werden. Das korrekt umzusetzen ist schwierig, da Hacker viele verschiedene Wege haben, XSS-Angriffe zu platzieren. Ihre Programmiersprache oder Ihr Webentwicklungs-Framework bietet wahrscheinlich einen verbreiteten, gut erprobten Mechanismus zum Schutz vor Cross-Site Scripting; bitte nutzen Sie ihn.

​
SQL-Injection

Wenn Ihre Anwendung eine Datenbank nutzt, sollten Sie sich der SQL-Injection bewusst sein. Jede Stelle, an der Sie Eingaben entgegennehmen, ist ein potenzielles Ziel für Angreifer, um aus dem Eingabefeld „auszubrechen“ und in Ihre Datenbank einzudringen. Verwenden Sie Datenbankbibliotheken, die systematisch vor SQL-Injection schützen. Wenn Sie von diesem Ansatz abweichen und eigenes SQL schreiben, entwickeln Sie gründliche Tests, um sicherzustellen, dass Sie sich dieser Angriffsform nicht aussetzen. Die beiden Hauptansätze zur Abwehr von SQL-Injection sind das Escaping vor dem Aufbau der SQL-Anweisung sowie die Verwendung parametrisierter Eingaben zum Erstellen von Anweisungen. Letzteres wird empfohlen, da es weniger anfällig für Programmierfehler ist.

​
Cross-Site Request Forgery (CSRF)

Sind Sie sicher, dass Anfragen an Ihre Anwendung tatsächlich von Ihrer Anwendung stammen? CSRF-Angriffe nutzen diese Unsicherheit aus, indem sie angemeldete Nutzer Ihrer Website dazu bringen, unbemerkt URLs zu öffnen, die Aktionen ausführen. Im Fall einer Developer-App könnte dies bedeuten, dass Angreifer Ihre App verwenden, um Nutzer zum Veröffentlichen unerwünschter Tweets zu zwingen oder Spam-Konten folgen zu lassen. Die gründlichste Methode, CSRF zu begegnen, besteht darin, jedem Formular ein zufälliges Token hinzuzufügen, das an einem vertrauenswürdigen Ort gespeichert ist; wenn ein Formular nicht das richtige Token enthält, sollten Sie einen Fehler auslösen. Moderne Webframeworks bieten dafür systematische Mechanismen und erledigen dies mit etwas Glück sogar standardmäßig. Ein einfacher vorbeugender Schritt (aber keineswegs der einzige, den Sie unternehmen sollten) besteht darin, Aktionen, die Daten erstellen, ändern oder löschen, nur per POST-Anfrage zuzulassen.

​
Fehlende Rate Limits

Setzen Sie CAPTCHAs dort ein, wo es sinnvoll ist, um potenzielle Spammer und Angreifer auszubremsen.
Wenn Sie eine Sicherheitslücke entdeckt haben, die X direkt betrifft, nutzen Sie bitte unser Bug‑Bounty‑Programm für Schwachstellen.
⌘I