Application Security, WAF, and OWASP form an interconnected defense strategy for web applications. OWASP (Open Web Application Security Project) provides the framework for identifying critical vulnerabilities through resources like the OWASP Top 10, while WAFs act as the protective layer that detects and blocks attacks targeting these vulnerabilities in real-time.

Web Application Firewalls (WAFs) are the first line of defense against sophisticated web-based attacks. By implementing comprehensive OWASP-based detection rules across your WAF infrastructure and sending logs to Coralogix, organizations can unlock deeper security insights through integrated log analytics, real-time alerting, and threat intelligence capabilities. Coralogix enables faster threat detection through advanced parsing and indexing, customizable dashboards, and automated alerts that provide security teams with early warning across critical web application attack vectors.

Understanding the Modern WAF Security Landscape

As web applications become increasingly complex and critical to business operations, they also become prime targets for attackers. The OWASP Core Rule Set provides a standardized framework for detecting and preventing common web application attacks. Whether you’re running AWS WAF, Akamai WAF, F5 WAF, or Cloudflare WAF, implementing consistent detection rules across your infrastructure is essential for comprehensive security coverage.

Modern WAFs generate vast amounts of security telemetry, capturing every request, response, and potential threat. However, raw WAF logs alone are insufficient. Organizations need sophisticated detection rules that can identify attack patterns, distinguish false positives from genuine threats, and provide actionable intelligence to security teams.

The detection rules outlined in this article focus on the most critical OWASP-based attack vectors:

• Cross-Site Scripting (XSS): Client-side code injection attempts
• SQL Injection: Database manipulation and unauthorized access
• Remote Code Execution (RCE): System-level command execution
• PHP Injection: Server-side code execution via PHP
• Server-Side Template Injection (SSTI): Template engine exploitation
• Server-Side Request Forgery (SSRF): Internal resource access via metadata services

Key Detection Rules for Enterprise WAF Deployments

Cross-Site Scripting (XSS) Payload Detection

Overview

Cross-site scripting remains one of the most prevalent web application vulnerabilities. This detection rule identifies XSS attempts by searching for HTML/script markers and malicious payloads within query parameters and URIs. It focuses specifically on events that were allowed, accepted, or logged highlighting inputs that reached the application layer and represent potential successful injection attempts.

Detection Logic

The rule monitors for common XSS indicators including:

• HTML tags: <script>, <svg>, <iframe>, <object>
• Event handlers: onload=, onerror=, onclick=, onmouseover=
• JavaScript functions: alert(), prompt(), eval()

These patterns are examined in both URL-encoded and standard formats across query strings and URI paths.

Security Impact

Successful XSS exploitation enables attackers to:

• Execute arbitrary JavaScript in victim browsers
• Steal session cookies and authentication tokens
• Perform actions on behalf of authenticated users
• Deliver secondary payloads and drive-by compromises
• Escalate privileges within web applications
• Pivot to further attacks against users or services

Mitigation Strategy

Security teams should immediately block or rate-limit offending source IPs at the WAF or reverse proxy layer. Review application access logs and user sessions for signs of successful exploitation. For stored XSS, identify and remove malicious content from the database. Update WAF rules to block the specific payload patterns observed, and implement content security policies (CSP) to prevent script execution from unauthorized sources.

MITRE ATT&CK Mapping: TA0003 (Persistence), T1059 (Command and Scripting Interpreter)

SQL Injection Attack Detection

Overview

SQL injection attacks attempt to manipulate backend databases by injecting malicious SQL code into application inputs. This comprehensive detection rule identifies suspicious SQL keywords, function calls, and common payload patterns across multiple database engines including MySQL, PostgreSQL, MSSQL, and Oracle.

Detection Logic

The rule detects a wide range of SQLi techniques:

• Union-based injection: UNION SELECT statements for data exfiltration
• File operations: load_file(), into outfile, pg_read_file()
• System commands: xp_cmdshell, exec master
• Information gathering: Queries against information_schema
• Error-based extraction: updatexml(), extractvalue()
• Time-based blind SQLi: sleep(), benchmark() functions
• Obfuscation techniques: Hex encoding (0x), SQL comments (–, /*)
• Stacked queries: Multiple statements separated by semicolons

Security Impact

Successful SQL injection can result in catastrophic security breaches:

• Unauthorized access to sensitive data (credentials, PII, financial records)
• Data modification or deletion
• Authentication bypass and privilege escalation
• Remote code execution through database-specific commands
• Complete environment compromise enabling lateral movement
• Long-term persistence through backdoor accounts

Mitigation Strategy

Immediately investigate and block offending IP addresses at the WAF. Review correlated logs for signs of successful exploitation and contain any compromised systems. Long-term mitigation requires implementing parameterized queries and prepared statements throughout the application codebase. Enforce strict input validation on the server side, apply least-privilege principles to database service accounts, and conduct regular security audits and penetration testing to identify injection vectors before attackers do.

MITRE ATT&CK Mapping: TA0002 (Execution), T1059 (Command and Scripting Interpreter)

Remote Code Execution (RCE) Detection

Overview

This high-priority detection rule identifies requests containing patterns that suggest remote command execution or attempts to invoke system shells and processes. These patterns are commonly observed in web shell uploads, template exploitation (OGNL, Struts), and command injection attacks.

Detection Strategy

The rule flags requests containing:

• Unix/Linux shells: /bin/sh, /bin/bash
• Windows shells: powershell.exe, cmd.exe
• Programming language execution: java.lang.Runtime.exec(), ProcessBuilder()
• System functions: Process.spawn(), system(), exec()
• Command execution indicators: Backticks, process invocation syntax

Security Impact

Successful RCE represents one of the most severe security breaches. Attackers who achieve code execution can:

• Run arbitrary commands on application servers
• Access, modify, or exfiltrate sensitive data
• Install persistent backdoors and malware
• Pivot laterally across the internal network
• Establish command-and-control channels
• Launch subsequent attacks against infrastructure

Mitigation Strategy

Configure the WAF to require high-confidence matches by combining multiple indicators rather than triggering on single patterns. Maintain aggressive patch management for web frameworks and dependencies many RCE exploits target known vulnerabilities. Enforce strong input validation and output encoding across all application layers. Run web services with least-privilege accounts that cannot execute system commands. Implement application-layer sandboxing where possible, and maintain robust logging to detect successful exploitation attempts.

MITRE ATT&CK Mapping: TA0002 (Execution), T1190 (Exploit Public-Facing Application)

PHP Code Injection Detection

Overview

PHP injection attacks attempt to execute malicious PHP code through vulnerable application endpoints. This detection rule identifies both server-side and client-side code execution attempts, including encoded payloads that bypass basic filtering.

Detection Logic

The rule searches for:

• Dangerous PHP functions: eval(), assert(), base64_decode(), system(), exec(), passthru(), popen(), proc_open()
• PHP tags: <?php, <?= (including URL-encoded variants %3C%3Fphp)
• HTML entity-encoded tags: &#x3c;?
• Combined payload patterns: base64_decode() + eval() chains

Security Impact

PHP injection can lead to complete server compromise. Successful attacks enable:

• Remote code execution with web server privileges
• Web shell installation for persistent access
• Database credential theft from configuration files
• File system access and manipulation
• Privilege escalation through vulnerable SUID binaries
• Lateral movement within the hosting environment

Mitigation Strategy

Application hardening is critical: never use eval() or assert() with user-controlled data, validate and canonicalize all inputs, and apply context-appropriate output encoding. Configure PHP with disable_functions to prevent execution of dangerous functions. Enforce least privilege for web processes and isolate secrets using environment variables or secure vaults rather than configuration files. Tune WAF rules to block both raw and URL-encoded payloads while maintaining separate allow-lists for legitimate static assets and query patterns.

MITRE ATT&CK Mapping: TA0002 (Execution), T1059 (Command and Scripting Interpreter)

Server-Side Template Injection (SSTI) Detection

Overview

Server-side template injection exploits vulnerabilities in template engines such as Jinja2, Twig, Velocity, Handlebars, and EJS. Attackers inject malicious expressions that break out of the template context and execute arbitrary code on the server.

Detection Logic

The rule identifies common SSTI patterns:

• Expression syntax: ${} template variables
• Function invocation: (), .call() method access
• Object traversal: -> property access operators
• Prototype pollution: [prototype] access attempts

These patterns appear in query parameters or URIs when attackers attempt to manipulate template rendering.

Security Impact

SSTI allows attackers to escape the intended template scope and access the underlying execution environment. This leads to:

• Arbitrary code execution on the backend server
• Access to sensitive application variables and configuration
• Data leakage through template context exposure
• Privilege escalation through object manipulation
• Full remote code execution capabilities
• Compromise of confidentiality, integrity, and availability

Mitigation Strategy

Implement strict input validation before passing data to template engines. Use allow-lists for acceptable variables and avoid rendering untrusted input directly. Configure template engines in restricted or sandboxed mode when available. Implement proper separation between template code and user data. Consider using logic-less template engines that limit code execution capabilities. Regularly audit template usage across the application and conduct security reviews of template-rendering code paths.

MITRE ATT&CK Mapping: TA0002 (Execution), T1190 (Exploit Public-Facing Application)

SSRF Metadata Service Access Detection

Overview

Server-Side Request Forgery (SSRF) attacks exploit applications that fetch remote resources based on user input. This detection specifically targets attempts to access cloud metadata services a critical attack vector in cloud environments that can expose sensitive credentials and configuration.

Detection Logic

The rule monitors for requests targeting:

• AWS metadata service: 169.254.169.254, latest/meta-data
• GCP metadata service: metadata.google.internal
• Loopback addresses: \x7f, 0x7f, [::] (various encoding schemes)

Security Impact

Successful SSRF exploitation against metadata services represents a severe cloud security breach:

• Exposure of AWS IAM role credentials
• Theft of GCP service account tokens
• Access to Azure managed identity tokens
• Privilege escalation using legitimate cloud credentials
• Lateral movement across cloud resources
• Full account takeover in extreme cases

Mitigation Strategy

Implement defense-in-depth for SSRF prevention. At the cloud level, enforce IMDSv2 (AWS) or equivalent secure metadata service access that requires session tokens and blocks unauthenticated queries. At the application level, rigorously sanitize and validate all user-supplied input used in server-side requests. Maintain explicit deny-lists for internal IP ranges (169.254.0.0/16, 127.0.0.0/8, ::1/128) and known metadata service domains. Use network segmentation to prevent application servers from reaching metadata services. Implement egress filtering to restrict outbound connections from application servers.

MITRE ATT&CK Mapping: TA0001 (Initial Access), T1190 (Exploit Public-Facing Application)

Enhanced Visibility and Analytics with Coralogix

Deploying these detection rules across AWS WAF, Akamai WAF, F5 WAF, and Cloudflare WAF provides comprehensive coverage, but the true value emerges when WAF logs are centralized and analyzed through a platform like Coralogix. By streaming WAF logs to Coralogix, organizations gain:

Advanced Log Analytics

• Parsing and indexing that makes massive WAF log volumes searchable in seconds
• Pattern recognition across multiple WAF platforms for unified threat visibility
• Historical analysis to identify attack trends and campaign persistence
• Query optimization for complex threat hunting across distributed WAF infrastructure

Real-Time Threat Detection

• Anomaly detection algorithms that identify unusual attack patterns and novel payloads
• Automated alerting with customizable thresholds and severity levels
• Threat intelligence enrichment correlating detected attacks with known threat actors and campaigns
• Multi-stage attack correlation linking initial probes to subsequent exploitation attempts

Security Operations Efficiency

• Centralized dashboards displaying attack metrics across all WAF platforms
• Incident response acceleration through correlated log analysis
• False positive reduction using machine learning to tune detection accuracy

• Total allowed/blocked requests across all WAF platforms
• Attack type distribution (XSS, SQLi, RCE, etc.)
• Geographic distribution of attack sources
• Top targeted endpoints and applications
• Time-series graphs showing attack volume trends
• Top offending source IPs with associated attack patterns

Implementation Best Practices

Multi-WAF Standardization

When deploying these detection rules across different WAF platforms, maintain consistent naming conventions, severity classifications, and alert configurations. This standardization enables security teams to develop unified playbooks and response procedures regardless of which WAF platform triggers the alert.

Tuning and Optimization

Initial deployment will generate false positives. Establish a tuning period where alerts are logged but not immediately blocked. Analyze patterns, identify legitimate traffic that triggers rules (such as security scanners, monitoring tools, or specific business workflows), and implement precise exclusions. The queries provided include common exclusion patterns for advertising trackers, transaction IDs, and authentication tokens expand these based on your environment.

Performance Considerations

Complex regex patterns in detection rules can impact WAF performance. Monitor rule evaluation latency and optimize patterns when necessary. Consider implementing sampling for high-volume endpoints while maintaining full coverage for critical authentication and data entry points.

Continuous Improvement

Threat landscapes evolve constantly. Schedule regular reviews of detection rules, incorporating new attack patterns, emerging vulnerabilities, and lessons learned from incidents. Subscribe to OWASP updates and security advisories relevant to your WAF platforms.

Optimization Based on Insights

By leveraging comprehensive WAF log analytics through Coralogix, security teams can:

• Identify attack campaigns by correlating patterns across multiple detection rules
• Prioritize remediation efforts based on the most frequently targeted applications
• Optimize WAF rules by analysing false positive rates and detection gaps
• Inform application security by sharing attack intelligence with development teams
• Demonstrate compliance with detailed audit trails and security metrics
• Predict future threats by analysing attack trend data and seasonal patterns

Conclusion

Web application security requires a multi-layered defence strategy, and WAFs serve as a critical control point for detecting and preventing attacks before they reach application logic. The six enterprise-grade OWASP detection rules outlined in this article provide comprehensive coverage against the most dangerous web application attack vectors: XSS, SQL injection, RCE, PHP injection, SSTI, and SSRF.

By implementing these rules consistently across AWS WAF, Akamai WAF, F5 WAF, and Cloudflare WAF, and centralizing log analysis through Coralogix, organizations achieve unified visibility, accelerated threat detection, and enhanced security operations efficiency. The combination of robust detection rules and advanced analytics capabilities empowers security teams to stay ahead of sophisticated attackers and protect critical web applications against evolving threats.

Remember that detection is only the first step effective web application security requires continuous monitoring, regular tuning, incident response readiness, and ongoing collaboration between security, development, and operations teams to address vulnerabilities at their source.