Information checked: 21 July 2026.
A web application firewall and malware scanner can reduce risk, but neither proves that a website is clean or secure. Their value depends on coverage, configuration, monitoring and the ability to respond to findings.
In brief: Use defensive tools as monitored layers within an incident and recovery process.
Understand the different jobs
| Tool | Main job | Cannot reliably do alone |
|---|---|---|
| Network or hosting firewall | Control network traffic and exposed services | Understand application business logic |
| Web application firewall | Filter selected malicious HTTP requests | Repair vulnerable code or stolen accounts |
| Malware scanner | Look for known or suspicious files and behaviour | Guarantee detection of every compromise |
| File-integrity monitoring | Flag unexpected changes | Decide whether every change is malicious |
| Endpoint or server protection | Protect the operating environment | Replace application security and recovery |
Select a service by evidence
- Which traffic and origins are actually covered.
- Whether administrators can see and export logs.
- How false positives are reviewed.
- What happens when the provider is unavailable.
- Who responds to an alert and within what time.
- Whether the origin server can be reached around the protection layer.
Prepare for a positive finding
- Do not delete evidence immediately.
- Limit access and isolate the affected service if necessary.
- Preserve logs, suspicious files and a timeline.
- Reset compromised credentials through a clean device.
- Identify the entry point before declaring the incident closed.
- Restore from a trusted state and monitor closely.
Acceptance check
Run a controlled test alert and confirm that the right person receives enough information to act. Record exclusions and business functions that could be blocked by defensive rules.
Review bypass and ownership
A CDN-based firewall offers limited value if attackers can reach the origin server directly. A scanner is also ineffective if nobody reviews alerts or if an attacker can delete the logs. Document coverage, bypass paths and who can change the rules.
Records to keep
- Protected hostnames and origin restrictions.
- Alert and log-retention configuration.
- False-positive review process.
- Supplier outage and bypass plan.
Owner test: Confirm that the origin is not unintentionally public and run a harmless test that creates a visible alert for the correct responder.
Sources and date checked
This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.