How Ignite WAF works.

An overview of the rule engine, rate limiting, and security auditing — written for operators setting up or tuning a live install.

00

Evaluation deployment

Start a 14-day evaluation to download the package and receive a trial code. Deploy the package to a non-production Lucee/CFML environment first, then use the guarded installer to create the required database tables and seed baseline rules.

Before deployment: confirm a supported database is available, back up any existing application files, and keep the installer out of the public webroot except while a trusted administrator is running it.
01

Getting started

Ignite WAF installs directly into your Lucee/CFML application. Once installed, it hooks into your application's request lifecycle so every inbound request is evaluated before it reaches your app code — no separate proxy or DNS change required.

Installation runs through a guarded installer that's disabled by default. Enabling it creates the core database tables and seeds the default rule set, so a fresh install starts with sensible baseline protection rather than an empty rule table.

Note: the installer only runs when explicitly enabled — it will not create or alter tables on a normal request.
02

Rules engine

Every request is evaluated against four rule types, in order. The first rule that denies a request stops evaluation there — later stages don't run.

  • IP rules — allow or deny by exact address or CIDR range.
  • Signature rules — regex pattern matching against known attack strings (path traversal, SQL injection fragments, common exploit probes).
  • User-agent rules — block known scraper and bad-bot signatures.
  • Path rules — deny requests to specific paths, useful for blocking probes against endpoints that don't exist on your install (like default CMS admin paths).

Rules are scoped per site, so a rule you add for one tenant doesn't affect any other site on the same install.

03

Rate limiting (velocity jail)

Beyond the rule engine, Ignite WAF tracks request volume per IP in a rolling window. An IP that crosses the configured threshold is automatically jailed — its requests get denied until the window rolls forward or an operator releases it manually from the admin panel.

This catches request floods and brute-force attempts that wouldn't match a specific signature or path rule.

04

CSP Security Audit

The CSP Security Audit fetches your site's live Content-Security-Policy header and checks it directive-by-directive — presence, default-src, script-src, unsafe-inline/unsafe-eval usage, object-src, frame-ancestors, and whether the policy is enforced or report-only, across 40+ individual checks.

Results are scored A–F. You can run an audit on demand from the admin panel, or schedule it to run automatically per site — scheduled runs can email the result to your team.

05

Quick Scan

Quick Scan is a separate, broader check — it isn't a CSP-specific audit. It covers TLS configuration, cookie flags, CORS policy, clickjacking protection, and commonly exposed paths, and produces its own A–F grade on the same scale as the CSP audit.

Run CSP Audit and Quick Scan together for a fuller picture: CSP Audit goes deep on one header, Quick Scan covers the rest of your site's security posture.

06

Multi-tenant & permissions

One install can protect any number of sites. Each site has its own IP, path, signature, and user-agent rules, and its own request logs — nothing is shared across tenants by default.

Admin access is permission-scoped per user, per site. A super admin has full access everywhere; other operators can be granted specific permissions — viewing logs, editing rules, managing users, running audits — independently per site they're given access to.

07

Supported databases

Ignite WAF ships with adapters for Microsoft SQL Server, MySQL, and PostgreSQL behind a shared SQL-dialect layer. SQL Server is the primary, most-tested target; the MySQL and PostgreSQL adapters are there if that's what your environment already runs.