You have invested in a powerful Web Application Firewall (WAF) like FortiWeb, believing you have secured your critical web applications against attack. Yet, you discover that a breach has occurred, or a penetration test reveals that common vulnerabilities are still exploitable. The immediate question is: how did this happen? The uncomfortable truth is that a WAF is not a “set and forget” appliance. Its effectiveness is entirely dependent on its configuration.
A poorly configured WAF creates a dangerous false sense of security. It sits on your network, appearing to do its job, while malicious requests slip past unnoticed. These failures are rarely due to a flaw in the WAF itself; instead, they are almost always the result of common misconfigurations, overly relaxed policies, and critical blind spots in monitoring.
This guide will explore the most common reasons why your WAF might not be blocking attacks, with a focus on FortiWeb misconfigurations. We will provide actionable steps to help you audit your setup, tighten your security posture, and ensure your WAF delivers the protection you expect.
Operating in Monitoring Mode Instead of Blocking Mode
One of the most frequent and fundamental errors is leaving your WAF policies in a non-blocking, “detection-only” mode. When you first deploy a WAF, it is common practice to set it to monitor traffic without actively blocking anything. This allows you to observe how it interacts with your application, identify legitimate traffic patterns, and tune out potential false positives before going live.
The problem arises when this “temporary” monitoring phase becomes permanent.
- The Risk: In detection mode, the WAF will log potential attacks, but it takes no action to stop them. You might have a detailed record of an SQL injection attempt, but the malicious request will still be allowed to reach your application server. The WAF acts as a spectator, not a guard.
- How to Check and Fix: In your FortiWeb Server Policy, review the
Actionset for your security profiles. If they are set toAlertorPeriod Block, they are not providing continuous protection. For a production environment, the action should be set toAlert & Deny. This ensures that malicious traffic is logged and blocked in real time.
Overly Permissive or Incomplete Policies
A WAF is only as strong as the rules that govern it. A policy that is too generic or relaxed can be easily bypassed. The goal is to enforce the principle of least privilege, allowing only what is explicitly required for your application to function.
The “Allow All, Deny Some” Mistake
Many administrators start with a policy that allows all traffic and then try to block known bad patterns. This is a flawed approach because you cannot possibly predict every type of attack. A much more secure method is a “positive security model” where you deny all traffic by default and only explicitly allow known-good, well-defined interactions.
The “Any” Object Trap
Using the Any object in security rules is a common shortcut that creates massive security holes. For example, allowing any HTTP method (GET, POST, PUT, DELETE, etc.) when your application only uses GET and POST exposes it to unnecessary risk.
- How to Audit and Tighten:
-
- Review Your Rules: Scrutinise every rule that uses
Any. Can you replace it with specific IP addresses, defined address groups, or specific HTTP methods? - Implement Input Validation: Don’t just rely on attack signatures. Configure strict input validation rules. If a field should only contain numbers, create a rule that blocks any request containing letters or special characters in that field.
- Leverage Auto-Learning: The FortiWeb auto-learning feature is incredibly powerful for building a positive security model. Run it for a representative period to allow it to build a comprehensive profile of your application’s normal behaviour, including all URLs, parameters, and methods. You can then use this learned profile to generate tight security rules that block anything deviating from this known-good baseline.
- Review Your Rules: Scrutinise every rule that uses
SSL/TLS Inspection is Disabled
An ever-increasing majority of web traffic is encrypted with SSL/TLS (HTTPS). If your WAF is not decrypting this traffic, it has zero visibility into the content of the requests. It can only see the source and destination IP addresses, but the actual payload—where threats like SQL injection and Cross-Site Scripting (XSS) hide—is completely invisible.
Failing to enable SSL/TLS inspection is like letting sealed, opaque containers pass through your security checkpoint without looking inside.
- The Challenge: SSL inspection is resource-intensive, requiring the WAF to decrypt, inspect, and then re-encrypt traffic. This can lead to performance concerns, which is why some administrators are hesitant to enable it.
- The Solution:
-
- Install the Correct Certificates: To perform SSL inspection, FortiWeb needs the private key and certificate for your web server. This allows it to act as a trusted man-in-the-middle.
- Enable SSL Inspection on Your Policy: In the Server Policy, you must enable SSL inspection and associate it with the correct certificate.
- Size Your WAF Correctly: Ensure your FortiWeb appliance or VM is sized appropriately to handle the overhead of SSL inspection for your expected traffic volume. It is better to have a correctly sized WAF that inspects all traffic than an undersized one that forces you to bypass security for performance.
Insufficient Logging and Alerting
If your WAF blocks an attack but no one is notified, did it really do its job? Without proper logging and alerting, your security team is flying blind. You have no visibility into the types of attacks targeting your applications, no way to identify trends, and no actionable intelligence to improve your security posture.
A common misconfiguration is to only log blocked events. While useful, this ignores traffic that was permitted, which could include sophisticated attacks that bypassed your rules.
- The Blind Spot: Without comprehensive logs, you cannot effectively troubleshoot issues or conduct forensic analysis after an incident. You won’t know if a successful attack was the result of a misconfigured rule or a new, zero-day threat.
- Best Practices for Logging:
-
- Log Everything: Configure FortiWeb to log both allowed and denied traffic. This provides a complete picture of what is happening.
- Integrate with a SIEM: Forward your FortiWeb logs to a central Security Information and Event Management (SIEM) platform like FortiSIEM. This allows you to correlate WAF events with data from other security tools (like your network firewall and endpoint protection) to identify complex, multi-stage attacks.
- Configure Meaningful Alerts: Don’t just collect logs; act on them. Set up alerts for critical events, such as repeated login failures, high-severity attack detections, or policy violations. These alerts should be sent directly to your security team for immediate investigation.
Not Keeping Signatures and Firmware Updated
The threat landscape is not static; it evolves daily. Attackers constantly develop new techniques, and researchers discover new vulnerabilities. A WAF relying on an outdated set of attack signatures or running on vulnerable firmware is defending against yesterday’s threats.
FortiGuard Labs, Fortinet’s threat intelligence and research team, provides continuous updates to protect against the latest threats. Failing to use this service cripples your WAF’s effectiveness.
- The Risk: Running on an old firmware version may leave the WAF itself vulnerable to exploitation. Using an outdated signature database means you are defenceless against newly discovered attack methods.
- The Fix:
-
- Enable FortiGuard Updates: Ensure your FortiWeb device has a valid FortiGuard subscription and is configured to automatically download and apply the latest WAF signatures, antivirus definitions, and IP reputation lists.
- Schedule Regular Firmware Updates: Establish a process for regularly reviewing and applying firmware updates. This is a critical maintenance task that patches vulnerabilities and often introduces new security features.
Lack of Integration with Threat Intelligence and Other Security Layers
A WAF that operates in isolation cannot provide the depth of protection needed against modern, multi-vector attacks. Without integration with broader security platforms, FortiWeb may detect an attack but fail to contribute to a coordinated response.
The Risk: Attacks often combine multiple stages across endpoints, firewalls, and applications. If FortiWeb alerts stay siloed, your security team cannot correlate events or act quickly on emerging threats.
How to Check and Fix:
-
Integrate with Fortinet Security Fabric: Link FortiWeb with FortiGate, FortiAnalyzer, and FortiSIEM to share logs, alerts, and threat intelligence.
-
Enable Threat Feeds: Subscribe to FortiGuard or other trusted feeds to ensure FortiWeb recognizes the latest malicious IPs and payload patterns.
-
Automated Responses: Configure security fabric automation to block offending IPs or escalate incidents based on FortiWeb’s detections.
Conclusion: From False Security to Active Defence
A Web Application Firewall is a powerful and necessary tool for protecting modern applications, but it is not a magic box. Its value is unlocked through careful configuration, continuous tuning, and diligent monitoring. If your WAF is not blocking attacks, the cause is almost certainly a misconfiguration rather than a product failure.
Take the time to audit your FortiWeb setup. Move policies from “monitor” to “block,” eliminate permissive rules, enable SSL inspection, establish comprehensive logging, and keep your system updated. By treating your WAF as a dynamic and critical part of your security ecosystem, you can transition from a false sense of security to an active, intelligent defense.
Meta Title: Why Your WAF Fails: Common FortiWeb Misconfigurations
Meta Description: Is your WAF not blocking attacks? Discover common FortiWeb misconfigurations like relaxed policies and logging blind spots, and learn how to fix them.