Files
VacatureRadar/docs/quality/PRODUCTION_AUDIT_2026-07-27.md
T
Jens 7caea3a1ee
deploy / deploy (push) Canceled after 0s
demo mode
2026-07-27 23:38:37 +02:00

4.6 KiB

Productie-audit — 27 juli 2026

Samenvatting

VacatureRadar heeft al een volwassen functionele en visuele basis. De audit vond geen noodzaak voor een nieuwe frontendarchitectuur; de belangrijkste professionaliseringswinst zat in de grens tussen Django, Nginx Proxy Manager en de Unraid-runtime.

De gerapporteerde DisallowedHost was een symptoom van ontbrekende publieke hostconfiguratie. De publiek zichtbare Django-debugpagina maakte tegelijk duidelijk dat de runtime nog ontwikkelinstellingen gebruikte. Deze release behandelt daarom hostvalidatie, HTTPS-detectie, CSRF, gedeelde rate limiting, readiness en gasttoegang als één productiecontract.

Bevindingen en herstel

Prioriteit Bevinding Risico Herstel
Kritiek Publieke host ontbrak in ALLOWED_HOSTS onbeschikbare publieke route PUBLIC_BASE_URL leidt host en CSRF-origin af; configuratiehelper toegevoegd
Kritiek DEBUG=True was publiek zichtbaar lek van interne paden en implementatiedetails productiehelper zet debug uit; productiecheck stopt bij onveilige configuratie
Hoog HTTPS-origin kon de interne poort 1226 bevatten CSRF-fouten achter poort 443 publieke en interne poort zijn gescheiden in deployscripts
Hoog Secure redirect kon interne healthchecks omleiden container blijft unhealthy na HTTPS-hardening alleen /health/live/ en /health/ready/ zijn intern vrijgesteld
Hoog Loginrate-limiting gebruikte proceslokale cache limiet verschilde per Gunicornworker Redis-cache als gedeelde productiestandaard en readinessdependency
Hoog X-Forwarded-For werd zonder proxyvertrouwen gebruikt IP-spoofing en omzeilbare rate limiting forwarded chain alleen bij expliciet vertrouwde proxy-CIDR
Hoog Gedeelde demo kon mutaties uitvoeren bezoekers beïnvloeden elkaars demo en persistente data server-side read-only middleware, begrensde sessie en zichtbare UI-status
Middel Unraid-documentatie wees naar een andere .env dan Compose wijzigingen werden niet geladen pad gestandaardiseerd op source/.env; override blijft mogelijk
Middel Deployhelper schreef een custom .env, maar Compose kon alsnog de standaardfile lezen productie-instellingen werden stil genegeerd geselecteerd env-bestand wordt nu voor Compose-interpolatie én containeromgeving gebruikt
Middel AIO Compose interpoleerde databasewachtwoord buiten env_file custom env-pad kon een kapotte URL leveren database-URL wordt uitsluitend in de containerentrypoint opgebouwd
Middel Persoonlijke installatie kon geïndexeerd worden onbedoelde vindbaarheid van login en productmetadata robots.txt en X-Robots-Tag standaard op noindex
Middel Runtime startte zonder Django deployment check foutieve securityconfiguratie werd laat ontdekt manage.py check --deploy vóór migraties en processtart
Laag Project- en assetversies liepen uiteen cache- en release-identiteit onduidelijk releaseversie gecentraliseerd op 0.3.12
Laag Overdrachtsarchief bevatte lokale Windows/runtimeartefacten onnodige omvang en risico op secrets of stale state bestaande schone packager en integriteitsmanifest verplicht gebruikt

Bewust niet gewijzigd

  • De server-rendered Django-architectuur blijft behouden.
  • De Stitch Intelligence Cockpit blijft de productiefrontend; er is geen SPA of extern runtime-CDN toegevoegd.
  • De containerpoort blijft op Unraid bereikbaar voor Nginx Proxy Manager. Netwerksegmentatie of firewalling blijft een live infrastructuurtaak.
  • HSTS start conservatief op 300 seconden. Verhoog pas na een geslaagde publieke login-, CSRF- en subdomeincontrole.
  • Zoekmachine-indexering blijft standaard uit omdat dit een persoonlijke installatie is.

Live controles na deployment

  1. Hermaak de container met de bestaande .env.
  2. Controleer intern beide health-endpoints.
  3. Controleer publiek dat HTTP naar HTTPS gaat.
  4. Controleer login en logout.
  5. Voer één echte CSRF-beschermde actie uit met het beheerdersaccount.
  6. Controleer dat het demoaccount geen mutatie kan uitvoeren.
  7. Controleer securityheaders en afwezigheid van een debugpagina.
  8. Controleer in Nginx Proxy Manager dat alleen de proxy de hostpoort kan bereiken.
  9. Maak een back-up en voer een herstel-smoke uit vóór verdere bronautomatisering.

Resterende externe punten

  • De echte Nginx Proxy Manager-configuratie en het proxy-IP/CIDR zijn niet in de repository zichtbaar.
  • De live Unraid-container, database en Redis zijn in deze auditomgeving niet bereikbaar.
  • Een volledige Dockerbuild, publieke TLS-smoke en hersteltest moeten daarom op de doelserver worden uitgevoerd.