A web application firewall (WAF) filters HTTP and HTTPS traffic between clients and a web application. It applies rules to requests, for example blocking SQL injection patterns, cross-site scripting payloads or abusive clients, and works at layer 7 rather than just looking at IP addresses and ports.
Why it matters
A WAF can buy time against known exploit patterns, such as an unpatched plugin, and absorb automated scanning. It is a mitigation layer, not a replacement for patching and secure code. It is also a common source of "mystery" errors: legitimate requests blocked as false positives return 403 Forbidden, often with a vendor block page.
Example
Many WAFs are built on the OWASP Core Rule Set. With ModSecurity and nginx you might run in logging mode first:
modsecurity on;
modsecurity_rules '
SecRuleEngine DetectionOnly
Include /etc/modsecurity/crs/crs-setup.conf
';DetectionOnly logs matches without blocking, so you can tune rules before switching to On.
Common mistakes
- Turning on blocking mode with default rules and no tuning, which blocks checkout, login or API calls.
- Blocking monitoring probes. Allowlist your uptime monitor, or checks report a false outage.
- Assuming the WAF makes the origin safe while the origin IP is still publicly reachable and unfiltered.
- Never reviewing blocked-request logs, so false positives linger for months.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.