Sicherheit für deine Replit-App

„Replit-Sicherheit" sind zwei Dinge, die man auseinanderhalten sollte. Das erste ist der Repl und sein Deployment: wo Geheimnisse leben, wer deine Dateien sieht, welche URL öffentlich ist und welcher Port offenliegt. Das zweite ist der Code, den Replit Agent erzeugt, meist ein Express-Server mit React und einer Postgres-Datenbank, der die klassischen Fehler eines hastig geschriebenen Backends mitbringt. Dieser Guide deckt beides ab, mit einem Block für die Datei, die der Agent bei jeder Anfrage liest, einem Review-Prompt vor dem Deploy und den Prüfungen von außen.

Teil 1: Deinen Repl und dein Deployment absichern

Geheimnisse: der Secrets-Tab, nicht der Code

Replit hat einen Secrets-Manager, der Variablen verschlüsselt speichert und sie dem Prozess als Umgebungsvariablen bereitstellt, ohne dass sie in einer Datei auftauchen. Das ist der einzig richtige Ort für API-Schlüssel, den Verbindungsstring der Datenbank und das Session-Secret. Der übliche Fehler ist, dass der Agent, oder du in Eile, sie in eine .env, eine config.json oder direkt in den Code schreibt. Diese Dateien gehören zum Repl: Sie sind in einem öffentlichen Repl sichtbar, werden beim Fork kopiert und deployed.

Öffentliche Repls und die Entwicklungs-URL

Ein öffentlicher Repl zeigt jedem alle seine Dateien, auch die vergessenen: Backups, eine alte .env, Datenexporte. Bevor du ihn öffentlich machst, prüf den ganzen Baum. Und solange der Repl läuft, antwortet die Entwicklungs-URL .replit.dev jedem, der sie hat; das ist keine private Umgebung, sondern ein Server im Internet mit deinen Testdaten.

Deployments

Das Deployment veröffentlicht die App auf einer .replit.app-Subdomain oder deiner Domain, mit automatischem TLS. Die Umgebungsvariablen des Deployments werden getrennt von denen der Entwicklung konfiguriert, prüf also, dass die Produktion nicht auf die Testdatenbank zeigt. Nur der deklarierte Port liegt offen, aber alles, was dieser Port ausliefert, ist öffentlich: API-Routen, statische Dateien und was der Server versehentlich zurückgibt. Replit setzt keine Sicherheits-Header; die setzt dein Server.

Eingebaute Datenbank und Authentifizierung

Die eingebaute Postgres-Datenbank übergibt ihren Verbindungsstring als Secret; kopiere ihn nie in eine Datei. Nutzt du Replit Auth, verwaltet Replit die Sitzung, und dein Code erhält den bereits identifizierten Nutzer, aber jede Route muss weiterhin prüfen, dass eine Sitzung besteht und dieser Nutzer tun darf, was er verlangt.

Teil 2: Die Fehler, die der Agent in deinen Code einbaut

• Geheimnisse in Dateien. Der OpenAI-Schlüssel oder der Postgres-String in .env, in einer Konstante oder in einer config.json, die statisch ausgeliefert wird.
• API-Routen ohne Authentifizierung. Das Dashboard prüft die Sitzung in React; /api/users antwortet jedem.
• Zu weite statische Ordner. express.static, das auf das Projekt-Root zeigt, liefert package.json, .replit, den Servercode und jede vergessene Datei aus. Und ohne index.html listen manche Server das Verzeichnis auf.
• Debug- und Seed-Routen. /api/debug, /api/seed, /api/reset, zum Testen angelegt und deployed.
• Offenes CORS mit Credentials. cors() ohne Optionen plus Session-Cookies: Jede Website handelt im Namen deiner Nutzer.
• SQL-Abfragen per Verkettung. Ein String, zusammengebaut aus dem, was vom Formular kommt, statt Parametern.
• Datei-Uploads auf die Platte, unverändert ausgeliefert. Jeder Nutzer lädt eine Datei hoch, und jeder Besucher lädt sie per Namen herunter.
• Kein Rate-Limit, keine Header. Ein Endpunkt, der ein kostenpflichtiges Modell ohne Deckel aufruft, und kein einziger Sicherheits-Header.

Ein Block, den der Agent immer anwendet

Replit Agent liest die Datei replit.md deines Projekts als dauerhaften Kontext. Ergänze diesen Abschnitt:

## Sicherheitsregeln
- Schlüssel, der Datenbank-String und das Session-Secret werden aus process.env gelesen und leben im Secrets-Tab. Nie in .env, config.json oder im Code.
- Jede API-Route, die Daten liest oder schreibt, prüft Sitzung und Rechte des Nutzers auf dem Server. Prüfungen in React zählen nicht.
- express.static liefert nur den Build-Ordner des Frontends oder public/ aus, nie das Projekt-Root.
- Keine Debug-, Seed- oder Reset-Routen in Produktion.
- CORS mit einer expliziten Liste von Origins; nie der Platzhalter mit Credentials.
- Alle SQL-Abfragen nutzen Parameter. Jede Formulareingabe wird auf dem Server validiert.
- Hochgeladene Dateien werden außerhalb des öffentlichen Ordners gespeichert und nur nach Rechteprüfung ausgeliefert.
- Sicherheits-Header mit helmet und Rate-Limit auf kostenpflichtigen Routen.

Und die Header in Express, in zwei Zeilen:

import helmet from 'helmet';
app.use(helmet());
app.use(helmet.hsts({ maxAge: 63072000, includeSubDomains: true, preload: true }));

Ein Review-Prompt vor dem Deploy

Prüfe die Sicherheit dieses Projekts und ändere noch nichts. Antworte mit einer Liste:
1. Schlüssel, Verbindungsstrings oder Geheimnisse in Dateien oder im Code, mit Datei und Zeile.
2. API-Routen, die Daten lesen oder schreiben, ohne die Sitzung zu prüfen, sowie Debug-, Seed- oder Reset-Routen.
3. Statisch ausgelieferte Ordner und welche Dateien sie offenlegen.
4. Konfiguration von CORS und Session-Cookies.
5. Per Verkettung gebaute SQL-Abfragen und unvalidierte Eingaben.
6. Wo hochgeladene Dateien gespeichert und wie sie ausgeliefert werden.
7. Ob Sicherheits-Header und ein Rate-Limit existieren.
Schlag für jeden Punkt die exakte Änderung vor und warte auf meine Bestätigung.

Prüf das Ergebnis von außen

curl -sI https://deinedomain.com | grep -iE "strict-transport|x-frame|x-content-type|content-security"
for p in .env .replit package.json config.json .git/config server.js uploads/; do printf "%-14s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://deinedomain.com/$p"; done
curl -s -o /dev/null -w "%{http_code}\n" https://deinedomain.com/api/users

Erwartet: Header vorhanden, 404 für die ganze Dateiliste und 401 oder 403 auf der API-Route ohne Sitzung. Ein 200 bei package.json oder .replit heißt, dass du das Projekt-Root auslieferst. Scanaris führt diese Prüfungen und rund vierzig weitere in 30 Sekunden aus: Es sucht offengelegte Dateien und Verzeichnislisten, Endpunkte, die ohne Sitzung antworten, Geheimnisse im JavaScript, Header, CORS, Cookies und TLS und gibt dir für jeden Fehler einen Fix-Prompt zum Einfügen in den Agent-Chat. Und es kann täglich neu scannen, weil eine Neugenerierung einen bereits behobenen Fehler zurückbringen kann.

Häufige Fragen

Sind die Werte aus dem Secrets-Tab in einem öffentlichen Repl sichtbar?

Nein, Geheimnisse werden nicht angezeigt und beim Fork nicht kopiert. Sichtbar ist alles andere: Dateien, Code und jeder Schlüssel, der darin statt in Secrets steht.

Ist die Entwicklungs-URL privat?

Nein. Solange der Repl läuft, antwortet sie jedem mit dem Link. Nutz sie nicht mit echten Daten und teil sie nicht in der Annahme, nur du könntest sie sehen.

Setzt Replit Sicherheits-Header bei Deployments?

Nein. Es liefert TLS und die Domain, aber die Header sendet dein Server. Bei Express fügt helmet sie in zwei Zeilen hinzu; bei anderen Frameworks deren Gegenstück.