Download the PHP package saarors/firewtwall-php without Composer

🔥 fireWTwall

Designed, built and maintained by saarors

A production-ready Web Application Firewall (WAF) with zero external runtime dependencies. Available as an npm package for Node.js, Bun, and Express — as a drop-in PHP auto-prepend file — and as an ASP.NET HttpModule for classic .NET Web Forms / MVC.

Version	Runtime	Install
Node.js	Node.js >= 16	npm install firewtwall
Bun	Bun >= 1.0.0	bun add firewtwall
PHP	PHP >= 8.0	composer require saarors/firewtwall-php
ASP.NET	.NET Framework 4.7.2+	Copy aspnet/src/ into your project

All versions share the same rule sets, detection philosophy, and NDJSON log format.

Table of contents

1. Protections
2. Node.js & Bun
   • Quick start
   • Bun runtime
   • All options
   • Debug mode
   • Log viewer CLI
   • Redis / multi-process
   • Configuration reference
   • TypeScript
   • Test commands
3. PHP
   • Requirements & install
   • Configuration
   • Rate limiter storage
   • Debug mode (PHP)
4. ASP.NET (.aspx)
   • Requirements
   • Installation
   • Configuration
   • Debug mode (ASP.NET)
   • Test commands (ASP.NET)
5. Middleware pipeline
6. Log format
7. Security headers
8. Project structure
9. Important notes
10. License & credits

What's new in v2.3.1 — Next-gen original detection layers

Protections

Dual mode: mode: 'reject' blocks · mode: 'log-only' audits without blocking (recommended for first deploy)

Node.js & Bun

Quick start

npm:

Bun:

Example (works with both):

Bun runtime

fireWTwall fully supports Bun — a fast JavaScript runtime that's fully compatible with Node.js APIs.

Run with Bun:

Performance benefits:

• Faster startup than Node.js
• Lower memory footprint
• Identical security protection
• No code changes needed

See docs/nodejs/bun.md for complete Bun documentation.

All options

Debug mode

When debug: true every request — pass and block — is fully traced:

Response headers in debug mode:

Passed request — log entry:

Blocked request — log entry:

Catch nmap in debug mode:

⚠️ Never use debug: true in production — it leaks internal rule names to the caller.

Log viewer CLI

Redis / multi-process

Replace the built-in in-memory store with any key-value backend:

Configuration reference

TypeScript

Types ship with the package — no @types/ install needed:

Test commands

PHP

Requirements

• PHP ≥ 8.0
• APCu extension (optional but recommended — file-based fallback included)

Installation

Option A — Composer (recommended):

Then load it at the top of your entry point:

Or via php.ini / .htaccess (auto-runs before every script):

Option B — php.ini (server-wide, no Composer):

Option C — .htaccess (per-directory, Apache):

Option D — manual include (any framework):

Configuration (php/config/waf.config.php)

Rate limiter storage

Enable APCu in php.ini:

Debug mode (PHP)

Set 'debug' => true in waf.config.php. The same X-WAF-* response headers and verbose NDJSON log entries as the Node.js version will be produced.

⚠️ Disable in production. Debug mode exposes rule names to the client.

ASP.NET (.aspx)

fireWTwall runs as a standard IHttpModule — the same mechanism used by ASP.NET's built-in security features. It fires on every request before your code runs, regardless of whether the target is an .aspx page, MVC controller, Web API endpoint, or .ashx handler.

ASP.NET Requirements

• .NET Framework 4.7.2 or later
• IIS 7.5+ or IIS Express
• System.Web, System.Runtime.Caching, and System.Web.Extensions assemblies (all included in .NET 4.7.2+)

ASP.NET Installation

Step 1 — Add the source files to your project.

Copy the aspnet/src/ directory into your web project or a referenced class library:

Step 2 — Register the HttpModule in Web.config:

That's it. The WAF now intercepts every request automatically.

ASP.NET Configuration

Override defaults in Global.asax.cs Application_Start:

Key settings:

See docs/aspnet/configuration.md for the full reference including DDoS and bot config.

Debug mode (ASP.NET)

Adds four response headers to every request and logs all passing requests:

Tail the log in PowerShell:

⚠️ Never use Debug = true in production — it exposes rule names in response headers.

See docs/aspnet/debug-mode.md for full details.

Test commands (ASP.NET)

Middleware pipeline

Requests pass through 23 stages (Node.js) / 22 stages (PHP) in this order:

Pattern-based stages (12–22) scan: query params · request body · URL path · cookies · all headers

Log4Shell (stage 18) and Shellshock (stage 19) scan every HTTP header — not just params.

Log format

Every blocked request appends one NDJSON line to the log file:

Severity levels: critical · high · medium

Sources: query · body · path · cookie:<name> · user-agent · header:<name>

Security headers (added to every response)

Project structure

The docs/aspnet/ directory contains the full ASP.NET reference:

Important notes

• Start with log-only mode in production. Review logs for false positives before switching to reject.
• The logs/ directory must be writable by the web server but not web-accessible. The included php/logs/.htaccess handles this for Apache.
• This WAF is a defence-in-depth layer — it does not replace parameterised queries, input validation, or proper output encoding in your application code.
• For multi-process / multi-server Node.js deployments, swap the in-memory rate-limit store with Redis (see the Redis example above).
• The CSP header shipped by default is strict. If your app loads scripts or styles from external origins, tune Content-Security-Policy in the security-headers middleware before deploying.

License

MIT © saarors

Credits

Author & lead developer

All design decisions, architecture choices, and release ownership belong to saarors.