Key Takeaways
- Web apps are the front door: internet-facing, constantly probed, and the most common breach vector. Web log monitoring is foundational SOC coverage.
- Wazuh ingests web server logs (Apache, Nginx, IIS) via the agent, with built-in decoders that parse access and error logs into structured fields.
- The default ruleset detects common web attacks: SQL injection, cross-site scripting, path traversal, command injection, scanner and bot activity, and brute force against login pages.
- WAF integration deepens coverage: forward ModSecurity, Cloudflare, AWS WAF or other WAF logs into Wazuh to correlate blocked attacks with application behaviour.
- Correlation is the win: a probe at the WAF plus an error in the app plus an unusual database query together tell a story no single log tells alone.
Why Web Application Monitoring Is Foundational
For most businesses the web application is the single most exposed asset. It sits on the public internet, accepts untrusted input by design, and is probed continuously by automated scanners and opportunistic attackers. The OWASP Top 10 categories, injection, broken access control, security misconfiguration and the rest, describe attacks that hit production applications every single day.
Web server logs are a rich and underused detection source. Every request leaves a trace: the URL, method, parameters, status code, user agent and source. Attack attempts have recognisable signatures in this data long before they succeed. Monitoring web logs in Wazuh turns that raw stream into detections and an investigative record.
Beyond detection, web log monitoring supports incident response and compliance. When an application incident occurs, the web logs are the primary evidence of what the attacker tried and what the server returned. Centralising them in Wazuh means they are retained, searchable and tamper-resistant rather than sitting on a server an attacker may have compromised.
Ingesting Web Server Logs
Install the Wazuh agent on the web servers and configure it to read the access and error logs. For Apache that typically means the access_log and error_log; for Nginx the access.log and error.log; for IIS the W3C log files. Add a localfile block in the agent configuration pointing at each log with the correct format so the manager knows how to handle it.
Wazuh ships decoders for the common web server log formats, so out of the box it parses access logs into structured fields: source IP, request method, URL, protocol, status code, response size and user agent. If you use a custom log format (many teams add request timing or upstream fields), you will need a matching custom decoder so those fields parse correctly. Test the decoder with the Wazuh log testing tool before relying on it.
Decide retention by value. Access logs are high volume, so apply tiered retention: keep recent data hot for active investigation and age older data to cold storage for the compliance window. Error logs are lower volume and often higher value for security, so retain them generously. Reverse proxies and load balancers in front of the app should also forward their logs, since they often see the original client IP that the backend does not.
Need a Wazuh-Based Managed SOC?
Codesecure deploys and operates Wazuh, TheHive, n8n, Cortex and MISP as a managed SOC. 24x7 named analysts, detection engineering, tuned dashboards and audit-ready compliance reporting. No commercial SIEM licensing.
See Managed SOC →Detecting Web Attacks With the Default Ruleset
The Wazuh ruleset includes a substantial set of web attack detections that work against parsed access and error logs. These map URL and parameter patterns, status code sequences and request characteristics to known attack classes, and they are tagged with the relevant attack group and compliance controls.
Out of the box, Wazuh detects the signatures of SQL injection (UNION, SQL keywords and metacharacters in parameters), cross-site scripting (script tags and event handlers in input), path and directory traversal (dot-dot-slash sequences targeting sensitive files), command injection (shell metacharacters and command chaining), and local and remote file inclusion attempts. It also flags scanner and tool activity by recognising the user agents and request patterns of common automated tools.
Status-code patterns are their own signal. A flood of 404s from one source suggests directory brute forcing or content discovery; a spike of 401 or 403 against an authentication endpoint suggests credential attacks; a sudden run of 500 errors may indicate an attacker probing for an exploitable flaw. Wazuh frequency rules catch these volume-based patterns that no single request reveals.
Integrating WAF Telemetry
A Web Application Firewall sits in front of the application and inspects requests against its own rule set, blocking or flagging malicious traffic. Its logs are a high-quality detection source because the WAF has already done first-pass analysis. Forwarding WAF logs into Wazuh combines that judgement with the rest of your telemetry.
For ModSecurity (the open source WAF that runs with Apache, Nginx or as a standalone), point the Wazuh agent at the ModSecurity audit log. Wazuh can parse ModSecurity's structured output and surface the triggered rule, the matched data and the disposition. For cloud WAFs such as Cloudflare, AWS WAF or Azure, forward the WAF logs through the provider's logging pipeline (for example to object storage or an event stream) and ingest them into Wazuh via the appropriate integration.
The value of WAF logs in Wazuh is not just seeing blocks; it is correlation. A WAF block tells you an attack was attempted and stopped. But a WAF event that was allowed through, followed by an application error and an unusual database query, tells you something got past the perimeter and is worth urgent attention. Centralising WAF and application telemetry in one place is what makes that correlation possible.
Correlating Across the Web Stack
The strongest web application monitoring does not look at any single log in isolation. It correlates the layers: the WAF at the edge, the web server, the application, and the database behind it. Each layer sees part of an attack; together they tell the whole story.
Consider a real sequence. The WAF flags and allows a borderline request. The web server logs a 200 for a URL with suspicious parameters. The application logs an unexpected exception. The database logs an unusual query returning a large result set. Individually each event might be dismissed. Correlated in Wazuh, they describe a probable injection that reached the data tier. Wazuh's rule correlation and the broader stack (feeding alerts into TheHive for case management and n8n for response) let you build and act on these composite detections.
This is why web monitoring should not be deployed as an island. It is one tier of a layered SOC. The web logs catch the probes, the WAF adds judgement, the application logs add context, and the database monitoring catches the impact. Codesecure designs these layers together so detections span the stack rather than guarding one door while the others stand open.
Want Help With Detection Engineering?
Whether you run Wazuh in-house or want a fully managed service, our SOC engineers build custom rules, dashboards and integrations tuned to your environment. ISO/IEC 27001:2022 certified delivery, fixed-fee monthly retainer.
Talk to a SOC Engineer →Tuning and Operating Web Detections
Internet-facing web logs are noisy. The background radiation of the internet, scanners, bots and opportunistic probes, generates a constant stream of low-severity alerts. Without tuning, this noise drowns the analyst queue and trains the team to ignore web alerts entirely, which is the worst outcome.
Tune in two directions. Suppress or downgrade the predictable background noise (well-known scanner user agents hitting endpoints that do not exist, for instance) so it is recorded but not alerted at high severity. At the same time, raise severity on the high-signal events: attacks against your actual authentication and admin endpoints, successful requests (200 status) with attack signatures, and anything that correlates across tiers. The goal is an alert queue where a high-severity web alert genuinely means look now.
Operate with a feedback loop. Each confirmed false positive is a tuning input; each real incident is a chance to ask whether the detection fired early enough. Over the first weeks the false positive rate falls sharply as the rules meet your specific application. Codesecure runs this tuning as part of managed SOC onboarding and revisits it whenever the application changes materially.
Frequently Asked Questions
Which web servers can Wazuh monitor?
Wazuh monitors any web server that writes logs the agent can read, including Apache, Nginx and Microsoft IIS, plus reverse proxies and load balancers. It ships decoders for the common access and error log formats. Custom log formats need a matching custom decoder so the fields parse correctly, which you can test with the Wazuh log testing tool before relying on it.
What web attacks does Wazuh detect out of the box?
The default ruleset detects the signatures of SQL injection, cross-site scripting, path and directory traversal, command injection, file inclusion, and scanner and bot activity, along with status-code patterns like 404 floods (content discovery) and 401/403 spikes (credential attacks). These are tagged with attack groups and compliance controls so they feed dashboards and reports.
Can Wazuh work with a WAF?
Yes, and it is recommended. For ModSecurity, point the agent at the audit log and Wazuh parses the triggered rule and matched data. For cloud WAFs such as Cloudflare, AWS WAF or Azure, forward the WAF logs through the provider's logging pipeline and ingest them into Wazuh. The real benefit is correlating WAF events with web, application and database telemetry.
Will signature detection catch every web attack?
No. Signature detection on web logs catches the noisy, opportunistic majority but will miss careful business-logic abuse that looks like legitimate traffic. That is why web log signatures should be paired with WAF telemetry, application-level logging and cross-tier correlation. Layered monitoring catches what any single layer misses.
How do I stop web alerts from being pure noise?
Tune in both directions. Suppress or downgrade predictable background noise like known scanners hitting nonexistent endpoints, and raise severity on high-signal events such as attacks on your real authentication and admin endpoints, successful requests carrying attack signatures, and anything correlating across tiers. The aim is a queue where a high-severity web alert means investigate now.
Does Codesecure set up web application monitoring?
Yes. Codesecure configures Wazuh agents on your web servers, integrates your WAF, writes any custom decoders your log formats need, builds cross-tier correlation and tunes the detections against your traffic. We deliver across India, Singapore, UAE and Malaysia with ISO/IEC 27001:2022 certified delivery and named OSCP, CEH and CISSP consultants.
Monitor The Front Door Attackers Hit First
Codesecure deploys Wazuh web application monitoring with WAF integration and cross-tier correlation for businesses across India, Singapore, UAE and Malaysia. Tuned OWASP detections, layered coverage, ISO/IEC 27001:2022 certified delivery.
