PHP Security: Web Application Firewall (WAF)

The latest release of Devflow CMS (v2.5.0) introduces a major update to the built-in Web Application Firewall (WAF). While the firewall provides protection against common attack patterns, this release focuses on something equally important: customization.

Instead of treating the firewall as a collection of hardcoded rules, developers can now customize, extend, replace, and disable individual detection rules.

A reminder: A Web Application Firewall should never be your primary security mechanism. Secure coding practices—including output escaping, parameterized database queries, CSRF protection, rate limiting, and proper authorization—should always be your first line of defense. The firewall exists to provide an additional layer of protection when malicious requests make it to your application.

Updating Your Configuration

The new release is backwards compatible, but you'll want to update your .config/firewall.php configuration to take advantage of the new features.

The biggest change is the introduction of the new rules configuration section. 

Instead of defining rule groups like this:

<?php

'sql_injection' => [],
'xss' => [],
'rce' => [],

you now configure them using:

<?php

'rules' => [
    'sql_injection' => [
        'enabled' => true,

        'add' => [],
        'remove' => [],
        'replace' => [],
    ],
]

This small change unlocks much greater flexibility.

Rule Customization

Every detection rule can now be customized in one of three ways.

add

<?php

'sql_injection' => [
    'add' => [
        '/my_custom_pattern/i',
    ]
],

Use add when you want to extend the framework's built-in detection.

This is useful when your organization encounters application-specific attack patterns that aren't part of the default rule set.

The default rules remain intact, and your custom rules are evaluated alongside them.

remove

<?php

'xss' => [
    'remove' => [
        '/expression\s*\(/i',
    ],
],

Sometimes a built-in rule is too aggressive for your application.

You can now remove individual signatures directly from your configuration.

This helps reduce false positives while preserving every other built-in rule.

replace

<?php

'file_traversal' => [
    'replace' => [
        '/your_company_pattern/i',
    ],
],

For complete control, replace discards the built-in signatures for a rule group and uses only the rules you provide.

Most applications will never need this option, but organizations with strict security requirements can completely tailor the firewall's behavior.

New WordPress Probe Detection

One of the new rule groups introduced in this release is:

'wordpress_probe'

Although Devflow CMS is not WordPress, internet bots don't know that.

Automated scanners constantly request files or routes such as:

/wp-admin/
/wp-login.php
/wp-content/
/xmlrpc.php

These requests generate unnecessary traffic and log noise.

The new WordPress probe detection identifies these automated scans and can immediately block them before they reach your application.

Improved Notification Configuration

Previous versions accepted a simple array of notifier objects.

The new configuration introduces named notifier configurations while maintaining backwards compatibility.

For example:

<?php

'notifiers' => [
    'email' => [
        'enabled' => false,
    ],

    'slack' => [
        'enabled' => false,
    ],

    new EmailThreatNotifier(),
],

This provides two important improvements.

First, built-in notification channels can now be enabled or disabled using configuration instead of code.

Second, existing applications that register custom ThreatNotifier objects continue to work without modification.

Future releases can add additional notification channels without changing your application code.

Monitoring Mode

Sometimes you want to see what the firewall would block before enforcing it.

That's exactly what monitoring mode is for.

'block' => false,

When enabled, requests continue through the application normally while threats are still logged and notifications are still sent.

This is especially useful after adding custom rules or when evaluating the impact of a new firewall configuration in production.

Once you're satisfied there are no unexpected false positives, simply switch:

'block' => true,

Ignored Paths

The ignored_paths section now includes support for excluding application endpoints from inspection.

For example:

<?php

'ignored_paths' => [
    '/favicon.ico',
    '/robots.txt',
],

Payload Logging

The log_payload option remains available.

'log_payload' => false,

Although enabling payload logging can be extremely helpful during incident investigations, request payloads often contain sensitive information such as passwords, API tokens, payment details, or personal information.

For most production environments, leaving this disabled is the safest choice unless detailed forensic logging is required.

Alert Severity

Notifications can now continue to be filtered by severity.

'alert_min_severity' => 'high',

Supported values are:

• low
• medium
• high
• critical

This allows routine attacks to be logged without overwhelming administrators with notifications while ensuring critical threats receive immediate attention.

Backwards Compatibility

Existing firewall configurations continue to work.

Legacy rule definitions such as:

'sql_injection' => [],
'xss' => [],

are still supported to make upgrading straightforward.

However, new applications should migrate to the rules configuration so they can take advantage of rule customization.

Conclusion

This release isn't about adding another security checkbox—it's about giving developers more control over how the firewall behaves.

The new configuration makes it possible to extend, remove, or replace individual detection rules, gradually roll out new protections using monitoring mode, configure notification channels more cleanly, and better handle the kinds of automated traffic modern PHP applications receive every day. But the firewall can be configured even beyond that. To learn more, check out the updated documentation.

As always, remember that the firewall is designed to complement secure coding practices—not replace them. A well-written application is your first line of defense. The firewall is simply there to help catch what slips through.