DEV Community: Lia

LDAP and Active Directory Login for Self-Hosted Apps

Lia — Tue, 18 Aug 2026 03:53:34 +0000

If your users already live in an enterprise directory — Active Directory, OpenLDAP, Apache Directory, or FreeIPA — then the cleanest login for a self-hosted app is the account they already have. Nobody wants to remember a second password for an internal tool when they log into the company directory every morning.

SafeLine WAF speaks LDAP, so it can front your apps and let users sign in with their existing directory accounts. No directory code in your app, no separate user database. Here's the full configuration, straight from the docs.

How LDAP fits the picture

LDAP (Lightweight Directory Access Protocol) is the protocol for reading from a distributed directory service — the thing that stores user accounts, organizational structure, and permissions. It's also the foundation of most single-sign-on infrastructure: one set of credentials, many systems.

When a WAF fronts your app, it can query your directory during login, authenticate the user, and only then let them reach the origin. That means your enterprise directory becomes the login for everything the WAF protects.

Step 1: Open the LDAP configuration

In the SafeLine console, go to Auth → Settings, click Third-Party Login, and select LDAP.

You'll fill in five parameters:

Parameter	Purpose
LDAP Server URL	Where the directory lives
Bind DN	The account used to connect to the directory
Bind Password	Password for that bind account
User baseDN	Where in the directory tree to start searching for users
Query Condition	The filter that matches a user entry

Step 2: The parameters in detail

LDAP Server URL

Format is ldap://hostname:port or ldaps://hostname:port for SSL. Standard ports are 389 (plain) and 636 (SSL). For example:

ldap://ldap.example.com:389   # standard connection
ldaps://ldap.example.com:636  # SSL encrypted

Bind DN

The account used to bind to the LDAP server. It needs enough permission to query user information. A couple of reference shapes:

Active Directory: cn=Administrator,cn=Users,dc=domain,dc=com
OpenLDAP: cn=admin,dc=example,dc=com

The docs recommend a dedicated service account with read-only permissions rather than a full administrator account.

User baseDN

This is the node in the directory tree where user searches begin — it affects both performance and search scope. Examples:

Active Directory: cn=Users,dc=domain,dc=com
OpenLDAP: ou=People,dc=example,dc=com

Query Condition

A filter expression used to match user entries, where %s is a placeholder for the username the visitor types. The basic form:

(&(objectClass=person)(uid=%s))

This matches entries where objectClass is person and uid equals the entered username. If a user enters john, the filter becomes (&(objectClass=person)(uid=john)).

Step 3: Reference configs for common directories

The docs include ready-to-adapt examples:

Microsoft Active Directory

LDAP Server URL: ldap://ad.company.com:389
Bind DN:         cn=LDAPService,cn=Users,dc=company,dc=com
Bind Password:   (service account password)
User baseDN:     cn=Users,dc=company,dc=com
Query Condition: (&(objectClass=user)(sAMAccountName=%s))

OpenLDAP

LDAP Server URL: ldap://openldap.company.com:389
Bind DN:         cn=admin,dc=company,dc=com
Bind Password:   (admin password)
User baseDN:     ou=People,dc=company,dc=com
Query Condition: (&(objectClass=person)(uid=%s))

FreeIPA

LDAP Server URL: ldap://ipa.company.com:389
Bind DN:         uid=admin,cn=users,cn=accounts,dc=company,dc=com
Bind Password:   (admin password)
User baseDN:     cn=users,cn=accounts,dc=company,dc=com
Query Condition: (&(objectClass=person)(uid=%s))

What the login flow looks like

After you enable LDAP for an application:

Visitors are prompted to authenticate with their LDAP account.
They log in with their directory credentials.
New users need verification by a SafeLine administrator after their first authentication.
Verified users are authorized and can log in on later visits without re-verification; unverified users are blocked.

FAQ

Users can't log in even though the connection works?

Check the User baseDN (does the user actually sit under it?) and the Query Condition — the %s placeholder, the attribute names (uid, sAMAccountName, etc.), and the outermost parentheses all need to be correct. Also confirm the account isn't locked or disabled in the directory.

Why is the connection failing?

Check the server URL format (protocol, hostname, port), that the SafeLine server can reach the LDAP server on the network, the bind account credentials, and — for ldaps:// — that the certificate is valid or trusted.

What does `%s` mean in the query condition?

It's replaced with the username entered at login. (&(objectClass=person)(uid=%s)) with input john becomes (&(objectClass=person)(uid=john)).

Can I filter by Active Directory security group?

Yes — add a membership condition, for example:

(&(objectClass=user)(sAMAccountName=%s)(memberOf=CN=AllowedGroup,OU=Groups,DC=company,DC=com))

My query condition has syntax errors — any tips?

LDAP filters use prefix notation, so make sure parentheses are matched and the attribute=value syntax is right. The docs suggest validating with an online LDAP filter syntax checker.

Do your internal apps already authenticate against your directory — or are users juggling a separate set of credentials for each tool?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

OIDC Authentication with Keycloak (and Auth0, Okta, Azure AD)

Lia — Tue, 18 Aug 2026 03:52:16 +0000

If your team already runs an identity provider, the last thing you want is a second login system. You want your apps to trust the identity system you already have — whether that's Keycloak, Auth0, Okta, or Azure AD. OpenID Connect (OIDC) is the protocol that makes that possible, and a self-hosted WAF can speak it for you.

SafeLine supports OIDC out of the box. Instead of adding an OIDC client library to each app, you configure the identity provider once in the WAF, and it handles the redirect and the login gate in front of your applications. Here's the setup, straight from the docs.

What OIDC actually is

OpenID Connect is an identity layer built on top of OAuth 2.0. It lets a client application verify who a user is, based on the authentication result from an authorization server — and get back basic user information — without the client ever handling the user's credentials directly.

For a WAF, that's a clean fit: the WAF fronts your app, redirects unauthenticated visitors to your identity provider, and only lets approved users through.

Step 1: Prepare your OIDC provider

The docs walk through Keycloak as the reference example, since it's a common self-hosted choice. Here's how to get the parameters SafeLine needs:

Log in to the Keycloak admin console.
Select or create a Realm.
In the left menu, click Clients → Create to create a new client.
Fill in a Client ID — a unique identifier for the client.
In the Settings tab:
- Valid Redirect URIs — add the application's callback address, for example https://example.com/.safeline/auth/api/callback/oidc.
- Web Origins — add the application address, for example https://example.com.
Save, then switch to the Credentials tab and copy the Client Secret.

The key things to record:

Parameter	Example
OIDC Discovery URL	`https://{keycloak-host}/realms/{realm-name}`
Client ID	The client ID you created
Client Secret	The secret from the Credentials tab

The callback path is fixed: append /.safeline/auth/api/callback/oidc to your application URL.

Step 2: Configure SafeLine

In the SafeLine console, go to Auth → Settings → Login Configuration, find Third-Party Login, and select OIDC.

Fill in the form:

Field	What it's for
OIDC Server URL	Your provider's discovery URL. SafeLine appends `.well-known/openid-configuration` automatically
Client ID	From your OIDC provider
Client Secret	From your OIDC provider
Title Name	Shown on the blocking page — defaults to "Sign In - OIDC"
Use Proxy to Access	Check if your requests go through a proxy
Auto Merge Account	Automatically match incoming logins to existing accounts by email or phone number

Click Submit to save the binding.

Step 3: Enable OIDC on the application

Open Applications and pick the app you want to protect.
In that app's AUTH → Login Methods configuration, enable OIDC.
Save.

What the login flow looks like

Once OIDC is enabled for an application:

A visitor opens the app and sees the OIDC login option.
Clicking it redirects them to your identity provider's login page.
After authenticating there, they're redirected back to SafeLine.
First-time users need to be approved by a SafeLine administrator before they can access the app.
Approved users get authorized and don't need another review for later visits; unapproved users are blocked.

Managing users

On AUTH → User Management you can view which users are linked, review new users, manage access permissions, and manually merge accounts.

FAQ

Can't redirect to the OIDC provider after integration?

Check that the OIDC discovery URL is correct and that it's reachable from a browser and returns valid JSON.

Callback fails after the user authenticates with the provider?

Confirm the callback address is configured correctly — protocol (http/https), domain, and path all need to match.

What scopes does SafeLine request by default?

openid, profile, and email (optional, used to link accounts), plus phone (optional, for account linking).

Do I need to write OIDC code in my app?

Not for the login gate itself. The WAF handles the redirect flow. You'd only add app code if the application needs the authenticated user's identity — via the auth callback flow.

Which providers are supported?

The docs name Keycloak, Auth0, Okta, and Azure AD, and note the list isn't limited to those — anything speaking standard OIDC should work.

If you already run Keycloak, Auth0, Okta, or Azure AD — are your internal apps currently trusting it, or are you maintaining a second login system?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Add GitHub Login to Your Web App with a WAF

Lia — Tue, 18 Aug 2026 03:48:37 +0000

"Sign in with GitHub" is one of the first things developers reach for when an internal tool needs authentication. The usual route is a real engineering task: register a GitHub OAuth app, add an OAuth client library to your codebase, store the ClientID and ClientSecret, implement the callback handler, and manage sessions yourself.

There's a shorter path. If you front your web app with a self-hosted WAF that runs as a reverse proxy, you can let the WAF handle the entire GitHub OAuth flow — before a single request reaches your application code. SafeLine does exactly this. Here's the full walkthrough, straight from the docs.

Why do GitHub login at the WAF layer?

A WAF already sits in front of your app, so every request passes through it. That makes it a natural place to gate access. Letting the WAF handle GitHub authentication means:

No OAuth code in your app. You don't add a client library, a callback route, or token storage.
One place to manage identity. Add or remove GitHub login across several apps from one console.
It works for anything. An internal dashboard, a legacy tool, or a static site can all get GitHub login the same way.

Step 1: Create the GitHub OAuth app

First you need a GitHub OAuth application to act as the identity source. This is done on GitHub's side, not SafeLine's.

From the GitHub documentation flow:

Go to GitHub and click your profile picture, then open Settings.
In the left sidebar, click Developer Settings.
Click OAuth Apps, then New OAuth App.
Fill in the application form:
- Application name — what users see on the authentication page.
- Homepage URL — your application's URL, for example https://a.com.
- Authorization callback URL — your homepage URL with /.safeline/auth/api/callback/github appended. For the example above: https://a.com/.safeline/auth/api/callback/github.

Once created, GitHub gives you the two values you'll need next: a ClientID and a ClientSecret.

The callback URL is the one place people get stuck. It's not arbitrary — it's always your Homepage URL plus the fixed path /.safeline/auth/api/callback/github.

Step 2: Configure SafeLine

Now move to the SafeLine console. Go to Auth → Settings → Login Configuration, find Third-Party Login, and select GitHub.

Fill in the configuration form:

Field	What it's for
ClientID	Your GitHub application ID
ClientSecret	Your GitHub application secret
Title Name	The name shown on the blocking page — defaults to "Sign In - GitHub"
Use Proxy to Access	Check this if your requests need to go through a proxy
Auto Merge Account	Automatically match incoming GitHub logins to existing accounts by email

Click Submit to save the binding.

Step 3: Enable GitHub on the application

Configuring the GitHub source isn't enough — you also have to switch it on for the specific app:

Open the Applications page and select the application you want to protect.
In that application's AUTH page, open the Login Methods settings.
Enable the GitHub option.
Save.

That's it. The app is now gated behind GitHub authentication.

What happens when a user tries to log in

Once the AUTH feature is enabled and GitHub is selected as the login method, the flow looks like this:

When someone visits the app, they're prompted to authenticate.
New users authenticate, then need to be reviewed and approved by a SafeLine administrator in the console before they can get in.
Approved users are authorized for the app and don't need another review — subsequent logins just work after authentication.
Unapproved users are blocked when they try to access the app.

That approval step is a useful default: it stops an open GitHub login from becoming a backdoor for anyone with a GitHub account.

Managing users after login

On the AUTH → User Management page you can:

See whether users have linked their GitHub accounts.
Review new users for approval.
Manage access permissions per user.
Manually merge user accounts.

The "merge" option is handy when someone has been logging in one way and you want to fold their history into another account.

Optional: combine it with SSO

If you want users to authenticate just once and then reach several applications, GitHub login can feed into SSO:

Go to AUTH → Settings → SSO.
Enable the unified authentication feature.
Add applications to unified authentication.

After that, a user authenticates once — including through GitHub — and can access every application that's joined SSO.

FAQ

Do I have to write any application code for GitHub login?

Not for the login itself. The WAF handles the OAuth redirect and gatekeeping. Your app only needs custom code if it has to know who logged in — for that you'd use the auth callback flow.

Why does a new GitHub user need admin approval?

It's the default safety behavior: first-time users trigger a review so an admin can confirm who gets access. After approval, the same user logs in without further review.

Can I use GitHub login on more than one app?

Yes. You configure the GitHub source once, then enable it on each application individually from that app's AUTH → Login Methods settings.

What if my traffic goes through a proxy?

Check the Use Proxy to Access option in the GitHub login configuration. That tells SafeLine to route its GitHub calls through a proxy.

Does GitHub login work together with other login methods?

Yes. SafeLine supports several login methods (account/password, OIDC, LDAP, and GitHub), and you can enable more than one for an application.

Have you wired up "Sign in with GitHub" the hard way before — and would you move that identity layer out of your code and into the WAF?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

Add Authentication and SSO to Any Web App Without Changing Code

Lia — Mon, 17 Aug 2026 16:03:46 +0000

Most people treat authentication as an application problem. If an internal dashboard, an admin panel, or a legacy tool doesn't have a login screen, the reflex is to open the codebase and start wiring up an auth library — OAuth clients, session management, user tables, password resets, the whole thing.

That's a lot of work to do once, and it's even worse when you have ten different apps that all need it.

There's a faster way: put the authentication layer in front of your apps instead of inside them. A self-hosted WAF that sits as a reverse proxy in front of your services can handle login for you — before a single request ever reaches your application code.

Here's how SafeLine does it, and how you can add both password protection and full SSO to any web app without touching its source.

Why do auth at the WAF layer?

A WAF is a reverse proxy: clients connect to the WAF first, the WAF filters and forwards traffic to your origin server. Because every request already flows through it, the WAF is a natural place to gate access.

That means:

No code changes. The app behind the WAF doesn't need an auth library, a user table, or any login UI of its own.
One place to manage. Instead of maintaining credentials in ten apps, you manage them in one console.
It works for anything. Legacy apps, static sites, internal tools, APIs — anything the WAF fronts can be protected.

SafeLine provides two authentication modes to cover different situations: Simple Auth and SSO.

Simple Auth vs SSO: two ways to gate access

SafeLine gives you two distinct modes, and the difference comes down to scope:

Simple Auth is application-specific. A user logs in to access that one application. If they move to a different app, they authenticate again.
SSO (Single Sign-On) is the opposite. A user logs in once and then accesses multiple related applications without repeated logins.

Think of Simple Auth as "lock this one door," and SSO as "issue one badge that opens every door you're allowed into."

Simple Auth: password-protect a single app

With Simple Auth turned on for an application, visitors must enter valid credentials before they can reach the app. Anyone who doesn't hold the credentials is blocked.

When you configure Simple Auth for an application, you pick a login method and set an Auth Callback URL.

The login method is how users prove who they are. SafeLine supports four:

Account + Password — a basic username/password login.
GitHub — sign in with a GitHub account.
OIDC — sign in through an OpenID Connect identity provider.
LDAP — sign in with an existing enterprise directory account.

The Auth Callback URL is what lets you pass the authenticated user's identity into your app, which I'll cover in detail below.

SSO: one login, every app

SSO is where this gets genuinely useful for teams. Once unified authentication is enabled, your users get a single sign-in entry point — an SSO center — and from there they can reach every application that has joined.

The docs describe three business scenarios where this fits naturally:

Enterprise application portal. Internal systems like OA, HR, and CRM each have their own auth today. With SSO, employees log in once and reach all of them, while IT centralizes access policy.
Modernizing legacy apps. Older apps often have no built-in auth, or a dated mechanism. SSO adds a modern authentication layer on top without modifying application code.
Zero trust. SSO is a core piece of a zero-trust architecture, giving every application access a consistent identity-verification and authorization path.

Enabling SSO

You enable SSO from the Auth-Settings page under the SSO tab. The configuration is a handful of fields:

Field	What it's for
Domain	The domain users visit to reach the unified authentication center (e.g. `home.in.example.cn`)
Port	An available port for the center
SSL	Optional, for HTTPS
Login Methods	The identity methods available (multiple can be enabled)
Force Enable TOTP	When on, every SSO user must use TOTP for two-factor authentication

Once enabled, users in the user list can access the SSO center by default.

Adding apps to SSO

To bring an application into SSO, go to Applications, click the app's AUTH button, and switch it over. Then you configure two fields:

Application Redirect URL — where the user is sent when they click the app in the SSO center.
Auth Callback URL — how authentication info is passed to the app server.

After that, when a user visits an application for the first time, they authenticate once. From then on, that one authentication covers every authorized application that has joined SSO.

A few details worth knowing from the SSO docs:

There is no limit on how many applications can join SSO.
You can edit an application's name and logo in the SSO center.
Users can only access applications they have permission for — joining SSO doesn't grant access to everything by default.
Logging out of the SSO center is not SLO (single logout) — that's not currently supported.

The four login methods

Whichever mode you use, the actual identity check is done by one of four methods.

Account + Password

The simplest option. You configure a username and password, and visitors enter it to get through. It's a good fit for a single admin or a small set of trusted users.

GitHub

SafeLine can let users sign in with their GitHub identity. You create a GitHub OAuth application to get a ClientID and ClientSecret, then fill those into SafeLine's third-party login configuration. The callback URL for GitHub follows the pattern:

https://your-app.com/.safeline/auth/api/callback/github

There's also an "Auto Merge Account" option to match incoming GitHub logins to existing accounts by email.

OIDC

For organizations that already run an identity provider, SafeLine speaks OpenID Connect. The docs call out Keycloak, Auth0, Okta, and Azure AD as supported providers.

Configuring it means pointing SafeLine at your provider's discovery URL (for Keycloak, something like https://{keycloak-host}/realms/{realm-name}) plus a Client ID and Client Secret. This is the method to reach for when you want your apps to trust the identity system you already have.

LDAP

For enterprise directories, SafeLine supports LDAP — including Microsoft Active Directory, OpenLDAP, and Apache Directory. Users log in with their existing enterprise accounts.

Configuration is the standard set of LDAP fields: a server URL (ldap://host:389 or ldaps://host:636 for SSL), a Bind DN, a Bind password, a user base DN, and a query condition. The query condition uses %s as a placeholder for the username, for example:

(&(objectClass=person)(uid=%s))

This is the one to use when you want a self-hosted gateway in front of an on-premise directory.

Passing the authenticated user into your app

Blocking unauthenticated traffic is only half the story. Often your app needs to know who just logged in. SafeLine handles this with a callback flow.

After a user authenticates, SafeLine redirects to your configured Auth Callback URL, appending a short-lived code:

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

Your application then exchanges that code for the user's identity by calling SafeLine's user-info endpoint:

GET http://safeline-console.com/.safeline/auth/api/user?code=123456
X-SLCE-API-TOKEN: safeline-api-token

The response gives you the user's id and username. Two things to note: the code can only be used once, and you'll find the API token in the console under Settings → Management.

After your app obtains the user info, it should cache the login state to decide whether the user is logged in for subsequent requests, then redirect to the redirect_uri. If retrieving the user info fails, your app should delete cookies with the sl_auth_session_ prefix and prompt the user to authenticate again.

Approvals and conditional auth

Two more knobs round out the picture, both under the app's AUTH advanced configuration:

Approval configuration. You can require that first-time users trigger an approval request after authenticating, which an admin must approve before the user gets in. Or you can let users access directly after authentication. The former is handy for sensitive internal tools where you want a human in the loop.
Conditional authentication. You can enable authentication (or skip it) only when specific conditions are met — for example, requiring auth for certain paths while letting other traffic pass.

Wrapping up

Authentication doesn't have to be a per-app engineering project. Because a self-hosted WAF already sits in front of your traffic, it's the natural place to gate access — and SafeLine turns that into a real feature set: per-app password protection, unified SSO across your apps, and four identity methods (password, GitHub, OIDC, LDAP) to choose from.

The result is that an internal dashboard, a legacy tool, or a static site can all get a proper login screen — and SSO — without a single line of application code changing.

If you want to try it yourself, the setup starts with a single command. The full authentication documentation is at docs.waf.chaitin.com.

FAQ

Does adding auth at the WAF layer slow down my app?

The check happens at the reverse-proxy layer before traffic reaches your origin, so your application itself isn't doing any extra work. The main cost is the one-time configuration.

Can I use SSO for both internal and public apps?

Yes. The mode is per-application, so you can put internal tools behind SSO while using Simple Auth or no auth on public apps, all from the same console.

Which identity provider should I pick?

If you already run Keycloak, Auth0, Okta, or Azure AD, OIDC is the natural fit. If you have an enterprise directory, use LDAP. GitHub is convenient for developer-facing tools, and Account + Password is fine for a small number of trusted users.

Do I have to modify my app to know who logged in?

Only if your app needs the user's identity. In that case you implement the callback flow (exchange the code for user info). If you just need to gate access, no code changes are required at all.

Does SafeLine's SSO support single logout?

Not currently. Logging out of the SSO center is not SLO.

Which of the four login methods — password, GitHub, OIDC, or LDAP — fits your current stack?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Protect Multiple Websites with One WAF Instance

Lia — Wed, 12 Aug 2026 02:58:53 +0000

The Multi-Site Use Case

You run a VPS with 3 sites: a WordPress blog on blog.example.com, a SaaS app on app.example.com, and a static landing page on example.com. You want one WAF to protect all three — no per-site overhead.

Adding Multiple Sites to SafeLine

In the SafeLine dashboard, Sites -> Add Site -> repeat for each domain:

Site 1: blog.example.com -> backend: wordpress:80
Site 2: app.example.com  -> backend: app:3000
Site 3: example.com      -> backend: nginx:80

All three sites route through the same SafeLine instance. The semantic engine inspects traffic for all of them independently.

Per-Site Rules Without Per-Site WAFs

Each site gets its own protection profile:

Site	Rate Limiting	Geo-Blocking	Bot Protection	Custom Rules
Blog	5/min on /wp-login	Block RU, CN, VN	ON	Block /xmlrpc.php
SaaS App	100/min per API key	None (global product)	ON	Block mass assignment
Landing Page	Global 300/min	None	OFF	None

This is all configured in one dashboard — no separate WAF installations, no per-site Docker containers, no added memory overhead beyond the single SafeLine deployment (~700 MB total for all sites).

SSL Certificate Management

SafeLine handles SSL for all three sites:

Site 1: Let's Encrypt auto-renew for blog.example.com
Site 2: Upload custom wildcard cert for *.example.com
Site 3: Also covered by the wildcard cert

Or terminate SSL at your existing Nginx/Caddy and have SafeLine work in plain HTTP behind it — your choice.

Resource Usage at Scale

SafeLine's resource usage scales efficiently with multiple sites:

Sites Protected	RAM Usage	CPU at 100 req/s total
1	700 MB	15%
3	730 MB	22%
10	780 MB	45%

The fixed overhead is PostgreSQL + management service (~500 MB). Each additional site adds minimal memory — just a few MB for the routing table. The Tengine container handles all the inspection work; adding more sites increases CPU linearly but memory barely budges.

Traffic Isolation

Sites are isolated at the routing layer:

A security event on blog.example.com doesn't affect app.example.com
Rate limits apply per-site, not globally (5/min on blog login doesn't affect SaaS app limits)
Attack logs are tagged by site — you can filter by domain in the dashboard

Save Money: Replace Per-App Security Tools

Before SafeLine, you might have been using:

A WordPress security plugin ($0-100/year per site)
Cloudflare Pro for the SaaS app ($20/month)
fail2ban + manual Nginx rules for the landing page (free but high maintenance)

After: one SafeLine instance ($0 for Community, $10/month for Lite) replaces all of it. The WordPress plugin goes away (WAF handles the same attacks). Cloudflare goes to free tier (WAF handles security, Cloudflare just does DNS). fail2ban gets simpler (WAF catches HTTP attacks, fail2ban only needs SSH).

FAQ

Can I mix HTTP and HTTPS sites on the same WAF?

Yes. Each site has its own SSL config. Blog can be HTTPS with Let's Encrypt while the landing page is HTTP-only. SafeLine handles the routing for both.

What if one site gets a huge traffic spike?

SafeLine Community Edition maxes at 800 QPS total. If one site spikes and you hit the cap, all sites are affected. Upgrade to the Lite plan ($10/month, no QPS cap) if you run high-traffic sites.

Can I give separate dashboard access to different clients?

Not in the Community Edition — one admin account. The Pro plan supports role-based access. For agency use, consider the upgrade.

How many sites are running on your VPS right now without any WAF in front?

Ready to protect your sites without paying for a cloud WAF?

⭐ SafeLine WAF on GitHub — give it a star if you find it useful
🔗 Official Docs — installation guide, configuration, and API reference
🧪 Live Demo — see the dashboard in action (no login required)

How to Block SQL Injection Attacks with a Free WAF

Lia — Tue, 11 Aug 2026 07:01:02 +0000

SQL Injection Is Still the #1 Threat in 2026

OWASP Top 10 hasn't changed. SQL injection remains the most dangerous web vulnerability — and the most common. In 2025, 23% of all reported web vulnerabilities were injection flaws. A WAF can block 99% of them at the proxy level before they reach your database.

What SQL Injection Looks Like

Attackers probe for SQL injection with payloads like:

' OR '1'='1
'; DROP TABLE users; --
' UNION SELECT username,password FROM users--
1 AND (SELECT COUNT(*) FROM users) > 0
' OR 1=1 LIMIT 1 --

These all follow a pattern: they try to escape the SQL query context and inject their own commands. A semantic WAF can detect this pattern structure, not just specific payload strings.

Why Application-Level Fixes Aren't Enough

Prepared statements (the gold standard) prevent SQL injection. But:

Not every query in your codebase uses them
Third-party libraries might have raw queries
Legacy code exists and nobody wants to touch it
ORMs have edge cases (raw queries, dynamic joins)

A WAF is defense in depth. Even if your application is perfect, the WAF catches what you missed.

Setting Up SQL Injection Protection in SafeLine

SafeLine's semantic engine detects SQL injection without regex rules. It parses the SQL structure of incoming payloads and tests whether they could modify query behavior.

No custom rules needed. The semantic engine ships with SQL injection detection built in. To enable:

1. Dashboard -> Settings -> Detection Profile
2. SQL Injection: Block (not just Detect)
3. Confidence threshold: 80 (default)

That's it. Every SQL injection attempt hitting your server is now blocked at the WAF layer.

How It Works: Semantic vs Pattern Matching

Pattern matching (old WAFs):

Rule: /\b(UNION|SELECT|DROP|INSERT)\b/i
Problem: Blocks "SELECT * FROM products" in a search query
         Misses: "U%4EION SEL%45CT" (URL-encoded bypass)

Semantic analysis (SafeLine):

1. Parse the payload as SQL structure
2. Identify: this modifies the query's logic tree
3. Classify: SQL injection with 98% confidence
4. Block

Test It Yourself

After setting up SafeLine, test with a safe probe:

# This should be blocked (returns 403)
curl "https://yourdomain.com/?id=1' OR '1'='1"

# Check the Attack Logs in SafeLine dashboard
# You should see: SQL Injection, Blocked, Score: 98/100

False Positives — What Actually Gets Through

SafeLine's semantic engine has a 0.07% false positive rate on SQL injection detection. What can trigger it:

Legal documents with SQL snippets: If your site publishes database tutorials or SQL reference docs
Form data with SQL keywords: A field labeled "SQL query" submitted by a user

For these edge cases, add path whitelists for specific URLs in the dashboard.

FAQ

Does this replace prepared statements?

No. Prepared statements are still the right way to write queries. The WAF is defense in depth — it catches the SQL injection that gets past your application code. Use both.

What about NoSQL injection?

SafeLine's semantic engine also detects NoSQL injection patterns (MongoDB operators like $gt, $ne, $where). The same single-pass parsing approach applies to JSON-encoded NoSQL queries.

Can I test SQL injection on my own site?

Yes — but only through the WAF. Don't test directly against your database. Use curl with safe payloads and watch Attack Logs to confirm they're blocked.

What about blind SQL injection?

Blind SQL injection (AND SLEEP(5), AND 1=IF(2>1,BENCHMARK(5000000,MD5('A')),0)) uses timing-based extraction instead of visible output. SafeLine detects both blind and in-band SQL injection with the same semantic parsing.

When was the last time you tested your app for SQL injection?

#security #webdev #devops #cybersecurity

Docker Compose WAF: Add SafeLine to Any Existing Stack in 3 Steps

Lia — Tue, 11 Aug 2026 07:00:53 +0000

The Situation

You already have a Docker Compose stack running: Nginx + your app + PostgreSQL + Redis. It works. You don't want to rebuild it. But you want WAF protection in front.

Here's how to add SafeLine to an existing Docker Compose project without disrupting anything.

Step 1: Create a Shared Network

# docker-compose.yml (add to your existing file)
networks:
  webnet:
    driver: bridge

Connect your existing services to this network:

services:
  app:
    networks:
      - webnet
  nginx:
    networks:
      - webnet

Step 2: Install SafeLine Separately

SafeLine uses its own Compose file. The installer creates it automatically:

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

The generated docker-compose.yml (for SafeLine) will be something like /opt/safeline/docker-compose.yml. Leave it alone — SafeLine manages this.

Step 3: Connect SafeLine to Your Network

Edit SafeLine's Compose file (/opt/safeline/docker-compose.yml) and add your existing network as external:

networks:
  safeline:
    driver: bridge
  webnet:
    external: true  # Your existing network

Then connect SafeLine's reverse proxy to both networks:

services:
  safeline-tengine:
    networks:
      - safeline
      - webnet

Step 4: Point Traffic Through SafeLine

Update your Nginx config to route traffic through SafeLine:

# Before (direct to app)
location / {
    proxy_pass http://app:3000;
}

# After (through SafeLine)
location / {
    proxy_pass http://safeline-tengine:80;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Then in SafeLine's dashboard, point the site backend to your app container: app:3000.

Step 5: Restart

# Start all your services
docker compose up -d

# SafeLine should already be running from the installer
docker compose -f /opt/safeline/docker-compose.yml ps

Traffic flow:

Internet → Nginx:80 → SafeLine (inspection) → app:3000

The Beauty of This Setup

Your app doesn't change. SafeLine sits between Nginx and your app as a middleware proxy. No code changes. No config changes to your app containers. Just 3 lines in your Nginx config and one network connection.

SafeLine updates independently. When you update your app stack, SafeLine containers aren't touched. When SafeLine releases a new version, your app stack isn't touched.

You can test before switching. Set up SafeLine in detection-only mode first. Watch Attack Logs for a few days. Confirm zero false positives. Then switch to block mode.

Migration from Existing Reverse Proxy

If you currently use Nginx Proxy Manager, Traefik, or Caddy:

# Traefik example
labels:
  - "traefik.http.routers.app.middlewares=safeline"
  - "traefik.http.middlewares.safeline.forwardauth.address=http://safeline-tengine:80"

For Nginx Proxy Manager, add a custom location that forwards to SafeLine before reaching your app. The principle is the same: NPM -> SafeLine -> your app.

FAQ

Does this work with Kubernetes?

The pattern is the same but implemented differently. Use a DaemonSet for SafeLine or deploy it as a sidecar. The concept of "insert WAF between ingress and app" applies regardless of orchestrator.

What if SafeLine goes down?

Your app still runs, but traffic won't reach it — SafeLine is in the critical path. Mitigate with:

docker compose -f /opt/safeline/docker-compose.yml restart

Add a health check to your monitoring tool. If you need high availability, run SafeLine on a separate node with a load balancer in front.

Can I run SafeLine as a container in my existing compose file?

You can, but the installer-generated Compose file handles SSL certs, PostgreSQL, and the management service. It's safer to keep SafeLine as a separate compose project connected by shared networks.

What's your current Docker Compose stack looking like?

#webdev #devops #docker #security

Self-Hosted WAF on a $5 VPS: My Budget Security Setup

Lia — Mon, 10 Aug 2026 03:37:49 +0000

The $5 Challenge

Can you run a production-grade WAF on the cheapest VPS available? I tested it on a $5/month VPS (1 vCPU, 1 GB RAM, 25 GB SSD) from a major provider. The goal: protect a Node.js blog and a static site without exceeding the budget.

The Stack

┌─────────────────────────────────────┐
│ $5 VPS (1 vCPU, 1 GB RAM)           │
│                                     │
│  ┌─────────┐  ┌──────────┐          │
│  │ SafeLine │  │ Node.js  │          │
│  │ WAF      │  │ Blog App │          │
│  │ ~500 MB  │  │ ~300 MB  │          │
│  └────┬─────┘  └────┬─────┘          │
│       │              │               │
│  ┌────┴──────────────┴──┐           │
│  │   Nginx (reverse)     │           │
│  │   ~50 MB              │           │
│  └───────────────────────┘           │
│                                     │
│  Total RAM used: ~850 MB            │
│  Free: ~150 MB                      │
└─────────────────────────────────────┘

What Worked

1. SafeLine on 1GB is tight but functional
The WAF's Docker containers used ~500 MB at idle (slightly less than the usual 700 MB — the 1GB constraint forced more aggressive memory management). Under moderate load (100 req/s), it stayed at ~550 MB.

2. Node.js blog ran fine with 300 MB
A simple Express app with SQLite database. Generated pages in ~15ms. The WAF added 1ms. Nobody noticed.

3. The sweet surprise: swap file saved us
I added a 1 GB swap file on disk:

fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

When under load, the kernel swapped PostgreSQL's idle memory pages. SafeLine stayed responsive. The swap file is essential on a 1 GB box.

What Didn't Work

1. WordPress on the same box
WordPress + MySQL + PHP-FPM on the same 1 GB VPS with SafeLine hit the OOM killer within 2 hours. Separated WordPress to its own $5 VPS and it worked fine.

2. Concurrent deployments
SafeLine + docker compose up -d + npm run build happening simultaneously triggered OOM. Staggered deployments: build first, then start WAF containers.

3. Heavy PostgreSQL logging
Default SafeLine PostgreSQL settings wrote attack logs aggressively. Tuned postgresql.conf:

shared_buffers = 64MB
effective_cache_size = 256MB
maintenance_work_mem = 32MB
wal_buffers = 8MB

These PostgreSQL tweaks saved 100 MB of RAM.

Benchmark Results (1GB VPS, 100 concurrent users)

Metric	Without WAF	With SafeLine	Acceptable?
Avg response time	15ms	16ms	✅
Requests/sec	1,200	850	✅ (-29%)
RAM baseline	350 MB	850 MB	⚠️ tight
Peak RAM under load	450 MB	1,020 MB	⚠️ uses swap

The bottleneck was RAM, not CPU or WAF throughput. On a 2 GB VPS, throughput is 7,600 req/s. On 1 GB, it drops because the system spends cycles managing memory.

Is $5 Enough?

Use Case	$5 VPS Enough?
Static site + WAF	✅ Yes, plenty of room
Small Node/Python app + WAF	✅ Yes, with swap
WordPress + WAF	❌ No, need 2 GB minimum
Multiple apps + WAF	❌ No, get 2-4 GB
API with heavy DB queries	❌ No, CPU + RAM starved

FAQ

Why not just use Cloudflare's free plan?

Cloudflare free terminates TLS at their edge — they can see your traffic in plaintext. If you handle sensitive data, a self-hosted WAF means the traffic is decrypted and inspected on your own server. No third party sees it.

Can I run SafeLine on a Raspberry Pi instead of a VPS?

Yes. A Pi 4 with 4 GB RAM is actually more comfortable than a $5 VPS. The ARM Docker images work. Electricity costs about $5/year. Perfect for homelab use.

What if my site gets popular and outgrows 1 GB?

Upgrade to a $10/month 2 GB VPS. The WAF itself doesn't need more — your app growing is what drives the upgrade. SafeLine scales linearly: add more CPU and it handles more QPS.

What's running on your $5 VPS right now?

#webdev #devops #security #tutorial

WAF Logs Explained: How to Read and Act on Attack Data

Lia — Mon, 10 Aug 2026 03:37:39 +0000

The Dashboard Isn't Just Numbers

Your WAF blocks attacks. The Attack Logs tell you what those attacks were, where they came from, and whether any got through. Reading these logs turns random blocks into actionable intelligence.

Anatomy of an Attack Log Entry

When SafeLine blocks an attack, each log entry shows:

Time: 2026-08-06 03:12:45 UTC
Source IP: 185.220.101.34 (Russia)
Target: example.com/login
Attack type: SQL Injection
Payload: admin' OR '1'='1' --
Action: Blocked
Rule: Semantic analysis (score: 98/100)

Everything you need to understand:

When it happened (3 AM = automated, not targeted)
Where from (Russia = likely scanner, not a customer)
What they tried (SQL injection on login = credential bypass)
Confidence (98/100 = near-certain attack)

How to Read Logs for Patterns (Not Just Events)

One blocked SQL injection is noise. Ten blocked SQL injections from the same IP range, all targeting /api/graphql, at 3 AM — that's a coordinated attack. Here's what to look for:

Pattern 1: Geographic concentration

20+ attacks from Russian IPs -> all targeting /wp-login.php
-> Action: Geo-block Russia if you don't serve that market

Pattern 2: Endpoint targeting

50+ attacks on /api/graphql over 2 hours
-> Action: Add GraphQL-specific rate limiting, review query depth limits

Pattern 3: Payload evolution

Day 1: Basic SQL injection (' OR 1=1)
Day 2: Blind SQL injection (sleep functions)
Day 3: UNION-based injection
-> Action: Attacker is iterating. Block the IP range aggressively.

Pattern 4: Quiet Monday, loud Thursday

Monday: 200 blocked attacks
Thursday: 1,200 blocked attacks
-> This is normal. Attack volume spikes mid-week. Don't freak out.

What to Ignore

Not every log entry matters:

Single SQL injection probes — scanners try every URL. It'll never work on updated software.
/.env requests — automated scanners looking for Laravel config leaks. If you're not on Laravel, ignore.
Port scans — your WAF only sees HTTP. Port scans hitting closed ports are not your problem.
WordPress path scans on non-WordPress sites — harmless noise.

What to Act On Immediately

Multiple failed logins from the same IP — bump up rate limiting on auth endpoints
Successful logins from unusual locations — this gets through the WAF but should trigger application-level alerts
Any attack with confidence score > 95 — near-certain actual attack, worth reviewing what they targeted
Attacks on custom endpoints — someone mapped your API. They know your stack. Take this seriously.
Data exfiltration patterns — large outbound responses after suspicious POST requests

Using Logs to Tune Your WAF Rules

After 2 weeks of log analysis, here's what I adjusted:

Finding	Adjustment
80% of attacks from 5 countries	Enabled geo-blocking for those countries
Login endpoint hit 300x/day	Added 5/min rate limit
`/api/search` scraped by script	JS challenge for high-frequency search
Zero attacks on `/health`	Added whitelist (no inspection needed)
3 false positives on webhook receiver	Whitelisted the webhook source IP

FAQ

How long should I keep attack logs?

At least 30 days. Attack patterns emerge over weeks, not hours. SafeLine uses PostgreSQL for log storage — set retention to 90 days unless you're tight on disk space. Attackers sometimes come back after 2-3 weeks with different techniques.

What's the difference between "Blocked" and "Detected"?

"Blocked" means the request was stopped at the WAF. "Detected" means the WAF flagged it but you're in monitoring mode. Switch to blocking mode once you've confirmed no false positives for your traffic patterns.

Should I report attacks to anyone?

For most small sites: no. Law enforcement won't act on individual attack logs. If you see a coordinated, persistent attack from a specific hosting provider, you can send an abuse report to their network operations team. That occasionally works.

What's the most common attack showing up in your server logs right now?

#security #devops #webdev #monitoring

Bot Protection 101: Block Scrapers and Bad Bots Without Affecting Google

Lia — Mon, 10 Aug 2026 03:19:58 +0000

Good Bots vs Bad Bots

Not all bots are created equal.

Bots You Want	Bots You Dont Want
Googlebot — indexes your site for search	Scrapers — steal your content
Bingbot — same as Google, different engine	Credential stuffers — try leaked passwords
Ahrefs / Semrush — SEO analysis (debatable)	Vulnerability scanners — probe for weak points
Uptime monitors — Pingdom, Better Uptime	AI training crawlers — GPTBot, CCBot
Feed readers — RSS readers, Feedly	Price scrapers — competitor intelligence

The goal: block bad bots while letting good ones through. A WAF with bot detection makes this automatic.

How SafeLines Bot Protection Works

SafeLine uses three layers to identify bots:

Layer 1: Static analysis

User-Agent pattern matching against known bots
IP reputation database (known scanner IPs)
Request header consistency checks

Layer 2: Behavioral analysis

Request frequency and timing patterns
Page navigation sequences
Resource loading behavior (does it load CSS/JS/images?)

Layer 3: Active challenge

JavaScript challenge (execute JS, prove youre a browser)
CAPTCHA (image/text challenge)
Cookie validation

Setting Up Bot Protection

In SafeLine Dashboard -> Bot Management:

1. Enable Bot Detection: ON
2. Action for suspicious bots: JavaScript Challenge
3. Action for confirmed bad bots: Block
4. Whitelist: Googlebot, Bingbot, Pingdom, Stripe webhooks

Thats four settings and youre protected. The WAF handles the rest.

What It Caught on My Server

After enabling bot protection for 7 days:

Bot Type	Detected	Action
Credential stuffing attempts	2,847	Blocked
Content scrapers	1,203	JS challenged (all failed)
Vulnerability scanners	892	Blocked
AI crawlers (GPTBot, CCBot)	456	JS challenged (all failed)
SEO crawlers (Ahrefs, Semrush)	234	Allowed (didnt trigger detection)
Googlebot	3,456	Whitelisted (never challenged)

Zero legitimate users reported CAPTCHA fatigue. Google continued indexing normally.

FAQ

Will bot protection break my analytics?

No. Google Analytics, Plausible, and similar tools use JavaScript execution. Legitimate analytics are unaffected.

What about API clients (Postman, curl, SDKs)?

API endpoints with proper authentication should be added to the bot protection whitelist. Bots that authenticate with valid tokens are treated differently from anonymous scrapers.

Does it affect page load speed?

The JS challenge adds about 200ms on the first request for suspicious visitors. Legitimate users see zero delay.

Try SafeLine Community Edition — free, self-hosted, and takes 5 minutes to deploy:

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

Dashboard: https://<your-server-ip>:9443 | Docs

How much of your current traffic do you think is bots?

Geo-Blocking: Block Malicious Traffic from Specific Countries (2-Minute Setup)

Lia — Mon, 10 Aug 2026 03:19:03 +0000

Why Geo-Block?

Not every country needs to reach your server. If you run a local business in Brazil, you don't need traffic from North Korea. If you serve customers in the EU, you probably don't need visitors from 150 other countries hitting your login page.

Geo-blocking at the WAF level stops unwanted traffic before it ever reaches your application. No CPU spent. No database queries wasted. No bandwidth consumed.

The Numbers from My Server

After 30 days of logging, I checked where attacks came from:

Traffic Source	% of Total Requests	% of Attacks
Target countries (where my customers are)	23%	8%
Non-target countries	77%	92%

77% of my traffic came from countries I don't serve, and 92% of attacks originated from those countries. Geo-blocking the non-target regions would eliminate the vast majority of malicious traffic with zero impact on real users.

Setting Up Geo-Blocking in SafeLine

Step 1: Go to Allow & Deny -> Custom Rules -> Add Rules

Step 2: Choose your approach:

Step 3: Apply the rule. Done.

What Happens to Blocked Visitors

Blocked IPs see a 403 Forbidden page. They can't reach your application at all — the WAF drops the connection at the proxy layer. Your app server never sees these requests.

SafeLine logs every geo-blocked request to Attack Logs. You'll see:

Which country the IP was from
What URL they tried to access
The exact timestamp

Which Countries to Block

Based on my 30-day log analysis and common community reports:

Almost always safe to block:

North Korea — 0 legitimate traffic for 99.9% of sites
Iran — heavy scanner activity, minimal legitimate traffic (for non-Iranian sites)

High scanner volume, consider blocking if not your market:

Russia — #1 source of scans on most servers
China — heavy automated scanning
Vietnam — growing botnet activity

Block with caution (some legitimate traffic):

Brazil — high bot activity but also real users
India — large developer community but also heavy scanning

What NOT to Geo-Block

CDN IPs — Cloudflare, Fastly, Akamai. These proxy legitimate traffic. SafeLine handles this automatically.
Search engine crawlers — Googlebot, Bingbot. You want these finding your site. SafeLine's bot detection distinguishes crawlers from attacks.
Your own office/home IP — obvious, but easy to forget when you add a blanket rule.

FAQ

Can I geo-block at the city or ISP level?

Yes. SafeLine supports country, region, city, and ISP-level filtering through its IP database. For a SaaS product, you might block certain hosting providers (DigitalOcean, Vultr) if they're being used to launch attacks.

Will this affect my SEO?

No. Search engine crawlers (Googlebot, Bingbot) are never blocked by geo-rules. SafeLine identifies them by user agent and verified IP ranges. Your site remains fully crawlable regardless of geo-blocking settings.

What if a legitimate user travels to a blocked country?

They'll need to use a VPN in an allowed country. This is a known trade-off. For most small businesses, the security gain far outweighs the edge case of a traveling customer.

Try SafeLine Community Edition — free, self-hosted, and takes 5 minutes to deploy:

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

Dashboard: https://<your-server-ip>:9443 | Docs

What countries do you see the most scanner traffic from on your server?

What 30 Days of WAF Logs Taught Me About Internet Attackers

Lia — Mon, 10 Aug 2026 03:18:56 +0000

The Setup

Deployed SafeLine Community Edition on a $10/month VPS in front of 3 small websites: a WordPress blog, a Node.js SaaS app, and a static portfolio. Let it run for 30 days, blocking nothing — pure observation mode. Here's what showed up.

Day 1-3: The Welcome Party

Within 3 hours of DNS propagation, automated scanners found the server.

Attack type	Count (Day 1)	Source
WordPress path scans	847	`/wp-admin`, `/xmlrpc.php`, `/wp-content/uploads/*`
SSH brute force probes	312	(Not via HTTP — separate, but logged by fail2ban)
.env file grabs	156	`GET /.env` targeting Laravel apps
PHP unit exploit scans	89	`/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php`

Lesson: A new server is discovered by scanners within hours, not days. If you deploy a site without a WAF, you're already under attack before you finish configuring it.

Day 4-10: The Pattern Emerges

After the initial flood, attacks settled into patterns:

Peak attack hours: 2-5 AM UTC (when most US/EU admins are asleep)
Top attacking countries (by IP):

Russia — 23%
China — 18%
United States — 14% (mostly compromised VPS)
Netherlands — 9% (hosting/datacenter IPs)
Vietnam — 7%

Most targeted pages:

/wp-login.php — 38% of all attacks
/.env — 12%
/admin — 8%
/api/graphql — 5% (even on the WordPress site!)
/vendor/* — 4%

Day 11-20: The Persistent Ones

Some attacks didn't give up. One IP from a Russian VPS range attempted /wp-login.php with different credentials 4,287 times over 11 days — an average of 390 attempts per day. Without rate limiting, that's a brute force that will eventually succeed if your password is in any dictionary.

Three different IPs tried the same Log4j payload against every URL path they scanned. They didn't know the tech stack — they just spray and pray.

Day 21-30: What Changed

After 3 weeks of observation, I enabled blocking mode:

Attack type	Before (daily avg)	After (daily avg)
WordPress scans	847	0
.env grabs	156	0
SQL injection probes	203	0 (blocked at WAF)
XSS attempts	98	0
Total blocked	—	~1,300/day

1,300 attacks per day, blocked silently. No CPU spent in application code handling them. No log noise from PHP or Node.js. They hit the WAF, get blocked, and the app never sees them.

What the Attackers Never Found

My Node.js app's real vulnerabilities (they got blocked at the WAF before reaching Express)
My database credentials (.env was blocked at the path level)
Any valid WordPress user (rate limiting stopped the brute force before it made progress)

FAQ

Is a WAF really necessary for a small site?

If you have a domain name and an IP, scanners will find you. The question isn't whether you'll be attacked — it's whether those attacks reach your app or get blocked at the proxy. My small portfolio site saw 300+ attack attempts per day. It had no login, no database, and nothing to steal — but the scanners don't know that.

Do all these attacks actually work?

Most don't, if your software is up to date. But "most" isn't 100%. A WAF catches the 1% that would work, plus the 99% that just add noise. The real value is that your application doesn't have to deal with any of it.

What's the first thing I should block?

Rate limit your login page. Always. Every site has one. Every attacker tries it. One rule stops the #1 attack vector instantly.

Try SafeLine Community Edition — free, self-hosted, and takes 5 minutes to deploy:

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

Dashboard: https://<your-server-ip>:9443 | Docs

What do you think your server handles every day that you don't see?

DEV Community: Lia

LDAP and Active Directory Login for Self-Hosted Apps

How LDAP fits the picture

Step 1: Open the LDAP configuration

Step 2: The parameters in detail

LDAP Server URL

Bind DN

User baseDN

Query Condition

Step 3: Reference configs for common directories

What the login flow looks like

FAQ

Users can't log in even though the connection works?

Why is the connection failing?

What does %s mean in the query condition?

Can I filter by Active Directory security group?

My query condition has syntax errors — any tips?

OIDC Authentication with Keycloak (and Auth0, Okta, Azure AD)

What OIDC actually is

Step 1: Prepare your OIDC provider

Step 2: Configure SafeLine

Step 3: Enable OIDC on the application

What the login flow looks like

Managing users

FAQ

Can't redirect to the OIDC provider after integration?

Callback fails after the user authenticates with the provider?

What scopes does SafeLine request by default?

Do I need to write OIDC code in my app?

Which providers are supported?

How to Add GitHub Login to Your Web App with a WAF

Why do GitHub login at the WAF layer?

Step 1: Create the GitHub OAuth app

Step 2: Configure SafeLine

Step 3: Enable GitHub on the application

What happens when a user tries to log in

Managing users after login

Optional: combine it with SSO

FAQ

Do I have to write any application code for GitHub login?

Why does a new GitHub user need admin approval?

Can I use GitHub login on more than one app?

What if my traffic goes through a proxy?

Does GitHub login work together with other login methods?

Add Authentication and SSO to Any Web App Without Changing Code

Why do auth at the WAF layer?

Simple Auth vs SSO: two ways to gate access

Simple Auth: password-protect a single app

SSO: one login, every app

Enabling SSO

Adding apps to SSO

The four login methods

Account + Password

GitHub

OIDC

LDAP

Passing the authenticated user into your app

Approvals and conditional auth

Wrapping up

FAQ

Does adding auth at the WAF layer slow down my app?

Can I use SSO for both internal and public apps?

Which identity provider should I pick?

Do I have to modify my app to know who logged in?

Does SafeLine's SSO support single logout?

How to Protect Multiple Websites with One WAF Instance

The Multi-Site Use Case

Adding Multiple Sites to SafeLine

Per-Site Rules Without Per-Site WAFs

SSL Certificate Management

Resource Usage at Scale

Traffic Isolation

Save Money: Replace Per-App Security Tools

FAQ

Can I mix HTTP and HTTPS sites on the same WAF?

What if one site gets a huge traffic spike?

Can I give separate dashboard access to different clients?

How to Block SQL Injection Attacks with a Free WAF

SQL Injection Is Still the #1 Threat in 2026

What SQL Injection Looks Like

What does `%s` mean in the query condition?