Forem: Carrie

Top 7 Free WAF Comparison

Carrie — Tue, 14 Apr 2026 15:22:32 +0000

Free WAF Comparison

WAF which is also known as the Web Application Firewall. Unlike traditional firewalls, WAF operates at the application layer and provides better protection for Web systems based on the HTTP/HTTPS protocol, safeguarding them from hacker attacks.

A Web Application Firewall (WAF) is a security system that sits in front of a web application to inspect, filter, and block malicious traffic. It acts as an intermediary between the internet and your website or web application, examining HTTP requests and responses for potential threats.

Conclusion

	Self-Hosted	Web UI	Anti-Exploit	Deploy	Anti-Bot	Rate Limiting
Cloudflare	NO	YES	NO	Reverse Proxy	YES	YES
SafeLine WAF	YES	YES	YES	Reverse Proxy	YES	YES
ModSecurity	YES	NO	YES	SDK	NO	NO
NAXSI	YES	NO	YES	Nginx Module	NO	NO
OpenAppSec	NO	YES	YES	SDK	NO	YES
BunkerWeb	YES	YES	NO	Nginx Module	NO	NO
Haltdos WAF	YES	YES	YES	Nginx Module	NO	YES

Cloudflare

The Cloudflare WAF runs on the Cloudflare global network and sits in front of web applications to stop a wide range of real-time attacks using powerful rulesets, advanced rate limiting, exposed credential checks, uploaded content scanning, and other security measures.

SafeLine

SafeLine is a self-hosted WAF(Web Application Firewall) to protect your web apps from attacks and exploits.

A web application firewall helps protect web apps by filtering and monitoring HTTP traffic between a web application and the Internet. It typically protects web apps from attacks such as SQL injection, XSS, code injection, os command injection, CRLF injection, ldap injection, xpath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, http-flood, bot abused, among others.

ModSecurity

ModSecurity is a classic open-source WAF project and has been very popular for many years.

Technically, ModSecurity is not a "WAF" but a "WAF rule set". ModSecurity is the foundation of most WAFs; it does not include other common WAF features such as website management and log management, and it does not even have an interface. What ModSecurity has is only protection rules.

NAXSI

NAXSI means Nginx Anti XSS SQL Injection.

Technically, it is a third party nginx module, available as a package for many UNIX-like platforms. This module, by default, reads a small subset of simple and readable rules containing 99% of known patterns involved in website vulnerabilities.

As you may have noticed, the development of Naxsi has been stopped and the repository will be archived for historical reasons.

BunkerWeb

BunkerWeb based on NGINX under the hood, it will protect your web services to make them "secure by default". BunkerWeb integrates seamlessly into your existing environments and is fully configurable to meet your own use-cases .

BunkerWeb contains primary security features as part of the core but can be easily extended with additional ones thanks to a plugin system.

OpenAppSec

open-appsec is a machine learning security engine that preemptively and automatically prevents threats against Web Application & APIs.

The open-appsec engine learns how users normally interact with your web application. It then uses this information to automatically detect requests that fall outside of normal operations, and conducts further analysis to decide whether the request is malicious or not.

Upon every HTTP request, all parts are decoded, JSON and XML sections are extracted, and any IP-level access control is applied.

Haltdos WAF

Haltdos WAF CE is a free version by Haltdos. It is a high-performance WAF and WAAP solution designed to safeguard Web Applications and APIs. Unlike many other open-source WAF solutions in the list, Haltdos uses a new HTTP request processing engine designed for handling performance, creating complex rules, and mitigating sophisticated attacks. Supports complex attack mitigation techniques such as captcha, rate limiting, anomaly detection, redirection, request termination, and connection termination.

SafeLine WAF running on Rootless Docker

Carrie — Thu, 09 Apr 2026 02:47:25 +0000

This article was originally written by obuno.

Original source: https://blog.synack.li/posts/safeline-on-rootless-docker/

The technical details in this article have not been officially verified by the SafeLine team. Please test in a non-production environment and do not apply directly to production systems. SafeLine is not responsible for any damage or issues caused by improper use.

In today’s post we’ll get going at getting SafeLine
excellent WAF (Web Application Firewall) to agree at running on Rootless Docker setup.

Prerequisites#

Docker installed in rootless mode (dockerd-rootless-setuptool.sh install)
SafeLine CE compose.yaml and .env present
sudo access for sysctl (one-time)

Setting up Docker in Rootless mode is a bit beyond the goal of that article, you’ll find all you need here.

Once this has been done, let’s get down at making SafeLine run on such a setup. In order to build your SafeLine setup, you’d need to do this by hands. That means that you’d need to download the docker-compose file and create your own .env file.

That is what I did logged in as the docker running user:

mkdir -p /home/user/data/safeline/

cd /home/user/data/safeline/

wget "https://waf.chaitin.com/release/latest/compose.yaml"

touch ".env"

cat > /home/user/data/safeline/.env << 'EOF'

SAFELINE_DIR=/home/user/data/safeline

IMAGE_TAG=latest

MGT_PORT=9443

POSTGRES_PASSWORD="<apassword>"

SUBNET_PREFIX=172.22.222

IMAGE_PREFIX=chaitin

ARCH_SUFFIX=

RELEASE=

REGION=-g

MGT_PROXY=0

EOF

Now comes a few identified issues, issues we will address further on:

Problem 1 — Ports 80/443 not binding on the host:#

In rootless Docker, network_mode: host does not mean the real host network. Containers land in the rootlesskit network namespace instead. As a result, nginx inside safeline-tengine binds to 80/443 correctly inside the container, but those ports are never exposed to the real host interface. Additionally, rootless Docker cannot bind privileged ports (< 1024) without a sysctl change.

Problem 2 — Real client IPs not visible to SafeLine (SNAT):#

Rootlesskit’s default port driver SNATs all incoming traffic before it reaches the container, so SafeLine/nginx sees the rootlesskit gateway IP instead of the real client IP. This breaks IP-based WAF features: block lists, rate limiting, geo-blocking and IP reputation rules all become ineffective. The fix is to switch the port driver to slirp4netns, which handles port forwarding at a lower level and preserves the original source IP.

Now let’s fix these issues:

Step 1 — Switch rootlesskit port driver to slirp4netns#

This is the most important step — it both enables privileged port binding and preserves real client IPs. With slirp4netns as the port driver, CAP_NET_BIND_SERVICE via setcap is no longer needed or effective; the sysctl approach (Step 2) is the only path for privileged ports.

Create the Docker daemon override file (under your docker user owner):

bashCopy

mkdir -p ~/.config/systemd/user/docker.service.d

cat > ~/.config/systemd/user/docker.service.d/override.conf << EOF

[Service]

Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_NET=slirp4netns"

Environment="DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns"

EOF

Reload and restart the Docker user daemon:

bashCopy

systemctl --user daemon-reload

systemctl --user stop docker

pkill rootlesskit          # ensure full teardown

systemctl --user start docker

systemctl --user status docker

Verify the driver is active:

bashCopy

cat ~/.config/systemd/user/docker.service.d/override.conf

systemctl --user show docker | grep Environment

Step 2 — Lower the unprivileged port start on the host#

Required for binding ports 80/443 in rootless mode. With slirp4netns as the port driver, this is the only supported method — setcap cap_net_bind_service on rootlesskit does not work with the slirp4netns port driver.

bashCopy

# Temporary (verify first)

sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80



# Persistent (survives reboot)

echo "net.ipv4.ip_unprivileged_port_start=80" | sudo tee /etc/sysctl.d/99-unprivileged-ports.conf

sudo sysctl --system

Verify:

bashCopy

sudo sysctl net.ipv4.ip_unprivileged_port_start

# Expected: net.ipv4.ip_unprivileged_port_start = 80

Step 3 — Fix the tengine service in compose.yaml#

Why this is needed#

SafeLine’s default compose.yaml uses network_mode: host for tengine with no explicit port mappings. In rootless Docker this means nginx binds inside the rootlesskit netns only — invisible to the real host.

The fix#

Edit compose.yaml. Find the tengine service and remove network_mode: host, replacing it with explicit port mappings and a network assignment:

yamlCopy

  tengine:

    container_name: safeline-tengine

    restart: always

    image: ${IMAGE_PREFIX}/safeline-tengine${REGION}${ARCH_SUFFIX}:${IMAGE_TAG}

    ports:

      - "80:80"

      - "443:443"

    networks:

      safeline-ce:

        ipv4_address: ${SUBNET_PREFIX}.x   # pick a free IP — see note below

    volumes:

      # ... unchanged ...

    environment:

      # ... unchanged ...

    ulimits:

      nofile: 131072

    # network_mode: host   ← REMOVE this line

Finding a free IP: Check .env for SUBNET_PREFIX, then review other containers' ipv4_address entries in compose.yaml to pick an unused last octet.

I went for this:
networks:
safeline-ce:
ipv4_address: ${SUBNET_PREFIX}.6

Remove any sysctls block from tengine (if present)#

If your compose file has this under tengine, remove it — it is not permitted with explicit port mappings:

yamlCopy

# REMOVE if present:

sysctls:

  - net.ipv4.ip_unprivileged_port_start=0

Step 4 — Bring SafeLine up#

bashCopy

cd /path/to/safeline

docker compose up -d

docker compose ps

Expected state — all containers Up:

safeline-tengine    Up

safeline-mgt        Up

safeline-detector   Up

safeline-pg         Up

safeline-chaos      Up

safeline-fvm        Up

safeline-luigi      Up

Step 5 — Verify port binding on the host#

bashCopy

ss -tlnp | grep -E ':80|:443|:9443'

Expected — slirp4netns owning all three ports:

LISTEN 0 1 0.0.0.0:80        0.0.0.0:*    users:(("slirp4netns",...))

LISTEN 0 1 0.0.0.0:443       0.0.0.0:*    users:(("slirp4netns",...))

LISTEN 0 1 0.0.0.0:9443      0.0.0.0:*    users:(("slirp4netns",...))

You can also verify nginx is listening inside the container via /proc:

bashCopy

docker exec safeline-tengine cat /proc/1/net/tcp | awk '{print $2}' | grep -E "^00000000:(0050|01BB)"

# 0x0050 = port 80, 0x01BB = port 443

Step 6 — Configure upstream applications#

Connecting tengine to an external app network (optional)#

If your upstream apps live in a separate Docker compose stack, attach tengine to their network:

yamlCopy

# In SafeLine compose.yaml



services:

  tengine:

    networks:

      safeline-ce:

        ipv4_address: ${SUBNET_PREFIX}.x

      your-app-network:            # join the upstream network

        aliases:

          - safeline-tengine



# Bottom of compose.yaml

networks:

  safeline-ce:

    external: false

  your-app-network:

    external: true

    name: actual_docker_network_name   # from: docker network ls

Find the network name:

bashCopy

docker network ls

docker inspect <upstream-container> | grep -A 5 Networks

Adding a site in SafeLine UI#

Browse to https://<host>:9443
Add your upstream app (IP:port or container name — see note below)
SafeLine generates nginx vhost configs in /etc/nginx/sites-enabled/IF_backend_*
nginx reloads automatically

Upstream addressing#

Method	Status	Notes
`172.1x.x.x:PORT` (static IP)	✅	Reliable if IPs are statically assigned in compose, I went for this
`container_name:PORT`	❌	SafeLine UI accepts it although nginx validation fails

Step 7 — Securing the SafeLine Admin Console on TCP:9443#

⚠️ Obviously, securing any external access toward port TCP:9443 is highly recommended, I did that through UFW rules on the host itself, thus allowing inbound connectivity to TCP:9443 for tolerated IP stacks only.

That’s it, you can now enjoy your Rootless SafeLine setup !
Hope this helps,
obuno

Running a Self-Hosted WAF in the Real World: Notes from Using SafeLine

Carrie — Wed, 24 Dec 2025 06:46:59 +0000

The problem that pushed me to look at a WAF

Like many small teams, we didn’t start with a security team.

At first, the site was simple: a couple of APIs, a frontend, some admin endpoints hidden behind “security by obscurity”.

Then traffic grew.

Not the good kind.

Credential stuffing on /login
Aggressive bots scraping pages that didn’t even matter
Random scanners hitting /wp-admin, /phpmyadmin, and endpoints we never had
Occasional bursts of traffic that weren’t large enough to be a DDoS, but enough to hurt stability

Nothing catastrophic, but enough to waste time and attention.

Rate limiting at the app level helped a bit, but it was reactive and incomplete.

That’s when I started seriously looking at a WAF.

Cloud WAF vs self-hosted: the trade-off I actually cared about

The obvious answer is a cloud WAF. They’re easy, mature, and battle-tested.

I did consider them.

But there were a few reasons I hesitated:

Visibility: I wanted to see raw requests, not just dashboards and sampled logs.
Control at the application layer: I didn’t want everything abstracted away.
Cost predictability: Traffic spikes shouldn’t automatically become billing spikes.
Architecture fit: Some services weren’t easily routed through a third-party proxy.

That led me to explore self-hosted WAFs instead.

More responsibility, yes—but also more control.

SafeLine was one of the options I ended up testing in depth.

How SafeLine fits into the traffic path

SafeLine is a self-hosted WAF, typically deployed as a reverse proxy in front of your application.

A common setup looks like this:

Client
↓
SafeLine (WAF)
↓
Upstream (Nginx / App / Load Balancer)

It inspects requests at the HTTP application layer, not just IP or TCP level.

This is important, because most of the real problems today are not volumetric attacks, but abusive behavior that looks almost legitimate.

From an operational point of view, I appreciated that:

It runs in your own environment
Logs stay local
You can correlate WAF behavior directly with upstream logs

SafeLine is self-hosted but not fully open source.

Some components are open (for example, parts of its semantic analysis engine), but it’s not an “everything on GitHub” project—and that’s fine as long as expectations are clear.

Features that actually mattered in practice

I’m intentionally skipping the “long feature list” here.

Instead, these are the parts that made a real difference for me.

1. Anti-bot challenges at the application layer

One thing I underestimated before using a WAF seriously:

how much bot traffic isn’t obviously malicious.

SafeLine’s anti-bot challenge mechanism works at the application layer, not just on IP reputation.

This helped with:

Headless browsers scraping content
Basic automation that rotated IPs but failed behavioral checks
Reducing noise without blanket IP blocking

The key benefit wasn’t “blocking everything”, but reducing junk traffic while keeping false positives manageable.

2. Rate limiting that’s not buried inside the app

Yes, you can implement rate limiting in your code.

But having it outside the app:

Keeps logic consistent across services
Avoids redeploys just to tweak limits
Makes abuse patterns more visible

I found SafeLine’s rate limiting useful especially for:

Login endpoints
Public APIs
Admin or internal paths that shouldn’t be hit often

3. Visibility and debuggability

This is where self-hosted solutions really shine.

When something is blocked, I can:

See the exact request
Check upstream logs
Correlate timestamps
Decide whether it’s a false positive or actual abuse

This matters more than people think.

A “secure” system that’s opaque is hard to trust.

A realistic deployment experience (not a full tutorial)

Deployment wasn’t exotic:

Docker-based setup
Fronted by DNS pointing traffic to SafeLine
Upstream services unchanged

What did take time wasn’t installation, but tuning:

Deciding which rules to enforce strictly
Allow-listing known services (e.g. search engine verification)
Avoiding over-blocking during the first few days

This is normal for any WAF.

If someone tells you “zero tuning required”, be skeptical.

Limitations and cases where it’s not a good fit

SafeLine is not for everyone.

I wouldn’t recommend it if:

You want zero operational responsibility
You expect DNS-level features (like native DNS challenges)
You prefer a fully managed, hands-off security model
You don’t want to think about false positives at all

Cloud WAFs still make more sense in many scenarios, especially for very large or very distributed systems.

Self-hosting trades convenience for control.

Who SafeLine makes sense for (and who it doesn’t)

Good fit if you are:

An independent developer running your own infrastructure
A small team without a dedicated security department
A DevOps/SRE who wants visibility and control
Someone who prefers predictable costs over usage-based surprises

Probably not a good fit if you:

Want everything abstracted away
Don’t want to manage another component
Need globally distributed edge protection out of the box

Final thoughts

SafeLine didn’t magically “solve security”.

What it did was give me leverage:

Better signal-to-noise ratio
More control at the HTTP layer
Fewer surprises when something goes wrong

For teams comfortable owning their infrastructure, that trade-off can be worth it.

Their website: https://safepoint.cloud/landing/safeline
Their awesome SafeLine Demo: https://demo.waf.chaitin.com:9443/statistics Take a look at the demo before you invest your time into it!

Mitigating the React Server Components RCE (CVE-2025-55182)

Carrie — Wed, 24 Dec 2025 03:15:42 +0000

React Server Components (RSC) were recently found to be affected by a high-severity remote code execution vulnerability (CVE-2025-55182).

Attackers may exploit this issue by crafting malicious serialized data in the Flight protocol, abusing features such as Next.js Server Actions, which can trigger a deserialization flaw and potentially lead to remote code execution on the server.

This post focuses how this vulnerability works, who is affected, and what you can realistically do to reduce risk—both at the application level and at the WAF layer.

What Is CVE-2025-55182?

React Server Components (RSC) were found to contain a high-risk deserialization flaw that can lead to remote code execution.

In affected setups, an attacker can:

Craft malicious serialized payloads in the React Flight protocol
Abuse Next.js Server Actions ("use server")
Trigger unsafe deserialization logic
Potentially execute arbitrary code on the server

This is not a theoretical issue. The attack surface exists anywhere RSC and Server Actions are exposed to untrusted input.

Priority 1: Identify and Patch (Primary Mitigation)

The most important mitigation is identification and upgrading. WAF rules can help, but they do not replace fixing the root cause.

1. How to Tell If You’re Affected

You are likely impacted if all or most of the following are true:

You are using Next.js, especially v13.4 or later
Your application uses React Server Components
Your codebase includes the "use server" directive (Server Actions)

⚠️ Important note

The vulnerable package (react-server-dom-webpack) is usually bundled internally by Next.js.

You will not necessarily see it in package.json, so don’t assume you’re safe just because it’s not listed as a direct dependency.

2. Upgrade Recommendation

Upgrade immediately to the latest security-patched version of Next.js.

At the time of writing, this means:

Patched releases in Next.js 14.x
Or newer fixed versions in Next.js 15.x

The React team has addressed the root issue by fixing the unsafe parsing of malicious Thenable objects, which was the core of the deserialization vulnerability.

This is the only complete fix.

Anything else should be treated as a temporary risk-reduction measure.

Priority 2: WAF-Level Mitigation with SafeLine

If immediate upgrading is not possible (for example, due to release freezes or legacy dependencies), you can add a defensive layer at the WAF level.

This does not eliminate the vulnerability, but it can help block known exploit patterns.

Example: SafeLine Custom Deny Rule

In SafeLine WAF, you can configure a custom deny rule with the following conditions:

Request Header
Content-Type matches (regex): multipart

AND

Request Body
Regex match: [’”]?then[’”]?\s*:\s*[’”]?$1:proto:then

This rule targets payloads attempting to exploit the RSC deserialization logic by abusing Thenable structures in serialized data.

What This Rule Does (and Does Not Do)

✔️ Helps block known exploit signatures

✔️ Reduces exposure during patching windows

❌ Does not guarantee protection against new or obfuscated payloads

❌ Does not replace upgrading Next.js

Think of this as a seatbelt, not a cure.

Conclusion

If you use Next.js + RSC + Server Actions, you should assume exposure until proven otherwise
Upgrading is mandatory, not optional
WAF rules (like those in SafeLine) are best used as defense-in-depth, especially during transition periods

If you’re running production workloads on modern React infrastructure, this is a good reminder that application-layer vulnerabilities can’t be fully solved at the perimeter—but a well-configured WAF can still buy you valuable time.

Ultimate Guide to Handle React/Next.js RCE (CVE-2025-55182)

Carrie — Fri, 05 Dec 2025 04:41:19 +0000

A Critical Front-End Vulnerability Hits Hard

On December 4, 2025, developers worldwide woke up to a CVSS 10.0 full-score RCE vulnerability in React 19 / Next.js (CVE-2025-55182, Next.js CVE-2025-66478).

If Log4Shell was a nightmare for Java in 2021, this is the darkest hour for full-stack JavaScript.

This vulnerability allows attackers to execute arbitrary code on your server via a single HTTP request—no authentication required.

01 Understanding the Vulnerability: The Achilles’ Heel of RSC

Flight Protocol & Serialization

React Server Components (RSC) introduced the Flight protocol to stream component trees between server and client:

Server → Client: Components are streamed in a JSON-like format.
Client → Server: When Server Actions (e.g., form submissions) are triggered, the client serializes parameters back to the server.

Unsafe Deserialization

The core of the vulnerability lies in the react-server package and its adapters (e.g., react-server-dom-webpack):

Cause: The server fails to safely validate the structure of deserialized objects.
Attack vector: Maliciously crafted RSC payloads exploit the server’s deserialization logic.
Trigger: When the server deserializes the payload, it executes arbitrary functions or instructions.
Impact: Malicious JavaScript runs in the server process context, bypassing sandboxes.

This is a classic unsafe deserialization vulnerability, amplified by RSC’s flexibility for complex object passing.

02 Who Is at Risk?

Affected frameworks include all React RSC implementations:

React versions: 19.0.0, 19.0.1, 19.1.x, 19.2.0
Next.js (App Router): v15.0.0–v15.5.6, v16.0.0–v16.0.6, v14.3.0-canary.77+
Other frameworks: Waku, RedwoodJS (RSC mode), and custom setups using react-server-dom-webpack/parcel.

Not affected: legacy Next.js using only Client Components (Pages Router).

03 Official Fix: Upgrade Immediately

Option 1: Upgrade Your Framework (Recommended)

Next.js users: Upgrade to the following patch versions or higher:

# Next.js v16
npm install next@16.0.7

# Next.js v15
npm install next@15.5.7
# or 15.4.8, 15.3.6, 15.2.6, 15.1.9, 15.0.5

# Next.js v14 Canary
# downgrade to stable v14 or upgrade to fixed v15

React native / custom integrations: Upgrade react, react-dom, and react-server-dom-* to the versions below:

npm install react@19.2.1 react-dom@19.2.1

Official patched versions: 19.0.1, 19.1.2, 19.2.1

Option 2: Mitigation Using WAF

If immediate code deployment isn’t possible (e.g., during a network freeze), use a Web Application Firewall (WAF).

Why WAF Matters for React RCE

Even if you patch this RCE, unknown vulnerabilities will always exist. A WAF like SafeLine provides:

Defense against unknown threats: Detects abnormal payloads, serialized data, and suspicious patterns that traditional rules miss.
Minimal false positives: Uses semantic analysis to distinguish malicious requests from normal traffic.
Continuous protection: Updated in real-time as new attack techniques emerge.

SafeLine WAF ensures that your full-stack React/Next.js apps stay protected even when you don’t yet know the next attack vector.

04 Full-Stack Security Considerations

React’s move across client and server boundaries complicates security. With Server Actions, developers can write backend logic directly in components — but this exposes HTTP-accessible endpoints.

CVE-2025-55182 is a wake-up call: you can patch today’s RCE, but tomorrow’s unknown vulnerabilities demand proactive protection.

Key takeaway: Patch your frameworks and deploy a WAF like SafeLine to defend against both known and unknown threats.

SafeLine WAF: Unaffected by React Vulnerabilities

Carrie — Fri, 05 Dec 2025 04:12:23 +0000

Just saw the alerts about the critical React 19 / RSC vulnerability flooding the feeds?

This CVSS 10.0 high-risk flaw instantly exposed React 19.x and Next.js 14.3+ applications to single-request RCE, forcing many teams to scramble and urgently upgrade their frameworks overnight.

Meanwhile, the SafeLine WAF site, built with React 18 + Next.js 14.0.1, has remained completely unaffected from the start.

Was it luck? Not entirely.

Why SafeLine Was “Unaffected”

From a product security perspective, all SafeLine WAF versions are insulated from this vulnerability:

Proactive full-stack protection: SafeLine’s core defense logic already covers risks in full-stack frameworks.
Next-gen semantic analysis: Our patented semantic analysis engine goes beyond traditional rule-based methods, deeply understanding request payloads to detect anomalies.
Targeted detection for RSC attacks: Malformed Flight protocol requests are detected via multiple dimensions — abnormal Content-Type, oversized or irregular payloads, and serialized data carrying hidden malicious instructions.
Precision interception with zero false positives: SafeLine combines linear security detection algorithms and dynamic traffic baseline learning. Unlike temporary WAF rules that may block legitimate users, SafeLine’s high-performance, Nginx-based architecture achieves <1ms detection latency, accurately distinguishing attack traffic from normal requests.

The result: RCE attacks are blocked without impacting your business operations.

This level of protection makes “unaffected” a guaranteed outcome for SafeLine customers, not mere luck.

SafeLine WAF: Full-Stack Security Without Fear

Accurate protection for known and unknown threats: For the recent React vulnerability, SafeLine’s XSS detection rules already block most malicious payloads. Leveraging intelligent semantic analysis, SafeLine defends against both known vulnerabilities and unknown threats, leaving 0-day attacks no place to hide. Our security team continuously monitors exploit patterns and updates detection rules in real time, ensuring protection evolves alongside emerging threats.

Plug-and-play deployment, lightweight operations: SafeLine supports one-click installation and containerized management, compatible with various environments. Rules are ready out-of-the-box, so even non-security professionals can manage it easily. With <1ms detection latency and 2000+ TPS on a single core, SafeLine provides round-the-clock protection without overloading server resources.
Multi-dimensional capabilities for full-stack scenarios: Includes CC attack mitigation, malicious IP intelligence blocking, enforced HTTPS, CAPTCHA verification, and more — all tailored for modern full-stack applications.

Don’t Rely on Luck

Vulnerabilities keep coming. Being “unaffected” by chance is not a sustainable security strategy.

SafeLine WAF delivers cutting-edge technology, ease of use, and comprehensive protection, making security a standard, not an afterthought.

Resources

SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine

How to Configure GitHub Login for Your Website

Carrie — Wed, 03 Dec 2025 03:20:35 +0000

GitHub login is a popular and trusted authentication method, especially for developer-oriented websites and internal tools. By enabling GitHub authentication, you can allow users to log in using their GitHub accounts without building a complex login system yourself.

This article explains the basic concept, when GitHub login is useful, and how to configure GitHub authentication for your website using SafeLine WAF, based on the official documentation.

Why Use GitHub Login?

GitHub authentication is based on OAuth 2.0, which allows third-party websites to verify user identities securely.

Common benefits include:

✅ No need to manage usernames and passwords
✅ Trusted identity provider used by millions of developers
✅ Faster login experience for users
✅ Reduced security risk for your backend
✅ Ideal for developer portals, admin panels, and internal systems

When Is GitHub Login a Good Choice?

GitHub login is especially suitable for:

Developer platforms or SaaS tools
Internal admin panels
Staging or testing environments
API portals
Open-source–related services

If your users already have GitHub accounts, GitHub login greatly simplifies access control.

How GitHub Authentication Works (High-Level)

The authentication flow typically looks like this:

User accesses a protected page on your website
The website redirects the user to GitHub for authentication
The user logs in and authorizes access
GitHub redirects the user back with an authorization code
The system verifies the identity and grants access

With SafeLine WAF, this entire process is handled at the gateway level, without changing your backend application code.

Prerequisites

Before setting up GitHub login, make sure you have:

A website already protected by SafeLine WAF
Access to the SafeLine management console
A GitHub account (to create an OAuth App)

Step 1: Create a GitHub OAuth App

Log in to GitHub
Go to Settings → Developer settings → OAuth Apps
Click New OAuth App
Fill in the required fields:
- Application name: Any recognizable name
- Homepage URL: Your website address
- Authorization callback URL: This should be the callback URL provided by SafeLine (from the authentication configuration page)
Save the application

After creation, GitHub will generate:

Client ID
Client Secret

Keep these values secure—you will need them in SafeLine.

Step 2: Configure GitHub Authentication in SafeLine

Log in to the SafeLine management console
Navigate to Advanced → Authentication
Create a new authentication configuration
Select GitHub as the authentication type
Fill in the following information:
- GitHub Client ID
- GitHub Client Secret
- Redirect / callback settings (as required)
Save the configuration

SafeLine will now be able to communicate with GitHub for identity verification.

Step 3: Protect Your Website or Paths

After creating the GitHub authentication policy:

Select the target site or domain in SafeLine
Specify which paths to protect, such as:
- /admin
- /dashboard
- Entire website
Bind the GitHub authentication policy to the selected resources
Apply and save the configuration

Once applied, unauthenticated users will be redirected to GitHub login automatically.

Step 4: Test the Login Flow

Open the protected URL in your browser
You should be redirected to GitHub’s login and authorization page
After successful login, you will be redirected back to your website
Access should now be granted

No backend code changes are required.

Advantages of Using SafeLine for GitHub Login

Using SafeLine WAF as the authentication layer provides several benefits:

✅ Authentication handled before traffic reaches your server
✅ No modification to existing application code
✅ Works with legacy systems
✅ Unified access control for multiple services
✅ Reduced backend attack surface

This approach is especially useful when adding authentication to existing websites or third-party applications.

Conclusion

GitHub login is a secure and convenient authentication method, particularly for developer-focused websites. By configuring GitHub authentication through SafeLine WAF, you can quickly add identity protection to your website without touching backend code.

This makes SafeLine an excellent choice for teams looking to implement modern authentication with minimal complexity and maximum security.

For detailed configuration options and advanced settings, refer to the official documentation:
https://docs.waf.chaitin.com/reference/articles/Auth-GitHub

Website Authentication Made Simple with SafeLine

Carrie — Wed, 03 Dec 2025 02:52:44 +0000

Website authentication is a fundamental part of modern web security. It ensures that only authorized users can access protected resources, reducing the risk of data breaches, abuse, and unauthorized operations.

This article will explain what website authentication is, when it is needed, introduce several free and practical authentication tools, and finally walk through SafeLine WAF’s authentication feature and how to configure it.

What Is Website Authentication?

Website authentication is the process of verifying a user’s identity before granting access to a website, application, or specific resources.

Common authentication methods include:

Username and password
Tokens or API keys
Cookies and sessions
Single Sign-On (SSO)
IP-based or request-based verification

Authentication answers the question:

“Who are you, and should you be allowed to access this resource?”

When Do You Need Website Authentication?

Not every website needs authentication, but it becomes essential in many scenarios:

Administrative Interfaces

Admin panels (/admin)
Internal dashboards
Management APIs

Internal or Private Services

Staging environments
Internal tools
Test platforms not meant for public access

APIs and Web Services

Prevent unauthorized API usage
Protect against abuse and scraping
Control access for partners or customers

Temporary Protection

Maintenance pages
Pre-launch websites
Emergency protection during attacks

If your website exposes sensitive functionality or data, authentication should be considered mandatory.

Free and Useful Website Authentication Tools

Here are some popular and free authentication solutions commonly used today:

1. Basic Authentication

Built into HTTP standard
Username and password via browser prompt
Easy to configure
Best for internal tools or temporary protection

✅ Simple

❌ Not suitable for public-facing login systems

2. OAuth / OpenID Connect

Used by Google, GitHub, Microsoft, etc.
Enables Single Sign-On (SSO)
Supported by many open-source tools

Popular providers:

Google OAuth
GitHub OAuth
Auth0 (free tier available)
Keycloak (open-source)

✅ Secure and scalable

❌ Slightly more complex to deploy

3. API Key / Token-Based Authentication

Common for APIs
Client sends a token in headers
Easy to rotate and revoke

✅ Ideal for machine-to-machine access

❌ Requires careful key management

4. Reverse Proxy Authentication

Authentication handled at the gateway layer
No need to modify backend applications
Ideal for legacy systems

✅ Very flexible

✅ Application-agnostic

This is where SafeLine WAF authentication shines.

SafeLine WAF Authentication: Overview

SafeLine WAF provides a built-in identity authentication feature at the WAF layer, allowing users to protect websites and applications without changing backend code.

With SafeLine authentication, you can:

Add authentication to any website behind SafeLine
Protect directories, paths, or entire domains
Block unauthorized users before traffic reaches the server
Reduce attack surface and backend load

This is especially useful for:

Admin panels
Internal services
Temporary access control
Protecting legacy applications

How To Configure Authentication in SafeLine

Basic Configuration

SafeLine provides two authentication modes: Simple Auth and SSO.

Simple Auth: Application-specific authentication system where users can only access that application after logging in
SSO (Single Sign-On): allowing users to access multiple related applications after logging in once, without repeated logins. See SSO

Field	Description
Login Method	Multiple login methods available, including AccountPassword, OIDC, Github, LDAP. For SSO mode, configuration must be done in `AUTH-SETTINGS-SSO`.
Auth Callback URL	Required when passing user authentication information to the application server, used to exchange for user information.
Application Redirect URL	Required in SSO mode. When clicking on the application in the unified management panel, it will redirect to this address.

Advanced Configuration

Approval Configuration: Options for authorization approval
- Need to approve access: First-time users will trigger an approval request after authentication, requiring admin approval before accessing.
- Access directly after authentication: Users can directly access the application after authentication without approval.
Enable authentication for specific conditions: Supports options to authenticate when conditions are met or skip authentication when conditions are met

How to Configure Passing User Authentication Information to the Application Server?

After successful user authentication, SafeLine will redirect to the following URL, where http://example.com/application is the Auth Callback URL configured:

http://example.com/application?code=123456&redirect_uri=original_user_access_address

Find the API Token in the SafeLine console under Settings-Management page
The application should implement using the code to request SafeLine's /.safeline/auth/api/user interface to obtain authenticated user information at the Auth Callback URL. The code can only be used once

// Request:

GET http://safeline-console.com/.safeline/auth/api/user?code=123456

X-SLCE-API-TOKEN: safeline-api-token

// Response:

Content-Type: application/json

{
    "code": 0, // 0: success, non-zero: failure
    "msg": "Error description",
    "data": {
        "id": 1,
        "username": "username"
    }
}

After successfully obtaining user information, the application should cache the login information to determine whether the current user is logged in for subsequent requests, then redirect to the redirect_uri

If retrieving user information fails, the application needs to delete cookies with the prefix sl_auth_session_, prompting the user to authenticate again

Why Use WAF-Level Authentication?

Compared to application-level authentication, WAF-level authentication offers:

✅ No code changes
✅ Faster deployment
✅ Consistent protection across services
✅ Reduced backend attack surface
✅ Ideal for legacy or third-party systems

It provides a lightweight but effective layer of access control exactly where it matters.

Conclusion

Website authentication is a critical security mechanism for protecting sensitive resources and preventing unauthorized access. While many tools and frameworks exist, WAF-level authentication offers a powerful and flexible option—especially when backend changes are impractical.

SafeLine WAF enables teams to implement authentication quickly, securely, and transparently, making it an excellent choice for internal tools, admin panels, APIs, and temporary access control scenarios.

By combining authentication with SafeLine’s traffic inspection and protection capabilities, you gain both identity control and attack defense at the gateway level.

Related Resources

SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine

Beginner's Guide to SafeLine Web Application Firewall

Carrie — Wed, 03 Dec 2025 02:17:36 +0000

Web Application Firewalls (WAFs) have become an essential security tool for protecting websites and online applications from malicious attacks. SafeLine WAF is a self-hosted solution that provides robust security while giving users full control over their deployment.

Why Use SafeLine WAF?

Web applications are constantly targeted by attackers using methods such as SQL injection, XSS (Cross-Site Scripting), and DDoS attacks. SafeLine WAF helps:

Prevent attacks: Blocks malicious requests before they reach your server.
Protect sensitive data: Ensures user information and backend data remain secure.
Enhance reliability: Reduces downtime caused by attacks.
Maintain compliance: Assists with meeting security standards and regulations.

By deploying SafeLine, organizations can protect their websites, APIs, and web applications with minimal manual intervention.

Who Can Use SafeLine WAF?

SafeLine is suitable for a wide range of users:

Small and medium-sized businesses (SMBs): Secure websites without relying on cloud-based services.
Enterprises: Protect high-traffic websites and critical applications.
Developers and DevOps teams: Gain full control of security policies and traffic management.
Security-conscious individuals: Self-hosted solution ensures data privacy and independence from third-party cloud providers.

Essentially, anyone running a web application or website that needs protection from cyber threats can benefit from SafeLine.

How to Install SafeLine WAF

SafeLine can be deployed quickly using either automatic or manual methods. Below is a summarized guide based on the official documentation.

Prerequisites

Operating system: Linux
Architecture: x86_64 or ARM64
Dependencies: Docker ≥ 20.10.14, Docker Compose ≥ 2.0.0
Minimum resources: 1 CPU core, 1 GB memory, 5 GB disk
CPU instruction set: SSSE3

Automatic Deployment (Recommended)

Use the following command to start the automated installation of SafeLine. (This process requires root privileges)

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en

After the command is executed, it means the installation is successfully. Please go to Use Web UI directly.

Mannually Deploy

Install Docker

Install the latest version of Docker.

If you already have Docker installed, please skip this step.

curl -sSL "https://get.docker.com/" | bash

Create SafeLine Directory

Create a directory for SafeLine to use, SafeLine will write its configuration and data to this directory. (You need to have at least 5GB of disk space)

mkdir -p "/data/safeline"

Docker Compose Script

Download the latest docker compose script by using the following command.

cd "/data/safeline"
wget "https://waf.chaitin.com/release/latest/compose.yaml"

Write Environment variables

cd "/data/safeline"
touch ".env"

Write the following content in the ".env" file

SAFELINE_DIR=/data/safeline
IMAGE_TAG=latest
MGT_PORT=9443
POSTGRES_PASSWORD={postgres-password}
SUBNET_PREFIX=172.22.222
IMAGE_PREFIX=chaitin
ARCH_SUFFIX=
RELEASE=
REGION=-g
MGT_PROXY=0

If deploying to an ARM server, change ARCH_SUFFIX to -arm

ARCH_SUFFIX=-arm

If you want to install the LTS version

RELEASE=-lts

SAFELINE_DIR: 123
IMAGE_TAG: SafeLine version to be used
MGT_PORT: Web console port to be used
POSTGRES_PASSWORD: Postgres db initialization password
SUBNET_PREFIX: SafeLine internal network communication address prefix
IMAGE_PREFIX: Mirror repository prefix
ARCH_SUFFIX: Set to -arm for ARM servers.
RELEASE: Set to -lts for use LTS version.
MGT_PROXY: The number of console proxy layers,It should only be used when configuring the proxy for the console. By default, it is set to 0 and no proxy is configured.

Launch SafeLine

Everything is ready to start the SafeLine service.

This process may take several minutes, so don't worry.

docker compose up -d

Use Web UI

Open the web console page https://<safeline-ip>:9443/ in the browser, then you will see below.

Get Administrator Account

docker exec safeline-mgt resetadmin

After the command is successfully executed, you will see the following content

Please must remember this content

[SafeLine] Initial username：admin
[SafeLine] Initial password：**********
[SafeLine] Done

Login

Enter the password in the previous step and you will successfully logged into SafeLine.

Resources

SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine

SafeLine Detection Engine Performance Configuration

Carrie — Tue, 02 Dec 2025 10:27:25 +0000

SafeLine offers three distinct performance modes to meet different system requirements and traffic loads. Each mode is designed to provide an optimal balance between resource consumption and request handling capacity.

1. Single-threaded Mode

Default performance setting
Minimal resource consumption on your device
Recommended for environments with limited computing resources
Suitable for low-traffic websites and testing environments
Prioritizes efficiency over high throughput

2. Balanced Mode

Moderate resource utilization
Medium QPS (Queries Per Second) capacity
Ideal for standard production environments
Provides a good compromise between performance and resource efficiency
Recommended for most general use cases

3. Maximum Performance Mode

Highest resource utilization
Maximum QPS handling capability
Designed for high-traffic websites and critical applications
Optimized for environments where performance is the top priority
Requires more robust hardware specifications

By selecting the appropriate performance mode, users can tailor SafeLine to their specific infrastructure, ensuring optimal protection and efficiency for their websites or applications.

Resources

How to update SSL certificates through file upload in SafeLine WAF

Carrie — Tue, 02 Dec 2025 10:02:49 +0000

Some users find it cumbersome to manually upload certificates through the interface when using Safeline WAF's SSL Cert feature.

They want to store certificate files in a fixed directory and have Safeline automatically detect and update them after overwriting, allowing the entire process to be completed through automation tools. Related issues include:

To solve or optimize the above issues, Safeline Community Edition launched the automatic certificate reading and updating feature in version 7.2.0. Below is an introduction to how to use this feature.

Prerequisites

WAF version >= 7.2.0

Upload Certificate Once

To let the WAF know that there are certificates that need periodic updates, you need to upload the certificate once in the WAF.

Get Certificate Path

By default, certificates are saved in /data/safeline/resources/nginx/certs

ls /data/safeline/resources/nginx/certs/ -lh
total 8.0K
-rw-r--r-- 1 root root 1.4K Nov 22 18:15 cert_1.crt
-rw-r--r-- 1 root root 1.7K Nov 22 18:15 cert_1.key

Update Certificates Using Files

You can use tools like certbot to apply for free certificates

After obtaining the certificates, simply overwrite the above files

WAF Automatic Updates

WAF refreshes certificate content every hour by default.

SafeLine Resources:
SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine

SafeLine HTTP Request Processing Flow

Carrie — Tue, 02 Dec 2025 09:16:03 +0000

SafeLine processes every incoming HTTP request through a layered, decision-based pipeline designed to block attacks early while ensuring legitimate users reach the application with minimal friction.

This flow combines access control, behavior analysis, bot protection, authentication, and attack detection into a clear and auditable request lifecycle.

Below is a step-by-step explanation based on the SafeLine HTTP Request Processing Flow diagram.

1. Request Entry: Users vs. Attackers

All incoming traffic—whether from legitimate users or attackers—enters the same processing pipeline.

SafeLine does not make assumptions upfront; instead, it evaluates each request through multiple security stages.

2. Work Mode (Global Switch)

Work Mode defines whether SafeLine is actively protecting the application.

Offline → Requests are blocked or bypassed depending on configuration
Defense → Full protection pipeline is enabled

If SafeLine is offline, the request is rejected immediately.

3. Allow & Deny Rules

At this stage, SafeLine applies explicit access control rules:

Allowlists (trusted IPs, regions, paths)
Denylists (known malicious IPs, forbidden paths)

Possible outcomes:

✅ Allowed → Continue processing
❌ Denied → Request is blocked

This ensures known-safe traffic passes quickly, while known threats are stopped early.

4. Rate Limiting

SafeLine evaluates request frequency and behavior patterns.

If rate limiting is enabled and the threshold is exceeded:
- ❌ Banned IP
If rate limiting is disabled or not triggered:
- ✅ Continue

This step is critical for mitigating DDoS, brute-force, and scraping attacks.

5. Anti-Bot Protection

The Anti-Bot module distinguishes real users from automated clients.

Browser fingerprinting
Behavior analysis
Challenge-response validation (if enabled)

Outcomes:

✅ Verified → Allowed to proceed
❌ Failed → Blocked as a bot

6. Authentication (Optional)

If authentication is configured, SafeLine validates the request identity.

Token-based auth
Client verification
Custom authentication logic

Outcomes:

✅ Authenticated
❌ Failed → Request rejected

This step is optional and depends on deployment requirements.

7. Attack Detector

This is the core WAF inspection phase.

SafeLine analyzes requests for:

SQL Injection (SQLi)
XSS
Command Injection
Path Traversal
Protocol violations
Known exploit signatures

Outcomes:

✅ Legitimate → Continue
❌ Attack detected → Blocked and logged

8. Waiting Room (Traffic Control)

When traffic surges occur, SafeLine can route users through a Waiting Room:

Helps protect backend services during peak loads
Ensures fair access for legitimate users

Outcomes:

⏳ Wait → User queued
✅ Admitted → Continue

9. Request Reaches the Application

Once a request successfully passes all enabled stages:

✅ It is forwarded to the protected application

This ensures:

Malicious traffic is filtered out
Legitimate users experience stable and secure access
All decisions are auditable

10. Audit and Visibility

Throughout the entire process:

Every decision is logged
Actions can be set to Audit-only or Block
Operators gain full visibility into request behavior

This makes SafeLine suitable for both strict security enforcement and gradual policy tuning.

Summary

SafeLine’s HTTP request processing approach is:

✅ Layered – Multiple security gates instead of a single check
✅ Flexible – Each module can be enabled, disabled, or audited
✅ Transparent – Every decision is traceable
✅ Production-ready – Balances protection and usability

By combining early filtering, behavior analysis, and deep inspection, SafeLine ensures that only trusted traffic reaches your applications.

SafeLine Resource:
SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine