Ein Entwicklungs-Server gehört auf den Laptop – nicht ins Internet. Trotzdem laufen erstaunlich viele Seiten live im Dev-Modus, weil jemand npm run dev statt eines echten Builds gestartet hat. Das ist kein kosmetisches Problem, sondern eine offene Tür. So erkennst du es – auch bei deiner eigenen Seite.
Warum das passiert
Beim Vibe Coding endet die Anleitung oft bei „starte den Dev-Server, fertig". Genau dieser Befehl landet dann im Deploy oder im Container-Start – statt next build + next start bzw. vite build + statischem Ausliefern. Die Seite sieht identisch aus, verhält sich aber komplett anders.
Woran man ihn von außen erkennt
- Eine offene Hot-Module-Reload-WebSocket-Verbindung (z. B. zu
/_next/webpack-hmroder einem Vite-Client). - Source-Maps sind erreichbar – der komplette, unminifizierte Quelltext liegt offen.
- Ausführliche Fehlerseiten mit Stacktraces, Dateipfaden und Framework-Internas statt einer schlanken Fehlermeldung.
- Verräterische Header oder Dev-Only-Endpunkte, die im Production-Build nicht existieren.
Warum es gefährlich ist
Offene Source-Maps und Stacktraces verraten Angreifern die Struktur, verwendete Bibliotheken und oft Pfade zu sensiblen Endpunkten – die halbe Recon-Arbeit ist damit erledigt. Dazu kommen fehlende Optimierungen: Der Dev-Server ist langsam, hält keine Last und deaktiviert teils Sicherheits-Defaults.
So deployst du richtig
Immer einen echten Production-Build erzeugen und diesen ausliefern: bei Next.js next build gefolgt von next start (oder ein statischer Export), bei Vite vite build und das dist/-Verzeichnis über einen echten Webserver. NODE_ENV=production setzen. Im Zweifel von außen scannen.
In 10 Sekunden prüfen
Der Vibe Check erkennt einen live laufenden Dev-Server an genau diesen Signalen und sagt dir sofort, ob deine Seite im falschen Modus läuft.
Jetzt deine Seite in 10 Sekunden prüfen →