Bewährte Verfahren

Ihre API Keys und Tokens sollten sehr sorgfältig geschützt werden. 

Diese Anmeldeinformationen sind direkt mit Ihrer Developer-App und den X Konten verknüpft, die Ihnen die Autorisierung erteilt haben, in ihrem Namen Anfragen zu stellen. Wenn Ihre Keys kompromittiert werden, könnten Angreifer sie verwenden, um im Namen Ihrer Developer-App oder ihrer autorisierten Nutzer Anfragen an die X endpoints zu stellen. Dies könnte dazu führen, dass Sie unerwartete Rate Limits erreichen, Ihr bezahltes Zugangskontingent aufbrauchen oder sogar dass Ihre Developer-App suspendiert wird.

Die folgenden Abschnitte enthalten Best Practices, die Sie beim Verwalten Ihrer API Keys und Tokens berücksichtigen sollten.

​

API Keys und Tokens neu generieren

Falls Sie glauben, dass Ihre API Keys offengelegt wurden, sollten Sie Ihre API Keys wie folgt neu generieren:

1. Navigieren Sie zur Seite des Entwicklerportals „Projects and Apps“.
2. Klicken Sie auf das Symbol „Keys and tokens“ (🗝) neben der betreffenden App.
3. Klicken Sie auf die Schaltfläche „Regenerate“ neben dem Satz von Keys und Tokens, den Sie neu generieren möchten.

Wenn Sie Ihre Access Tokens oder Bearer Tokens lieber programmgesteuert neu generieren möchten, können Sie dies über unsere Authentication-endpoints tun.

• Wenn Sie Ihre Access Tokens neu generieren möchten, müssen Sie Ihre Tokens mit dem endpoint POST oauth/invalidate_token ungültig machen und anschließend Ihre Tokens mithilfe des 3-legged OAuth-Flow neu generieren.
• Wenn Sie Ihren Bearer Token neu generieren möchten, müssen Sie Ihren Token mit dem endpoint POST oauth2/invalidate_token ungültig machen und anschließend Ihren Token mithilfe des endpoints POST oauth2/token neu generieren.

​

Eine zentrale Datei für Ihre Secrets verwenden

Eine Datei wie eine .ENV-Datei oder eine andere .yaml-Datei zur Verwaltung Ihrer Secrets kann hilfreich sein. Achten Sie jedoch darauf, eine strikte .gitignore-Datei zu verwenden, um zu verhindern, dass Sie diese versehentlich in ein Git-Repository committen. 

​

Umgebungsvariablen

Es kann hilfreich sein, Code zu schreiben, der Umgebungsvariablen verwendet.

Ein Beispiel dafür in Python:

import os

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

consumer_secret = os.environ.get("CONSUMER_SECRET")

In Ihrem Terminal würden Sie etwas wie Folgendes eingeben:

export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'

​

Quellcode und Versionskontrolle

Zu den häufigsten Sicherheitsfehlern von Entwickler:innen gehört, dass API Keys und Tokens in zugänglichen Versionskontrollsystemen wie GitHub und Bitbucket im Quellcode eingecheckt werden. Viele dieser Code-Repositories sind öffentlich zugänglich. Dieser Fehler kommt in öffentlichen Code-Repositories so häufig vor, dass es lukrative Bots gibt, die gezielt nach API Keys suchen.

• Verwenden Sie Server-Umgebungsvariablen. Indem Sie API Keys in Umgebungsvariablen speichern, halten Sie sie aus Ihrem Code und der Versionskontrolle heraus. So können Sie außerdem problemlos unterschiedliche Keys für verschiedene Umgebungen verwenden.
• Verwenden Sie eine Konfigurationsdatei, die von der Versionskontrolle ausgeschlossen ist. Fügen Sie den Dateinamen Ihrer .gitignore-Datei hinzu, um die Datei von der Nachverfolgung durch die Versionskontrolle auszunehmen.
• Wenn Sie die API Keys nachträglich aus Ihrem Code entfernen, nachdem er versioniert wurde, bleiben die API Keys wahrscheinlich weiterhin zugänglich, indem auf frühere Versionen Ihrer Codebasis zugegriffen wird. Generieren Sie Ihre API Keys neu, wie im nächsten Abschnitt beschrieben.

​

Datenbanken

Wenn Sie Ihre access tokens in einer Datenbank speichern müssen, beachten Sie bitte Folgendes:

• Beschränken Sie den Datenbankzugriff so, dass die access tokens nur vom Inhaber des Tokens gelesen werden können.
• Beschränken Sie die Bearbeitungs- und Schreibrechte für die Datenbanktabelle für access tokens – dies sollte durch das Schlüsselverwaltungssystem automatisiert werden.
• Verschlüsseln Sie access tokens, bevor sie in beliebigen daten­speichern abgelegt werden.

​

Tools zur Passwortverwaltung

Tools zur Passwortverwaltung wie 1Password oder LastPass können hilfreich sein, um Ihre Keys und Tokens sicher aufzubewahren. Verzichten Sie nach Möglichkeit darauf, diese in einem gemeinsam genutzten Team-Passwortmanager zu teilen.

​

Webspeicher & Cookies

Es gibt zwei Arten von Webspeicher: LocalStorage und SessionStorage. Diese wurden als Verbesserungen gegenüber der Verwendung von Cookies entwickelt, da die Speicherkapazität für Webspeicher wesentlich höher ist als für Cookies. Allerdings haben beide Speicheroptionen jeweils unterschiedliche Vor- und Nachteile.  

Web Storage: LocalStorage

Alles, was im lokalen Webspeicher gespeichert wird, ist persistent. Das bedeutet, dass die Daten erhalten bleiben, bis sie ausdrücklich gelöscht werden. Je nach Anforderungen Ihres Projects kann das positiv sein. Sie sollten jedoch den Einsatz von LocalStorage sorgfältig abwägen, da alle Änderungen/Ergänzungen an Daten bei allen zukünftigen Besuchen der betreffenden Webseite verfügbar sind. Wir empfehlen die Verwendung von LocalStorage in der Regel nicht, auch wenn es einige wenige Ausnahmen geben kann. Wenn Sie sich für LocalStorage entscheiden, ist es gut zu wissen, dass es die Same-Origin-Policy unterstützt, sodass alle hier gespeicherten Daten nur über denselben Origin verfügbar sind. Ein zusätzlicher Performance-Vorteil von LocalStorage ist die Verringerung des Client-Server-Verkehrs, da die data nicht bei jeder HTTP-Anfrage an den Server zurückgesendet werden muss.  

Web Storage: SessionStorage

SessionStorage ähnelt LocalStorage, aber der entscheidende Unterschied besteht darin, dass SessionStorage nicht persistent ist. Sobald das Fenster (oder der Tab, je nach verwendetem Browser), das zum Schreiben in SessionStorage verwendet wurde, geschlossen wird, gehen die Daten verloren. Das ist nützlich, um den Lesezugriff auf Ihr Token innerhalb einer Benutzersitzung einzuschränken. Aus Sicherheitsperspektive ist die Verwendung von SessionStorage in der Regel gegenüber LocalStorage vorzuziehen. Wie bei LocalStorage gelten auch für SessionStorage die Vorteile der Unterstützung der Same-Origin-Policy und des verringerten Client-Server-Verkehrs.  

Cookies

Cookies sind die traditionellere Methode zur Speicherung von Sitzungsdaten. Sie können für jedes Cookie eine Ablaufzeit festlegen, was die Widerrufbarkeit und die Einschränkung des Zugriffs erleichtert. Der Client-Server-Verkehr nimmt jedoch bei der Verwendung von Cookies definitiv zu, da die data bei jeder HTTP-Anfrage an den Server zurückgesendet wird. Wenn Sie sich für die Verwendung von Cookies entscheiden, müssen Sie sich gegen Session Hijacking schützen. Standardmäßig werden Cookies im Klartext über HTTP gesendet, wodurch ihre Inhalte anfällig für Packet Sniffing und/oder Man-in-the-Middle-Angriffe sind, bei denen Angreifer Ihren Verkehr manipulieren können. Sie sollten immer HTTPS erzwingen, um Ihre Daten während der Übertragung zu schützen. Dies gewährleistet Vertraulichkeit, Integrität (der Daten) und Authentifizierung. Wenn Ihre Webanwendung oder Website jedoch sowohl über HTTP als auch über HTTPS verfügbar ist, sollten Sie zusätzlich das „Secure“-Flag beim Cookie setzen. Dadurch wird verhindert, dass Angreifer einem Benutzer Links zur HTTP-Version Ihrer Seite senden und das daraus resultierende HTTP-Request belauschen können.

Eine weitere sekundäre Verteidigungsmaßnahme gegen Session Hijacking bei der Verwendung von Cookies besteht darin, die Identität des Benutzers erneut zu validieren, bevor Aktionen mit hoher Auswirkung durchgeführt werden. Ein weiteres Flag, das Sie zur Verbesserung der Sicherheit Ihrer Cookies in Betracht ziehen sollten, ist das „HttpOnly“-Flag. Dieses Flag teilt dem Browser mit, dass das betreffende Cookie nur vom angegebenen Server aus zugänglich sein soll. Jegliche Versuche von clientseitigen Skripten würden durch dieses Flag unterbunden, was dabei hilft, die meisten Cross-Site-Scripting-(XSS)-Angriffe zu verhindern.