Self-Hosted API Protection: How to Put a WAF in Front of Your API
APIs are where the valuable data lives — and where attackers go first. A public API endpoint is a direct door to your logic, your database, and your users' sessions. If you self-host your API, you can also self-host its first line of defense: a WAF sitting in front of it, filtering traffic before it reaches your handlers.
Here's how to protect a self-hosted API with a WAF, and where SafeLine fits.
Why APIs are attractive targets
Unlike a rendered web page, an API speaks machine-to-machine — and that means requests are structured, predictable, and easy to script. Attackers go after:
- Authentication endpoints — credential stuffing, token abuse, brute force.
- Injection in parameters — SQL or command injection through query strings and JSON bodies.
- Abuse and scraping — automated clients hammering endpoints for data or compute.
- Malformed payloads — probing for parser or deserialization bugs.
A WAF can't fix a broken auth scheme, but it can stop the bulk of automated abuse at the edge.
What a WAF does for an API
Placed as a reverse proxy in front of your API service, a WAF:
- Inspects every request, including JSON bodies and query parameters, for attack patterns.
- Blocks injection and known malicious payloads before they reach your code.
- Rate limits per client, per key, or per path — so one abusive caller can't monopolize the API.
- Manages bots, separating automated tooling from legitimate integrations.
Where SafeLine fits
SafeLine is a self-hosted WAF that runs in reverse-proxy mode, so you point your API's traffic at it and it forwards clean requests to your upstream service. For API protection specifically:
- Its semantic detection engine analyzes request content — parameters, headers, and bodies — to catch injection and malicious payloads that static rules miss.
- Rate limiting can be applied per path, which is ideal for throttling login, token, or search endpoints.
- It's self-hosted and free to run (Community Edition covers up to 10 apps at 800 QPS), so protecting an internal or public API doesn't add a vendor bill.
SafeLine won't replace proper auth and input validation in your code — but it removes the flood of automated junk so your application logic only sees traffic worth handling.
Putting it in front of your API
Deploy SafeLine as the proxy in front of your API service:
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
In the console at https://<your-server-ip>:9443, add a site whose upstream is your API (for example http://127.0.0.1:8080). Route your API's DNS or gateway at SafeLine's listener, then set rate limits on your most-sensitive paths (auth, token refresh). From there, every request is filtered and throttled before it touches your API.
FAQ
Does a WAF replace API authentication?
No. You still need solid auth and authorization in your app. A WAF stops automated abuse and injection; it doesn't decide who's allowed in.
Will it break legitimate API clients?
Rate limits are set above normal client behavior, and the detection engine targets malicious patterns — legitimate requests pass through. Test against your real client traffic when configuring.
Can it inspect JSON request bodies?
Yes — a semantic engine evaluates the request content, including structured bodies, rather than only matching URLs or headers.
Is this free to self-host?
The Community Edition is free to run indefinitely and covers up to 10 apps at 800 QPS, which is plenty for a typical API footprint.
That's it — your API now has a filtering and rate-limiting layer in front of it.