Alleen toegestane HTTP-methoden doorlaten: Nginx blokkeert ongewenste verzoeken met 405/444

Tijdens het tailen van de logs van een webapplicatie komen we soms op dit moment.

  • Ik dacht dat ik alleen GET / POST / PUT / DELETE gebruikte
  • In de logs zie ik een methode die ik nog nooit eerder heb gezien

Bijvoorbeeld PROPFIND, een WebDAV-methode, verschijnt in de logs. De app zal het sowieso behandelen als een “niet-ondersteunde methode”. Maar het belangrijkste is dit:

Moet een hardwerkende applicatie zich toch bezig houden met ruis? Het antwoord is meestal “nee”. Daarom is het schoon om alleen toegestane methoden door te laten en de rest in Nginx te blokkeren.

Waarom moet het in Nginx worden geblokkeerd?

Je kunt het op applicatieniveau blokkeren, maar zodra een verzoek de app bereikt, zijn er al kosten gemaakt.

  • WSGI/ASGI wordt aangeroepen
  • Middleware, logging, authenticatie draaien deels
  • De app-log wordt vervuild, waardoor echte problemen verborgen blijven
  • Bij hoge traffic ontstaat onnodige belasting

Blokkeer je het in Nginx:

  • Direct in de eerste lijn → minimale kosten
  • App-logs blijven schoon → eenvoudiger beheer
  • Aanvalsoppervlak verkleint → onnodige methoden worden geëlimineerd

Kort samengevat:

De app bouwt het product, Nginx fungeert als de poortwachter.

Onbekende methoden in de logs zijn meestal geen “normaal gebruik”

PROPFIND is een typische WebDAV-methode.

  • Een scan die controleert of WebDAV is ingeschakeld
  • Als PUT/MKCOL per ongeluk open staat, probeert de scanner verder te gaan
  • Een lege User‑Agent of een vage HTTP/1.0‑verzoek komt vaak voor

Het belangrijkste punt:

Als onze service die methode niet gebruikt, is het vrijwel zeker geen legitieme traffic. Dus waarom de app laten reageren?

Strategie: een allowlist gebruiken

Nginx als beveiligingsagent die de poort beheert

Het principe is simpel: open alleen wat nodig is, sluit de rest.

  • Standaard webpagina’s/ statische bronnen: meestal GET en HEAD
  • API: alleen POST/PUT/PATCH/DELETE op de noodzakelijke eindpunten

Alle andere methoden (bijv. PROPFIND, MKCOL, LOCK) worden volledig geblokkeerd als we ze niet gebruiken.

405 vs 444: welke respons gebruiken?

Blokkering kan op twee manieren:

1) 405 Method Not Allowed

  • Standaard, duidelijk voor legitieme clients
  • Geeft aan dat de methode niet is toegestaan

2) 444 (Nginx‑specifiek: geen respons, verbinding sluiten)

  • Sluit zonder bericht
  • Geeft minder hints aan scanners/bots
  • Rustig en schoon voor het beheer (verwijdert “ruis”)

In de praktijk:

  • Onzinnige methoden op een publieke site: 444
  • Legitieme clients die per ongeluk een fout maken: 405

Nginx‑configuratie‑voorbeeld: “alleen toegestane methoden” – twee patronen

Hieronder vind je een startpunt dat je meteen kunt kopiëren.

Patroon A) Standaard: alleen GET/HEAD, API extra toestaan

server {
    # ... listen/server_name etc. ...

    # 1) Standaard: web/ statische bestanden alleen GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # of 405
        proxy_pass http://app;
    }

    # 2) API: alleen noodzakelijke methoden
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
  • / is meestal voldoende met alleen GET/HEAD voor pagina’s.
  • /api/ vereist vaak OPTIONS vanwege CORS.

Patroon B) Alleen “vreemde” methoden expliciet blokkeren (lichtgewicht start)

location / {
    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }
    proxy_pass http://app;
}
  • Verwijdert meteen de meest voorkomende “ruis”‑methoden.
  • Op de lange termijn is Allowlist‑methode (Patroon A) veiliger en makkelijker te beheren.

Opmerking: if in Nginx kan riskant zijn, maar voor een eenvoudige “direct return” is het gangbaar. Voor strengere controle kun je limit_except gebruiken.

Conclusie: “Alleen toegestane methoden” maakt beheer eenvoudiger

De kern is simpel:

  • Onbekende methoden zijn meestal geen legitieme traffic
  • Door ze naar de app te sturen, ontstaan extra kosten en rommelige logs
  • Blokkeer in Nginx met 405/444 en laat alleen de noodzakelijke methoden doorgaan

Met één patroon kun je:

  • Minder belasting op de app
  • Schone logs
  • Eenvoudiger beheer