Running a WAF
A network firewall sees ports and addresses. It cannot see a SQL injection in a perfectly valid HTTP request. That is the gap a web application firewall fills.
What it inspects
A WAF reads the HTTP layer — paths, parameters, headers, bodies — and blocks requests that match known attack patterns: injection attempts, path traversal, common exploit probes. It sits in front of your application, usually in your reverse proxy, and is a different job from the packet firewall and from rate limiting.
Tune it, or it tunes you
Run it in detection mode first and watch what it would have blocked. Real applications do odd-looking things, and a WAF dropped into blocking mode cold will stop legitimate users. Build a short allowlist for your own quirks, then switch to enforcing. Expect to revisit it after every big release.
A layer, not a cure
A WAF buys time against known patterns and noise; it does not fix the vulnerability underneath. Treat it as one layer over code that is still written to be safe, patched on a routine, and run with least privilege. It is the outer wall, not the foundation.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base