Was das Register ist
Jede wiederkehrende Fehlerklasse in der Geschichte von FlareWatch wurde in eine nummerierte Schutzmaßnahme destilliert: eine einseitige Regel, eine Begründung und ein Verweis auf die Stelle im Code, die sie durchsetzt. Neue Schutzmaßnahmen werden hinzugefügt, wenn eine Fehlerklasse oder ein Muster auftaucht, das wiederkehrend verhindert werden sollte.
Das Register ist ein Arbeitsdokument, keine Marketingmaterial. Sein Zweck ist es, das Team — und die Audit-First-Überprüfungsschleife, die das Team verwendet — ehrlich darüber zu halten, welche Regeln wo gelten. Das Register wird in Inline-Code-Kommentaren referenziert (z. B. // Safeguard 24), damit ein Leser einer beliebigen Datei die Regel finden kann, die die umgebenden Zeilen regelt.
Diese Seite ist eine öffentliche Zusammenfassung. Das vollständige Register befindet sich im Quell-Repository neben dem Code, den es regelt. Der Zweck besteht darin, Sicherheitsforschern, Grant-Reviewer oder potenziellen Mitwirkenden einen Überblick über die Kategorien des Registers und die Art der Disziplin, die es durchsetzt, zu geben.
Warum ein Register
Ein Sicherheitsregister rechtfertigt seine Existenz nur, wenn es verhindert, dass derselbe Fehler zweimal auftritt. Die Erfolgsgeschichte des Registers ist die Antwort:
- Jede Sicherheitsmaßnahme benennt den Fehler, den sie verhindert. Eine Regel ohne einen erinnerten Incident dahinter ist keine Sicherheitsmaßnahme, sondern eine Stilpräferenz. Stilpräferenzen gehören in Lint-Regeln, nicht in das Register.
- Sicherheitsmaßnahmen werden aus dem Code referenziert, nicht nur aus der Dokumentation. Eine Codeänderung, die eine Sicherheitsmaßnahme verletzt, wird bei der Überprüfung als Flagge erkannt, weil die Sicherheitsmaßnahmennummer in den umgebenden Kommentaren steht.
- Einige Sicherheitsmaßnahmen werden automatisch durchgesetzt. Eine Teilmenge wird durch ESLint-Regeln oder Shell-Skripte durchgesetzt, die in CI ausgeführt werden. Der Rest verlässt sich auf die Disziplin des Autors plus das Audit-first-Review-Muster, das sich in der Praxis bewährt hat.
- Das Register wird durch Tests überprüft. Mehrere Sicherheitsmaßnahmen sind durch Regressionstests verankert, die Quelldateien als Strings lesen und behaupten, dass Anti-Patterns nicht erscheinen. Sprödigkeit ist das Feature: Ein zukünftiger Refactor, der zu einem Anti-Pattern zurückkehrt, schlägt den Test fehl, bevor die Regression in die Produktion gelangt.
Kategorien
Das Register ist nach Domäne organisiert. Die folgenden Kategorien sind stabil; spezifische Sicherheitsmaßnahmen innerhalb jeder werden hinzugefügt, wenn neue Fehlermodi entdeckt werden.
| Kategorie | Was es abdeckt |
|---|---|
| Authentifizierung & Autorisierung | Einzelner Engpass für Session-Validierung, Wallet-Eigentumsprüfungen pro Route, Cross-Token-Ablehnung zwischen Access- und Refresh-Token, Admin-Route-Gating. |
| Datenintegrität | Adressnormalisierung, Unit-Conversion-Verträge an Producer/Consumer-Grenzen, Key-Builder-Disziplin und Regeln gegen stille Zusammenführung von Fehlern in Nullwerte. |
| On-Chain-Lesezugriffe | Single-Implementation-Regeln für jeden von einem Smart Contract gelesenen Wert, Contract-Adressauflösung aus dem On-Chain-Register und Regeln gegen Duplizierung von Reward-Logik. |
| Anzeigegenauigkeit | Zentralisierte Zahlen-, Währungs- und Datumsformatierung; Null-Sicherheit bei jeder numerischen Anzeige; APR-vs.-APY-Kennzeichnungsdisziplin; Steuersatz-als-Effektiv-Disziplin. |
| Benachrichtigungen & Meldungen | Einzelne Quelle der Wahrheit für die Bewertung von Benachrichtigungen zwischen Client und Server; explizite Allowlists für die Verbreitung von Benachrichtigungen an beobachtete Wallets; Ablösungsregeln, sodass eine "Belohnungen eingegangen"-Benachrichtigung eine veraltete "Belohnungen verfügbar"-Benachrichtigung aufhebt; synchronisierte Abmeldung über Geräte hinweg. |
| Persistenz & Cache | Regeln für den Zeitpunkt, zu dem der kanonische Speicher das Key-Value-Backend gegenüber dem localStorage ist; Migrationsdisziplin; Deploy-Bereichs-Service-Worker-Cache; explizites dynamisches Opt-out für Routen, die Live-State lesen. |
| UI & Lebenszyklusmanagement | Seiten-Bereitschaftsgates, monotone Floors, die verhindern, dass transiente Nullwerte bekannte Salden verdrängen, und Regeln für Skelett-Rendering während Cold-Fetch-Fenster. |
| Prozess & Tooling | Regeln für explizite Zustimmung zum Feature-Start, vollständige Test-Suiten bei Änderungen der Alert-Oberfläche, strukturierte Protokollierung im serverseitigen Code und Review-Disziplin gegen Abkürzungslösungen. |
Einige repräsentative Regeln
Dies sind öffentlich unbedenkliche Zusammenfassungen von Schutzmaßnahmen, die den Charakter des Registrars illustrieren. Sie sind paraphrasiert und abgekürzt; der kanonische Text befindet sich neben dem Code.
Einzelne Quelle der Wahrheit für On-Chain-Lesevorgänge
Jeder Wert, der aus einem Smart Contract gelesen wird – anspruchsberechtigte Belohnungen, Salden, Stake-Status, Epoch-Daten, Preise – wird von genau einer Funktion in der Service-Schicht berechnet. Jedes Feature, das diesen Wert benötigt, importiert die gleiche Funktion. Wenn zwei Funktionen den gleichen Wert berechnen, ist eine davon falsch; die Regel ist, sie zu löschen, nicht eine dritte hinzuzufügen.
Einzelner Engpass für Session-Validierung
Jede authentifizierte Route in FlareWatch validiert Session-Cookies über einen einzigen Helper. Kein Route-Handler verifiziert Session-Token unabhängig. Diese Invariante macht die serverseitige Widerrufung universell – es gibt keine Hintertüren, die die Überprüfung umgehen.
Ownership-Gating pro Wallet, beide Seiten
Pro-Wallet-Routen überprüfen die Eigentümerschaft server-seitig, nicht client-seitig. Das ursprüngliche Audit hat die Regel etabliert, weil frühere Arbeiten die client-seitigen Gates geschlossen hatten, aber die server-seitigen Endpunkte vollständig ungefiltert ließen. Die beiden Hälften werden nun als separate explizite Liefergegenstände nachverfolgt — auf der Client-Seite geschlossen, auf dem Server geschlossen — um zu verhindern, dass dieser Fehlermodus erneut auftritt.
Zentrale Formatter verwenden, nie inline
Alle Zahlen-, Währungs- und Datumsformatierungen laufen durch einen kleinen Satz zentraler Hilfsfunktionen. Keine Komponente formatiert inline. Die Regel hat nichts mit Stil zu tun: Wenn sich eine einzelne Gebietsschema- oder Währungsdefinition ändert, wird jede Oberfläche in der Anwendung damit aktualisiert. Abweichungen zwischen Oberflächen sind stumm und schwer zu erkennen, bis ein Benutzer sie bemerkt.
Einheitenumwandlungen sind an beiden Enden dokumentiert
Wenn zwei Teile des Systems Werte austauschen, deren Einheit mehrdeutig sein könnte (Sekunden vs. Millisekunden, Dezimal vs. Prozentsatz, Kleinbuchstaben vs. Checksummen-Adressen), wird die Konvention sowohl beim Produzenten als auch beim Konsumenten dokumentiert. Ein Kommentar an nur einer Stelle veraltet; nur ein Grenzvertrag, der an beiden Enden bestätigt wird, übersteht einen Refactor.
Eine Implementierung pro Benutzeraktion
Jede vom Benutzer initiierte Aktion — das Hinzufügen einer beobachteten Wallet, das Ändern einer Steuersatz, das Verwerfen einer Benachrichtigung, das Abmelden — hat genau eine Implementierung. Die Regel existiert, weil Aktionen, die von verschiedenen Teilen der Benutzeroberfläche ausgelöst wurden, früher auf subtile Weise abwichen: Ein Einstiegspunkt würde einen Cache löschen, ein anderer nicht, und eine Klasse von "veralteter Wert nach Operation X"-Bugs würde entstehen.
Fehlermodi, die deutlich sein müssen
Einige Fehlermodi sind von Natur aus stumm — eine falsch klassifizierte Belohnung, ein Einheitenmismatch, das eine Benachrichtigung zu einer Nicht-Operation macht, ein Verwerfungsprotokoll, das nie in den Schlüssel-Wert-Speicher gelangt. Wo möglich, verlangt das Verzeichnis, dass Produzenten dieser Werte ihren Vertrag laut genug deklarieren, dass eine zukünftige Änderung, die ihn verletzt, in Tests fehlgeschlagen wird, bevor sie die Produktion erreicht.
Wie sich das Verzeichnis entwickelt
- Neue Schutzmaßnahmen. Werden hinzugefügt, wenn eine Fehlerklasse erneut auftritt oder ein einzelner Fehler genug gekostet hat, um eine dauerhafte Regel zu rechtfertigen.
- Obsolete Schutzmaßnahmen. Werden im Verzeichnis mit einem "obsolet"-Marker und einem Zeiger auf den Ersatz aufbewahrt, sodass historische Referenzen im Code interpretierbar bleiben.
- Von Arbeitsnotizen hochgestuft. Einige Schutzmaßnahmen beginnen als informelle Regeln in einem Session-Handoff-Dokument und werden ins Verzeichnis aufgenommen, sobald sich ihr Wert bewährt hat.
- Vierteljährliche Überprüfung. Temporäre Lint-Ausnahmen und "bis nächstes Quartal zu erledigen"-Marker werden vierteljährlich überprüft. Alles, das zu alt geworden ist, wird entweder gelöst oder explizit verlängert.
Warum dies veröffentlicht wird
FlareWatch veröffentlicht diese Übersicht statt des vollständigen internen Registers aus zwei Gründen.
- Das interne Register enthält Code-Ebenen-Details (Dateipfade, Schlüssel-Wert-Schemananmen, Incident-Zeitstempel), die für das Team und einen Sicherheitsprüfer mit Code-Zugriff nützlich sind, aber nicht ohne diesen Zugriff veröffentlicht werden sollten.
- Die Kategorien und die Disziplin sind die eigentliche Geschichte. Ein Grant-Reviewer oder Sicherheitsforscher, der FlareWatch bewertet, möchte wissen, welche Art von Projekt es ist, wie ernst es Korrektheit nimmt und wie seine Arbeitsschleife aussieht – nicht, welche Datei Regel #91 enthält.
Forscher, die eine spezifische Sicherheitsmaßnahme diskutieren, eine neue vorschlagen oder eine Lücke melden möchten, können uns gerne unter [email protected] kontaktieren.
Weiterführende Ressourcen
- Architektur – wie FlareWatch aufgebaut ist.
- Sicherheitsfunktionen – Authentifizierung, Autorisierung, Header, Audit-Verlauf.