How a Small Engineering Team Secured Their Self-Hosted Stack with SafeLine WAF

Source: Dev.to

Introduction

When people talk about Web Application Firewalls, the conversation often revolves around large enterprises, managed cloud services, or expensive SaaS subscriptions. For many developers running self‑hosted applications, the reality is different. This is the story of a small engineering team that runs production workloads on its own infrastructure and deployed SafeLine WAF to solve very practical problems.

The Team’s Environment

• Public‑facing services
  • Customer portal built with a modern web framework
  • Internal APIs exposed for mobile clients
  • Legacy admin panels that can’t easily be rewritten
• Infrastructure
  • Dockerized services
  • Nginx as a reverse proxy
  • Deployed on a VPS + on‑prem hybrid setup

Challenges Faced

Initially the setup worked well—until it didn’t. Logs began to show patterns that were hard to ignore:

• Constant bot traffic probing /wp-login.php, /admin, /phpmyadmin
• Automated scanners testing common SQL‑injection payloads
• Credential‑stuffing attempts against login endpoints
• Crawlers aggressively scraping APIs, driving up bandwidth and CPU usage

Rate limiting in Nginx and basic firewall rules helped a bit, but none of them addressed the application‑layer behavior. The team needed more than just IP blocking; they needed to understand intent.

Evaluating Options

Managed Cloud WAF

Pros:

• Turnkey protection

Cons:

• Data locality concerns
• Limited control over detection logic
• Recurring costs that don’t scale for small deployments
• Dependency on external infrastructure for core security

For a team that already self‑hosts everything, outsourcing the security layer felt like a mismatch.

Self‑Hosted WAFs

The team began looking at self‑hosted solutions. SafeLine caught their attention because it does not position itself as “rules and regexes.” Instead, it focuses on semantic analysis of HTTP traffic—examining the meaning of requests rather than matching predefined patterns.

Deploying SafeLine

SafeLine was deployed as a reverse proxy in front of the existing services:

Internet → SafeLine WAF → Nginx / App Containers

Installation was straightforward using Docker:

• No kernel modules
• No traffic mirroring
• No invasive changes to application code

Immediate Benefits

Once traffic was routed through SafeLine, the team could immediately observe:

• Request classification
• Attack logs with clear reasoning
• Minimal false positives on normal traffic
• No noticeable performance degradation

Impact on Traffic

• Automated scanners were identified and blocked early
• Scrapers were throttled without breaking legitimate clients
• Login abuse dropped significantly

SafeLine intercepted:

• SQL‑injection attempts embedded in query parameters
• XSS payloads in form submissions
• Suspicious API calls abusing edge cases

No custom rules were required.

Added API Security

Beyond traditional WAF duties, SafeLine provided:

• Request structure validation
• Abnormal behavior detection
• Protection against malformed or abusive payloads

This added a missing layer of defense for APIs exposed to mobile clients and third‑party integrations.

What Worked Well

• Strong protection out of the box
• Low false‑positive rate
• Fully self‑hosted, predictable behavior
• Clear logs that developers could actually understand

Considerations

• Basic ops knowledge (Docker, networking) is still required
• SafeLine is not a CDN replacement
• Tuning advanced scenarios takes some time

For a team already comfortable running infrastructure, these trade‑offs were reasonable.

Results After Production Use

• Security incidents dropped dramatically
• Logs became quieter—and more meaningful
• Engineers spent less time firefighting random traffic
• Confidence in exposing services publicly increased

SafeLine didn’t replace good application design or authentication, but it made attacks boring again—exactly what a WAF should do.

Who Should Consider a Self‑Hosted WAF Like SafeLine

• Teams running self‑hosted or hybrid infrastructure
• Those who care about control, transparency, and data locality
• Developers wanting real application‑layer protection without handing traffic to a third party

Sometimes the best security improvement isn’t adding more code; it’s putting something smart in front of it.