Sicherheitsleitfaden
Web3-Sicherheitscheckliste: 15 Schritte zum Schutz Ihres Smart Contracts
Eine umfassende, umsetzbare Checkliste von Zugriffskontrolle bis Monitoring — damit Schwachstellen auffallen, bevor Angreifer sie finden.
Sicherheitscheckliste vor dem Deployment
Diese 15 Checks abschließen, bevor ein Smart Contract aufs Mainnet geht.
Rollenbasierte Zugriffskontrolle umsetzen
OpenZeppelins AccessControl oder Ownable2Step statt roher Adressvergleiche nutzen. Getrennte Rollen für Admin, Operator und Pauser definieren. Niemals tx.origin zur Autorisierung verwenden.
Gegen Reentrancy absichern
Das Pattern Checks-Effects-Interactions auf alle externen Calls anwenden. ReentrancyGuard für Funktionen, die ETH transferieren oder mit unsicheren Contracts interagieren. Mit bewusst bösartigen Callback-Contracts testen.
Alle externen Eingaben validieren
Nulladressen, Overflow-Werte, leere Arrays und Out-of-Range-Parameter an den Funktionseingängen prüfen. Niemals darauf vertrauen, dass Caller sinnvolle Inputs liefern — Constraints on-chain durchsetzen.
Integer-Arithmetik sicher behandeln
Solidity 0.8+ hat eingebaute Overflow-Checks, unchecked-Blöcke umgehen sie. Jeden unchecked-Block auf Overflow/Underflow prüfen. Division durch Null und Präzisionsverlust in Fixed-Point-Mathematik im Blick behalten.
Oracle-Abhängigkeiten absichern
Zeitgewichtete Durchschnittspreise (TWAP) oder mehrere Oracle-Quellen gegen Flash-Loan-Manipulation. Staleness-Checks, Mindest-Antwortschwellen und Fallback-Logik bei Oracle-Ausfällen ergänzen.
Compiler-Version festnageln und prüfen
Die Solidity-Version mit konkretem Pragma pinnen (z. B. 0.8.20) statt schwebender Pragmas (^0.8.0). Alle Contracts im Projekt mit derselben Version kompilieren, um subtile Verhaltensunterschiede zu vermeiden.
Upgrade-Angriffsfläche minimieren
Bei upgradebaren Proxys die Upgrade-Autorität mit Timelocks und Multisig-Governance beschränken. Kollisionen im Storage-Layout verhindern. Prüfen, ob Upgradeability wirklich nötig ist — immutable Contracts sind einfacher zu durchdenken.
Not-Aus-Mechanismen einbauen
Pausierbarkeit für kritische Operationen. Den Pause-Mechanismus so gestalten, dass er nicht zur Zensur missbraucht werden kann, aber bei laufenden Exploits stoppt. Testen, dass Pause wirklich alle kritischen Pfade blockiert.
Gegen Front-Running schützen
Commit-Reveal-Schemata, private Mempools (Flashbots Protect) oder Deadlines für zeitkritische Operationen. Den extrahierbaren Wert in pending Transactions minimieren.
Token-Approval-Muster prüfen
Unendliche Approvals möglichst vermeiden. EIP-2612 Permit für gaslose Approvals. Race Conditions bei Approvals prüfen und decreaseAllowance nutzen statt approve(0) gefolgt von approve(newAmount).
Mit realistischen Fork-Simulationen testen
Integrationstests gegen Mainnet-Forks, um Probleme mit echten Token-Balances, Pool-Zuständen und Oracle-Werten zu finden. Hardhat und Foundry unterstützen Fork-Tests — damit echte Deployment-Bedingungen simulieren.
Gas-Optimierung gegen Sicherheit abwägen
Gas-optimierter Code kann subtile Sicherheitslücken einführen. Niemals Sicherheitschecks sparen, um Gas zu sparen. Jeden unchecked-Block oder Assembly-Einsatz mit expliziter Sicherheitsbegründung dokumentieren.
Quellcode im Block-Explorer verifizieren
Quellcode direkt nach dem Deployment auf Etherscan oder dem jeweiligen Explorer veröffentlichen und verifizieren. Das ermöglicht öffentliche Prüfung und schafft Vertrauen. Der verifizierte Source muss exakt dem deployed Bytecode entsprechen.
Monitoring und Alerting aufsetzen
On-Chain-Monitoring vor dem Launch, nicht danach. Ungewöhnliche Transfermuster, Privilege Escalation, Governance-Proposals und Parameteränderungen beobachten. Tools wie FinGuards 24/7-Monitoring-Schicht fangen aktive Exploits in Echtzeit.
Unabhängiges Sicherheitsaudit einholen
Interne Reviews sind nötig, aber nicht genug. Einen unabhängigen Auditor beauftragen, der Ihren Contract in einer Sandbox zu exploitieren versucht. Exploit-Belege für Findings verlangen, nicht nur theoretische Risikolisten.
Häufige Schwachstellen im Blick behalten
Diese Schwachstellenklassen machen den Großteil der DeFi-Exploits 2024–2025 aus.
Reentrancy-Angriffe
Die klassischste Smart-Contract-Schwachstelle. Angreifer treten in eine Funktion ein, bevor der erste Call endet, und leeren Mittel über rekursive Calls. Der DAO-Hack 2016 verlor 60 Mio. USD an diesem Muster.
Oracle-Manipulation
Angreifer nutzen Flash Loans, um On-Chain-Preise kurz zu verzerren, und exploitieren Protokolle, die auf Spotpreise setzen. Seit 2020 der führende Exploit-Vektor in DeFi.
Fehler in der Zugriffskontrolle
Fehlende oder falsche Rechteprüfungen an privilegierten Funktionen — jeder kann Admin-Ops aufrufen, Parameter ändern oder Mittel abziehen. Oft durch unvollständige Modifier-Abdeckung.
Flash-Loan-Exploits
Atomar große Beträge leihen, um Governance-Votes, Pool-Ratios oder Preismechanismen in einer einzigen Transaktion zu manipulieren. Abwehr braucht zeitgewichtete Werte und Multi-Block-Bestätigung.
Logikfehler in Geschäftsregeln
Falsche Umsetzung von Lending-Zinsen, Reward-Berechnungen oder Liquidationsschwellen. Diese Bugs sind protokollspezifisch — deshalb reichen automatisierte Tools allein nicht; menschliches Reasoning findet Designfehler.
Testanforderungen
Der Mindeststandard, bevor ein Smart Contract aufs Mainnet geht.
Unit-Tests (90 %+ Abdeckung)
Jede public- und external-Funktion braucht positive und negative Testfälle. Mindestens 90 % Branch-Coverage. Mit Foundrys forge coverage oder Hardhat-Coverage-Plugins messen.
Integrationstests auf Mainnet-Forks
Den vollen Deployment-Flow auf einem geforkten Mainnet-Zustand testen. Interaktionen mit DEX-Pools, Lending-Protokollen und Oracles mit echten On-Chain-Daten prüfen.
Fuzz-Tests mit Property-Invarianten
Invarianten definieren (z. B. Total Supply nie über dem Cap, User-Balance nie negativ) und einen Fuzzer tausende zufällige Inputs erzeugen lassen. Foundry und Echidna sind führende Tools dafür.
Formale Verifikation für kritische Pfade
Bei hochwertigen Contracts mit signifikantem TVL formale Verifikation (Certora, Solidity SMTChecker) nutzen, um mathematisch zu beweisen, dass kritische Eigenschaften für alle möglichen Inputs gelten.
Häufig gestellte Fragen
Wie lange dauert diese Checkliste?
Bei einem gut strukturierten Projekt mit bestehender Testabdeckung rechnen Sie mit 2–5 Tagen für alle 15 Punkte. Bei Nullstart 1–2 Wochen für Zugriffskontrolle, Testinfrastruktur und Monitoring.
Können automatisierte Tools eine manuelle Sicherheitsprüfung ersetzen?
Automatisierte Tools (statische Analyzer, Fuzzer, formale Verifikation) treffen bekannte Schwachstellenmuster effizient, verpassen aber Business-Logic-Fehler, ökonomische Designprobleme und neue Angriffsvektoren. Am besten: Automatisierung für Breite plus Expertenreview für Tiefe — genau so arbeitet FinGuards 7-Schichten-Pipeline.
Was ist der wichtigste einzelne Punkt auf dieser Liste?
Wenn Sie nur eines tun können: ein unabhängiges Sicherheitsaudit (#15). Ein erfahrener Auditor trifft die meisten übrigen Punkte in seiner Prüfung. Sich aber allein aufs Audit zu verlassen, ohne die anderen Punkte umzusetzen, erzeugt unnötige Arbeit und Risiko.
Diese Checkliste vor oder nach dem Audit?
Davor. Wer die Liste abhakt, lässt den Auditor tiefe, nicht offensichtliche Issues finden statt Hygieneprobleme markieren. Das gibt mehr Wert pro ausgegebenem Dollar. Wie das Haus putzen, bevor der Inspektor kommt.
Bereit für ein professionelles Audit?
Checkliste abschließen, dann FinGuards 7-Schichten-KI Ihre Arbeit mit echten Sandbox-Exploits verifizieren lassen.