SamWaf Private Web Application Firewall Review

Why SamWaf targets smaller private sites

SamWaf addresses a specific gap between basic web server plugins and hosted cloud protection. Its README says the project was motivated by the coupling of products built around Nginx, Apache, and IIS plugins, as well as the cost of private deployment for small companies and studios. Its intended users are operators of small company websites, studios, personal sites, and APIs.

The project emphasizes private deployment and local data handling. According to the README, locally stored information is encrypted, while the default configuration uses an embedded encrypted SQLite database. MySQL and PostgreSQL are optional alternatives rather than required services. This distinction matters to operators that do not want request and management data sent to a cloud security provider.

SamWaf is more than a request-filtering library. Its documented interface includes attack logs, CC and rate-limit settings, IP and URL lists, custom rules, log details, and manual rule editing. That gives an administrator a policy console, although the README does not describe a formal threat model, rule-update procedure, or incident-response workflow. Operators must establish those details from the application documentation and their own deployment requirements.

How SamWaf filters and forwards traffic

SamWaf is written primarily in Go and is designed as an independent protection engine rather than a plugin that depends on IIS or Nginx. The README states that it supports HTTP/1.1, HTTP/2, and HTTP/3 over QUIC, along with WebSocket forwarding. It can therefore sit in front of applications as a reverse proxy and security gateway.

Its documented balancing methods include weighted round-robin, IP hash, and least connections. Health checks automatically remove unhealthy backends. Individual paths can be configured for reverse proxying, static file serving, or 301 and 302 redirects. Backend protocol and response timeout are configurable. The product can also serve a static site, which makes it applicable to deployments that are not limited to dynamic applications.

The attack-protection layer includes SQL injection, XSS, RCE, scanner, path traversal, dangerous file upload, and spoofed Content-Type detection. SamWaf also documents CC and rate-limit protection, reverse-DNS bot verification, hotlink protection, CSRF checks based on Origin or Referer, sensitive-word filtering, and OWASP CRS support through the Coraza engine. Log-only mode records attacks without blocking them, which supports an initial observation period.

Access controls include IP and URL allowlists and blocklists, geographic blocking through offline ip2region and GeoIP2 data, and operating-system firewall IP bans. TCP and UDP tunnels add IP and time-window controls. This broad feature set can reduce the number of separate components in a small deployment, but it also increases the importance of rule ordering and allowlist scope.

Encrypted storage and Docker privilege boundaries

The embedded database is SamWaf's clearest storage distinction. The README says the encrypted SQLite database requires no external dependency. Operators can select MySQL or PostgreSQL when they prefer a separate database service. Redis is also named among optional dependencies, although the README excerpt does not identify every feature that can use it.

The repository's `docker-compose.yml` publishes ports 26666, 80, and 443. It mounts `./conf`, `./data`, `./logs`, and `./ssl` under `/app` and adds the `NET_ADMIN` capability to the SamWaf container. It also defines an `nginx:latest` service on port 8080 and attaches both containers to `samwafnet`.

Containerized firewall bans have a specific boundary. The compose comments state that the container needs `NET_ADMIN`, but also explain that host traffic is affected only when the host network namespace is shared. Uncommenting `network_mode: host` requires commenting the mapped `ports` and `networks` configuration. If SamWaf remains in an isolated container network, a host-level ban cannot be assumed to apply outside that namespace.

The Dockerfile starts `./SamWafLinux64` and supports amd64 and arm64 images. It exposes 26666, 80, and 443 and mounts the same four directories. The project also supports Linux, Windows 64-bit, and ARM64, but the README does not document every platform-specific startup or upgrade procedure.

Starting a Docker deployment and defining the first host

The repository includes a Compose deployment, but the README does not provide an explicit installation command, initial administrator account, or documented first-login URL. The following service configuration is copied from `docker-compose.yml`. Place it in a directory where the four bind-mounted directories can be created and backed up.

services:
  samwaf-instance:
    image: samwaf/samwaf
    container_name: samwaf-instance
    ports:
      - "26666:26666"
      - "80:80"
      - "443:443"
    volumes:
      - ./conf:/app/conf
      - ./data:/app/data
      - ./logs:/app/logs
      - ./ssl:/app/ssl
    cap_add:
      - NET_ADMIN
    networks:
      - samwafnet
    restart: always

Start the deployment with the Docker Compose installation available on the host, then use the address mapped from port 26666 to reach the management interface. The README shows screens for adding a host, inspecting attack logs, selecting logs, configuring rules, and maintaining IP and URL lists. It does not document whether port 26666 serves the interface over HTTP or HTTPS.

For the first real use, define one upstream host and begin with the documented log-only mode. Confirm that ordinary requests appear in the selected log, then review detected attacks without blocking them. After validating false positives, enable a narrow protection rule or rate limit and verify that traffic still reaches the intended backend. Do not expose ports 80 or 443 until the TLS paths and backend protocol have been checked against the host configuration.

False positives, CSRF, and rule tuning

SamWaf offers several inspection layers, but that flexibility creates a tuning requirement. SQL injection and XSS detection can affect legitimate requests when an application uses uncommon encodings or parameter formats. Sensitive-word filtering can also depend on language and business context. The documented log-only mode lets an operator observe matches before enforcement, although the README does not state the default mode or retention behavior for temporary log-only data.

CSRF protection relies on per-site Origin or Referer validation. API clients, mobile applications, callbacks, and server-to-server requests may not send those headers in the same form as browsers. Enabling this feature without representative traffic can therefore create application-specific failures. The human-verification features include click CAPTCHA and Cap.js proof-of-work, but the README does not explain their per-site configuration.

Custom script rules and GUI-edited rules make local policy possible. They also create more configuration surfaces that can diverge between environments. Record which Coraza CRS rules are enabled, disabled, or overridden, and keep custom rules tied to named application routes where possible. The README documents rule adjustment but not compatibility for every web framework. Log-only observation and a staged rollout are therefore more defensible than enabling every protection category at once.

Release maturity and upgrade boundaries

The repository is not archived, and the last push was on 2026-10-15. Recent releases include `v1.3.25-beta.7` on 2026-10-10, `v1.3.25-beta.6` on 2026-09-12, and `v1.3.25-beta.5` on 2026-09-07. The current version label is beta, so an operator should review release notes and test changes before replacing a working deployment.

Repository files include `build_test_upgrade_twice.bat` and `check_upgrade_state.ps1`. Their names indicate upgrade-related test paths, but the README does not describe a complete upgrade procedure, supported upgrade sequence, backup format, or rollback command. Before changing versions, preserve the `conf`, `data`, `logs`, and `ssl` directories referenced by the Compose deployment. A backup is especially important because the default database is stored locally rather than delegated to a managed service.

SamWaf uses the Apache-2.0 license. Its Go dependency list includes multiple third-party components, and the repository also contains `ThirdLicense`. Distribution reviewers should inspect notices for bundled libraries, GeoIP data, CAPTCHA assets, and other included resources. Apache-2.0 identifies the project's license, but it does not replace a review of all bundled components.

Where SamWaf differs from simpler infrastructure

A conventional reverse proxy primarily routes requests to upstream services. SamWaf combines that role with inspection, rate limiting, bot checks, upload checks, geographic filtering, access lists, caching, and attack logs. For a small operator, that can replace the need for a separately hosted WAF while retaining a reverse proxy.

The corresponding trade-off is policy ownership. A managed cloud WAF may supply centrally managed updates and a hosted operational model. SamWaf keeps data local and leaves rule design, application compatibility, upgrades, and incident review to the operator. Its independence from IIS and Nginx avoids plugin dependence, but it also makes the proxy and security gateway part of the same deployment boundary.

SamWaf also supports static hosting, WebSockets, HTTP/3, TCP and UDP tunnels, and operating-system firewall banning. Those capabilities do not make it a complete network firewall. In Docker, host-level IP banning depends on privileged configuration and network-namespace sharing. The product is better suited to owners of a specific web and API estate than to environments requiring a documented global network-security boundary.

Editorial conclusion

Adopt SamWaf when a small organization needs a self-hosted reverse proxy and WAF with encrypted local storage and no required database service. Do not treat it as a complete replacement for network controls. Before shifting production traffic, verify log-only rule behavior, database recovery, container permissions, TLS configuration, and upstream health checks.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. samwafgo/SamWaf on GitHub