Zo weet je in 5 minuten of je site veilig is

Je hoeft geen beveiligingsexpert te zijn om te weten of je site de meest voorkomende fouten heeft. Met een browser, een terminal en vijf minuten kun je controleren wat een geautomatiseerde aanvaller in de eerste seconden probeert: of het verkeer versleuteld is, of er headers ontbreken, of er sleutels in de code staan, of je API verzoeken van overal accepteert en of er bestanden staan die er niet horen. Deze gids neemt je stap voor stap mee, met het exacte commando, wat elk resultaat betekent en wat je doet afhankelijk van wat je vindt. Aan het eind weet je hoe je prioriteert en wat deze test niet detecteert.

Minuut 1: HTTPS en redirect

Typ je domein met http:// ervoor, zonder de s. Het moet je meteen naar de https://-versie brengen. Vanuit de terminal:

curl -sI http://jouwdomein.com | head -3
curl -sI http://jouwdomein.com/prijzen | head -3

Beide antwoorden moeten een 301 zijn met Location: https://.... Stuurt de tweede niet door, dan dekt je redirect alleen de homepage. Kijk daarna, met https://, of de header Strict-Transport-Security verschijnt: die vertelt de browser nooit meer HTTP te gebruiken. Zit je op Vercel, Netlify of Cloudflare, dan staat de redirect al en moet je HSTS zelf toevoegen. Wat elk detail van het certificaat betekent, lees je in wat je TLS-cijfer echt betekent.

Minuut 2: beveiligingsheaders

curl -sI https://jouwdomein.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

Er zouden minstens vijf regels uit moeten komen. Elke ontbrekende is een bescherming die de browser niet kan toepassen: zonder X-Frame-Options kan je site in een andere worden ingebed om je gebruikers te misleiden; zonder X-Content-Type-Options raadt de browser bestandstypes; zonder Content-Security-Policy draait elk geïnjecteerd script ongeremd. Houd je niet van de terminal, plak je URL dan in de headeranalyzer. De betekenis van elke header staat in HTTP-headers uitgelegd voor mensen.

Minuut 3: geheimen in de JavaScript

Open je site, rechtermuisknop, "Paginabron weergeven". Zoek naar .js om te zien welke scriptbestanden hij laadt, open het belangrijkste en gebruik de zoekfunctie van de browser met deze termen:

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

Vanuit de terminal kun je het in één keer over alle scripts van de homepage doen:

curl -s https://jouwdomein.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://jouwdomein.com$s";; *) u="https://jouwdomein.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Sommige dingen zijn normaal om te vinden: de publieke sleutel van Stripe (pk_live), de anon-sleutel van Supabase of de Firebase-configuratie zijn ontworpen om in de browser te staan. Wat nooit mag verschijnen: sk_live, service_role, AWS-sleutels (AKIA), OpenAI-tokens of alles wat secret heet. Vind je er een, beschouw hem dan als gecompromitteerd en roteer hem voordat je hem uit de code haalt. De volledige lijst staat in geheimen die je app in de browser lekt.

Minuut 4: CORS en cookies

CORS bepaalt welke andere websites vanuit de browser verzoeken aan je API mogen doen. Vraag een van je endpoints op alsof je van een ander domein komt:

curl -sI -H "Origin: https://evil.example" https://jouwdomein.com/api/me | grep -i "access-control"

Antwoordt hij Access-Control-Allow-Origin: https://evil.example of * samen met Access-Control-Allow-Credentials: true, dan kan elke website de data van je gebruikers lezen met hun sessie. De toegestane origin moet de jouwe zijn en alleen de jouwe. Nu je er toch bent, bekijk de cookies in het loginantwoord of in de ontwikkelaarstools van de browser: sessiecookies hebben Secure, HttpOnly en SameSite=Lax of Strict nodig. Details in verkeerd geconfigureerde CORS.

Minuut 5: blootgestelde bestanden

Tools en half afgemaakte deployments laten sporen na. Probeer deze paden en kijk welke code ze teruggeven:

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://jouwdomein.com/$p"
done

Wat je wilt zien is 404 (of 301 naar je foutpagina). Een 200 op .env of .git/config is ernstig: de eerste bevat je inloggegevens en de tweede maakt het mogelijk de volledige broncode te downloaden. Een 200 op swagger.json of api/debug is op zichzelf geen lek, maar geeft een aanvaller de plattegrond van je API.

Bonusminuut: wat de bots zien

Heb je nog een minuut over, bekijk dan /robots.txt en /sitemap.xml: dat ze bestaan, dat ze niet iedereen blokkeren en dat de sitemap alleen pagina's bevat die je geïndexeerd wilt hebben. Het is geen beveiliging in strikte zin, maar een uit de testfase vergeten Disallow: / kost maanden aan ranking.

Hoe je prioriteert wat je vindt

Niet alles weegt even zwaar. Dit is de volgorde die wij gebruiken:

Kritiek, vandaag nog. Een geheime sleutel in de JavaScript; .env of .git toegankelijk; een API die elke origin met credentials accepteert. Roteer, verwijder, sluit. Controleer daarna of iemand het heeft gebruikt.
Hoog, deze week. Geen redirect naar HTTPS; sessiecookies zonder HttpOnly of Secure; debugroutes in productie.
Middel, deze maand. Ontbrekende headers; geen HSTS; certificaat dat binnenkort verloopt zonder automatische vernieuwing.
Laag. Blootgestelde API-documentatie, verwaarloosde robots.txt en sitemap, headers die de serverversie prijsgeven.

Wat deze vijf minuten niet detecteren

Wees eerlijk over de grenzen. Deze test kijkt naar het oppervlak dat iedereen van buitenaf kan zien. Hij controleert niet of je database rijen van andere gebruikers laat lezen (bij Supabase is dat RLS, bij Firebase zijn het de regels), of je afhankelijkheden bekende kwetsbaarheden hebben, of je bedrijfslogica toestaat een betaling over te slaan of of een formulier elke invoer accepteert. Voor het eerste leggen de Supabase-gids en die voor Firebase uit hoe je het test. Voor de rest moet je naar de code kijken, en de checklist vóór de lancering bundelt het essentiële.

Scanaris doet dit en veertig dingen meer in 30 seconden

De vijf stappen hierboven vormen de kern van wat Scanaris controleert, plus een veertigtal tests die niet in vijf minuten passen: elke header apart, geheimen met patronen van tientallen diensten, blootgestelde bestanden met een veel langere lijst, volledige TLS, cookies, CORS op meerdere routes, en bovendien de staat van je SEO en je AI-zichtbaarheid. Voor elke fout krijg je een fix prompt om in Lovable, Bolt, Cursor of v0 te plakken met de exacte wijziging, en het kan de scan elke dag herhalen en je waarschuwen als iets verslechtert. Het zijn allemaal alleen-lezen controles op wat al publiek is op je site.

Veelgestelde vragen

Is het legaal om mijn eigen site zo te scannen?

Ja. Alles hier zijn normale verzoeken die elke browser doet; je leest alleen wat je server toch al aan iedereen antwoordt. Doe het uitsluitend op je eigen domeinen of met toestemming.

En als ik de terminal niet kan gebruiken?

Stappen 1, 3 en 5 kun je vanuit de browser doen (URL's typen en de bron bekijken), stap 2 met de gratis headeranalyzer, en stap 4 is de enige die hem nodig heeft. Of laat een scanner het voor je doen.

Hoe vaak moet ik het herhalen?

Bij elke relevante deployment en minimaal één keer per maand. Met AI gebouwde apps veranderen snel, en een hergeneratie van code kan een fout opnieuw introduceren die je al had opgelost.