Beveiliging voor je Replit-app

"Replit-beveiliging" zijn twee dingen die je beter uit elkaar houdt. Het eerste is de Repl en zijn deployment: waar geheimen leven, wie je bestanden ziet, welke URL publiek is en welke poort open staat. Het tweede is de code die Replit Agent genereert, meestal een Express-server met React en een Postgres-database, die de klassieke fouten van een haastig geschreven backend meebrengt. Deze gids behandelt beide, met een blok voor het bestand dat de Agent bij elk verzoek leest, een reviewprompt vóór het deployen en de controles van buitenaf.

Deel 1: je Repl en je deployment beveiligen

Geheimen: het tabblad Secrets, niet de code

Replit heeft een secretsbeheer dat variabelen versleuteld opslaat en ze als omgevingsvariabelen aan het proces doorgeeft, zonder dat ze in een bestand verschijnen. Het is de enige juiste plek voor API-sleutels, de connectiestring van de database en het sessiegeheim. De gebruikelijke fout is dat de Agent, of jij in de haast, ze in een .env, een config.json of rechtstreeks in de code schrijft. Die bestanden maken deel uit van de Repl: ze zijn zichtbaar in een publieke Repl, worden gekopieerd bij een fork en gedeployed.

Publieke Repls en de ontwikkel-URL

Een publieke Repl toont al zijn bestanden aan iedereen, inclusief de bestanden die je vergat: back-ups, een oude .env, data-exports. Bekijk de hele boom voordat je hem publiek maakt. En zolang de Repl draait, antwoordt de ontwikkel-URL .replit.dev aan wie hem heeft; het is geen privéomgeving, het is een server op internet met je testdata.

Deployments

Een deployment publiceert de app op een .replit.app-subdomein of je eigen domein, met automatische TLS. De omgevingsvariabelen van de deployment configureer je apart van die van de ontwikkeling, dus controleer of productie niet naar de testdatabase wijst. Alleen de poort die je declareert, staat open, maar alles wat die poort serveert, is publiek: API-routes, statische bestanden en wat de server per ongeluk teruggeeft. Replit voegt geen beveiligingsheaders toe; die zet jouw server.

Ingebouwde database en authenticatie

De ingebouwde Postgres-database geeft je zijn connectiestring als geheim; kopieer hem nooit naar een bestand. Gebruik je Replit Auth, dan beheert Replit de sessie en ontvangt je code de al geïdentificeerde gebruiker, maar elke route moet nog steeds controleren of er een sessie is en of die gebruiker mag doen wat hij vraagt.

Deel 2: de fouten die de Agent in je code stopt

• Geheimen in bestanden. De OpenAI-sleutel of de Postgres-string in .env, in een constante of in een config.json die als statisch bestand wordt geserveerd.
• API-routes zonder authenticatie. Het dashboard controleert de sessie in React; /api/users antwoordt iedereen.
• Te brede statische mappen. express.static dat naar de projectroot wijst, serveert package.json, .replit, de servercode en elk vergeten bestand. En zonder index.html tonen sommige servers de mapinhoud.
• Debug- en seedroutes. /api/debug, /api/seed, /api/reset, aangemaakt om te testen en gedeployed.
• Open CORS met credentials. cors() zonder opties plus sessiecookies: elke website handelt namens je gebruikers.
• SQL-query's via concatenatie. Een string opgebouwd uit wat uit het formulier komt in plaats van parameters.
• Bestandsuploads naar schijf, ongewijzigd geserveerd. Elke gebruiker uploadt een bestand en elke bezoeker downloadt het op naam.
• Geen rate limit, geen headers. Een endpoint dat een betaald model aanroept zonder plafond, en geen enkele beveiligingsheader.

Een blok zodat de Agent het altijd toepast

Replit Agent leest het bestand replit.md van je project als permanente context. Voeg deze sectie toe:

## Beveiligingsregels
- Sleutels, de databasestring en het sessiegeheim worden gelezen uit process.env en leven in het tabblad Secrets. Nooit in .env, config.json of de code.
- Elke API-route die data leest of schrijft, controleert de sessie en de rechten van de gebruiker op de server. Controles in React tellen niet.
- express.static serveert alleen de buildmap van de frontend of public/, nooit de projectroot.
- Geen debug-, seed- of resetroutes in productie.
- CORS met een expliciete lijst van origins; nooit de wildcard met credentials.
- Alle SQL-query's gebruiken parameters. Alle formulierinvoer wordt op de server gevalideerd.
- Geüploade bestanden worden buiten de publieke map opgeslagen en alleen na rechtencontrole geserveerd.
- Beveiligingsheaders met helmet en een rate limit op routes die geld kosten.

En de headers in Express, in twee regels:

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

Een reviewprompt vóór het deployen

Beoordeel de beveiliging van dit project en verander nog niets. Antwoord met een lijst:
1. Sleutels, connectiestrings of geheimen in bestanden of in de code, met bestand en regel.
2. API-routes die data lezen of schrijven zonder de sessie te controleren, en debug-, seed- of resetroutes.
3. Mappen die als statisch worden geserveerd en welke bestanden ze blootstellen.
4. Configuratie van CORS en sessiecookies.
5. SQL-query's opgebouwd via concatenatie en ongevalideerde invoer.
6. Waar geüploade bestanden worden opgeslagen en hoe ze worden geserveerd.
7. Of er beveiligingsheaders en een rate limit bestaan.
Stel voor elk punt de exacte wijziging voor en wacht op mijn bevestiging.

Controleer het resultaat van buitenaf

curl -sI https://jouwdomein.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://jouwdomein.com/$p"; done
curl -s -o /dev/null -w "%{http_code}\n" https://jouwdomein.com/api/users

Verwacht: headers aanwezig, 404 op de hele bestandslijst en een 401 of 403 op de API-route zonder sessie. Een 200 op package.json of .replit betekent dat je de projectroot serveert. Scanaris voert deze controles en zo'n veertig andere uit in 30 seconden: het zoekt blootgestelde bestanden en mapvermeldingen, endpoints die zonder sessie antwoorden, geheimen in het JavaScript, headers, CORS, cookies en TLS, en geeft je voor elke fout een fix prompt om in de Agent-chat te plakken. En het kan elke dag opnieuw scannen, want een hergeneratie kan een al opgeloste fout terugbrengen.

Veelgestelde vragen

Zijn de waarden uit het tabblad Secrets zichtbaar in een publieke Repl?

Nee, geheimen worden niet getoond en niet gekopieerd bij een fork. Wat wel zichtbaar is, is al het andere: bestanden, code en elke sleutel die daarin staat in plaats van in Secrets.

Is de ontwikkel-URL privé?

Nee. Zolang de Repl draait, antwoordt hij iedereen met de link. Gebruik hem niet met echte data en deel hem niet in de veronderstelling dat alleen jij hem ziet.

Zet Replit beveiligingsheaders op deployments?

Nee. Het levert TLS en het domein, maar de headers worden door jouw server verstuurd. Met Express voegt helmet ze in twee regels toe; met andere frameworks hun equivalent.