A GraphQL API is still an HTTP application, which is the only reason a web application firewall belongs in the conversation. SafeLine is documented as a self-hosted WAF that filters and monitors HTTP traffic between a web application and the Internet, and that blocks malicious HTTP/S requests before they reach the app (https://docs.waf.chaitin.com/en/home). The same pages do not describe a GraphQL parser, a query-cost engine, or an introspection switch. This guide is a decision checklist for putting that reverse proxy in front of a GraphQL route without pretending those missing controls exist.
Begin with the path, not with a rule pack. SafeLine is a web application firewall developed on nginx. It acts as an HTTP/HTTPS reverse proxy: it receives traffic for the original site, cleans malicious attack traffic, and forwards safe traffic upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). In the web console you add an application with the public domain, hostname, or IP; the port SafeLine will listen on, such as 80 or 443; and the upstream address of the real GraphQL service. For HTTPS, the same guide says to check the SSL option. Then resolve that public name to the SafeLine server. If DNS still points at the API host, every later control is bypassed.
Next, write down what the WAF is allowed to own. The introduction lists defenses for SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoors, brute force, HTTP flood, and bot abuse (https://docs.waf.chaitin.com/en/home). Core capabilities on that page are web-attack defense, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. Rate limiting is described as throttling traffic that exceeds defined limits, including DoS attempts, brute force, and traffic surges. Those controls are relevant to GraphQL because many attacks arrive as ordinary HTTP: a hostile argument in a JSON variable, a flooded POST to /graphql, or a scanner probing the same route. They are not a substitute for schema rules.
Be explicit about controls that do not map cleanly onto an API. Captcha challenge is documented as a way to let human visitors through and block crawlers and bots (https://docs.waf.chaitin.com/en/home). That can fit a browser client. It is a poor default for a service-to-service GraphQL caller that cannot solve a challenge. Authentication challenge, on the same page, blocks visitors until they enter a password. That is a site password gate, not GraphQL token validation, and the docs do not say it understands bearer tokens or operation names. Dynamic protection encrypts HTML and JS on each visit. Leave it off the GraphQL checklist unless the same hostname also serves pages.
Keep the GraphQL-specific work in the service. Nothing in the supplied guides says SafeLine limits query depth, rejects aliases, caps batched operations, hides introspection, or authorizes a field. Those checks belong in the API even when the WAF is healthy. A practical split is simple: SafeLine reduces generic web attacks, floods, and unwanted clients at the HTTP layer; the GraphQL runtime enforces who may run which operation and how expensive that operation may be. If you need a feature the docs do not list, do not configure toward it. Treat the absence as a boundary.
Check the host before you publish the name. The install guide requires Linux, x86_64 or arm64, Docker 20.10.14 or newer, Docker Compose 2.0.0 or newer, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk, plus SSSE3 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). It also states that SafeLine installed on ARM requires a Pro license and that the Personal Edition is not supported on ARM. That license note is a deployment decision, not a GraphQL feature. Confirm architecture before you promise the endpoint.
Prove the proxy with the documented samples, not with an invented GraphQL payload. The application guide gives test URLs for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was stopped (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Replace the sample domain with yours. Then open the console attack list and click detail. A block plus a log entry shows that traffic passed through SafeLine. It does not show that every GraphQL abuse case will match a signature. After that test, confirm the upstream port is not reachable from the Internet, that rate limits cover the GraphQL route, and that real clients still succeed.
The home page states that SafeLine is production-ready (https://docs.waf.chaitin.com/en/home). As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price. Use those commercial notes only as stated here; do not infer extra editions, modules, or GraphQL add-ons from them.
Does SafeLine document GraphQL query inspection?
No. The official pages describe HTTP and HTTPS filtering, a reverse proxy, and general web-attack defenses. They do not document query parsing, depth limits, or introspection control. Use the checklist above and keep those policies in the API.
Which documented SafeLine controls belong on a GraphQL hostname?
Web-attack defense, IP-based rate limiting, the web access control list, and, where the client is a browser, captcha or authentication challenge. Rate limiting is the control most teams should review first, because a single GraphQL route can concentrate traffic. Confirm each setting in the console rather than assuming a GraphQL profile exists.
Do I need a separate listener for GraphQL?
Not according to the application guide. You protect the site by domain, listen port, and upstream. If GraphQL is the only app on that hostname, one application entry is enough. If pages and the API share a name, remember that HTML and JS dynamic protection is a page feature, not an API feature.
How should I test without bypassing the WAF?
Send the documented sample attacks to the public domain that resolves to SafeLine, expect the blocking page, and read the attack detail in the console. Also request the real GraphQL route with a normal query from an allowed client. Both results matter: a block with no successful client path is not a finished rollout.
What remains my responsibility after the proxy is live?
Resolver authorization, query cost, batching policy, error hygiene, and upstream network exposure. SafeLine can filter malicious HTTP traffic and throttle excess requests as documented. It does not become the GraphQL authorization layer.
If this checklist matches the way your GraphQL API is exposed, read the install guide and the application guide, then review the project and the current promotion before you pick a host.
Official project: https://github.com/chaitin/SafeLine
Docs: https://docs.waf.chaitin.com/en/home
Install guide: https://docs.waf.chaitin.com/en/GetStarted/Deploy
Application setup: https://docs.waf.chaitin.com/en/GetStarted/AddApplication
Promotion: https://cyberserval.tech/landing/lto
Top comments (0)