Sicherheit

Wie über den Zugriff auf die API entschieden wird, wie ein Credential scheitern kann und was dir das sagt, was wir tun, wenn etwas ausfällt, und wie du eine Schwachstelle meldest. Die Mechanik hinter jeder Anfrage steht unter Wie wir deine Daten schützen.

118/135Operationen brauchen ein Credential
2Wege, einen Schlüssel zu senden
39Gründe, aus denen eine Anfrage abgelehnt werden kann
TLSHSTS mit Preload

Prinzipien

Vier Regeln, jede mit dem Code, der sie durchsetzt.

Minimale Rechte

Ein Schlüssel sieht, was sein Plan erlaubt, und nicht mehr. Felder werden pro Plan nach jedem Handler geformt; Endpunkte sind in einer Middleware nach Stufe gesperrt.

Feldformung

Verteidigung in der Tiefe

TLS, Härtungs-Header, eine Origin-Allowlist, Body-Grenzen, Minuten- und Tageslimiter und Paginierungsgrenzen stapeln sich; was eine Stufe passiert, trifft die nächste.

Die Request-Pipeline

Datensparsamkeit

Ein Konto ist eine E-Mail und ein Plan. Kartendaten bleiben bei Stripe, Fehlerlogs enthalten Code und Request-ID, Audit-Zeilen nie einen Body.

Datenschutz und Compliance

Sicher per Voreinstellung

Es gibt eine Konfiguration, und sie ist die sichere: nichts, das du einschalten musst, und das einzige Opt-in auf unserer Seite ist Analytics hinter einem Consent-Banner.

Header auf jeder Antwort

Wie ein Aufrufer identifiziert wird

Vier Arten von Credentials erreichen die API. Jede wird anders geprüft und scheitert mit eigenen Gründen, damit der Fehler sagt, welche schuld ist.

Credential	Geprüft durch	Scheitert als
API-Schlüssel	Bei jeder Anfrage im Schlüsselspeicher nachgeschlagen, mit Plan und Besitzer. Deaktivierte und abgelaufene Schlüssel werden abgelehnt, bevor ein Handler läuft. Gesendet als X-API-Key or Authorization.	`KEY_MISSING` `KEY_INVALID` `KEY_DISABLED` `KEY_EXPIRED` `ACCOUNT_SUSPENDED`
Website-Sitzung	Ein `HttpOnly`-, `Secure`-Cookie auf unserer Domain, gestützt auf eine Datenbankzeile und gecacht; ein Cache-Miss baut sie aus der Zeile neu, statt dich abzumelden. Getrennt von API-Schlüsseln und der Sitzung der Mitarbeiterkonsole.	`SIGN_IN_REQUIRED` `SESSION_EXPIRED` `ACCOUNT_NOT_FOUND`
Die Website selbst	Ein serverseitiges Proxy-Token, das der Browser nie sieht. Gewährt keinen Plan und keinen Schlüssel: Die Seite rendert mit der vollen Feldpolitik, kann aber nicht geliehen werden, um die API aufzurufen.	`ORIGIN_BLOCKED`
Marketplace-Proxy	Ein Proxy-Geheimnis plus der Abo-Header, den der Marketplace weiterreicht. Der Planname wird einer Stufe zugeordnet; der Marketplace misst das Kontingent.	`PROXY_CREDENTIAL_INVALID`

401 oder 403: welches du bekommst, zählt

Ein 401 ist ein Credential-Problem: fehlend, fehlerhaft, deaktiviert oder abgelaufen, und ein anderes kann funktionieren. Ein 403 heißt, das Credential ist gültig und der Aufrufer nicht berechtigt; einen Schlüssel zu rotieren ändert nichts. Jede Antwort nennt den genauen Grund.

Jeder Grund, mit dem, was zu tun ist

Schlüsselhygiene

Was einen Schlüssel geheim hält.

Tun

Einen Schlüssel nur über TLS senden, im Header X-API-Key oder als Bearer-Token, aus serverseitigem Code.
Ein Schlüssel pro Anwendung oder Umgebung, damit ein Widerruf die anderen nicht mitreißt.
Schlüssel planmäßig rotieren und sofort widerrufen, wenn jemand geht; der Widerruf wirkt sofort.
error.reason lesen, bevor du rotierst: Ein 403 wird nie durch einen neuen Schlüssel behoben.
Den Schlüssel aus der URL halten: Query-Strings landen in Logs und Referrer-Headern.

Nicht tun

Einen Schlüssel in Browser- oder Mobile-Code, ein öffentliches Repository oder einen geteilten Screenshot bringen.
Einen Schlüssel über mehrere Produkte wiederverwenden oder zwischen Personen teilen.
Denselben Schlüssel von vielen unzusammenhängenden Clients senden: Teilen sich 3 oder mehr Schlüssel einen Client-Fingerabdruck, wird das Konto markiert, und ein Schlüssel auf vielen Clients sieht genauso aus.
Sich für die Produktion auf den im Playground gespeicherten Schlüssel verlassen: Er lebt nur in diesem Browser und wird uns nie zur Speicherung gesendet.

Wenn auf unserer Seite etwas schiefgeht

Was vor einem Vorfall vorhanden ist und was du währenddessen siehst.

Statusseite

Aktuelle und historische Verfügbarkeit unter status.gunspec.io. Die Fußzeile jeder Docs-Seite zeigt den aktuellen Zustand.

Kill-Switch, Wartung, Nur-Lesen

Betreiber können die öffentliche API anhalten oder einfrieren, ohne ihre Konsole zu berühren. Du siehst ein 503 mit Retry-After und benanntem Grund.

Fehleralarm

Eine stündliche Prüfung vergleicht 5xx-Raten und alarmiert Betreiber bei einem Anstieg. Ein absichtliches 5xx wird wie ein Ausfall protokolliert, damit nichts, was wir bewusst auslösen, für uns unsichtbar ist.

Request-IDs

Jede Antwort trägt X-Request-Id, jeder Fehler wiederholt sie. Nenne sie; sie findet die Anfrage, ihren Status und ihren Fehlercode in unseren Logs.

Mitarbeiter-Audit-Trail

Jede ändernde Mitarbeiteraktion landet in einem Append-only-Log mit Akteur, Ziel und Herkunft. Bodies werden nie gespeichert.

Versiegelte Geheimnisse und Backups

Betreiber-Zugangsdaten werden mit authentifizierter Verschlüsselung versiegelt, bevor sie die Datenbank erreichen; ein kopiertes Backup ist kein kompromittiertes Konto.

Eine Schwachstelle melden

Wir wollen davon hören, vertraulich und zuerst. Die vollständige Richtlinie steht auf der Hauptseite; das hier ist die Kurzform.

1Schreib an security@gunspec.io mit einer klaren Beschreibung, den Schritten zur Reproduktion, der betroffenen URL oder dem Endpunkt und einem Proof of Concept.
2Füge eine X-Request-Id bei, wenn du eine hast; sie führt uns direkt zur Anfrage.
3Ein Problem pro Nachricht, wo praktikabel. Wir bestätigen, halten dich auf dem Laufenden und nennen dich mit deiner Erlaubnis.

Im Umfang

gunspec.io, api.gunspec.io und die Systeme, die wir zu ihrem Betrieb einsetzen.

Außerhalb des Umfangs

Denial of Service, volumetrische oder Spam-Tests.
Social Engineering von Mitarbeitern oder Nutzern sowie physische Angriffe.
Meldungen automatisierter Tools ohne nachgewiesene, ausnutzbare Auswirkung.
Unsere Hosting- und Zahlungsanbieter, die eigene Programme betreiben.

Safe Harbor

Gutgläubige Forschung, die der Richtlinie folgt, ist autorisiert. Wir gehen dafür nicht rechtlich vor, und tut es ein Dritter, machen wir diese Autorisierung bekannt. Nutze Testkonten und Testdaten, rühre keine fremden Daten an und gib uns angemessene Zeit zur Behebung vor einer Veröffentlichung.

Anerkennung

Derzeit kein bezahltes Bug-Bounty-Programm. Gültige Meldungen werden mit deiner Erlaubnis öffentlich gewürdigt.

security@gunspec.io Vollständige Richtlinie zur Schwachstellenmeldung lesen Kontakt

Verwandt