How to Protect a GraphQL API with a Reverse-Proxy WAF

GraphQL rarely looks like a traditional multi-page site. Most APIs expose one HTTP endpoint, accept a JSON document, and return another JSON document. That shape tempts teams to skip a web application firewall, or to expect the firewall to understand selections, fragments, and resolver cost. Neither shortcut is sound. This is a decision checklist for placing a general HTTP WAF in front of a GraphQL API without treating undocumented behavior as a feature.

Start with the traffic path, not the schema. SafeLine is a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between an application and the Internet. The official introduction describes a reverse proxy: clients pass through SafeLine before they reach the server, SafeLine filters and monitors HTTP/S traffic, blocks traffic its policies treat as malicious, and is also described as preventing unauthorized data from leaving the app. The application guide adds that SafeLine is developed on nginx, receives traffic for the original site, cleans malicious attack traffic, and forwards safe traffic to the upstream application (https://docs.waf.chaitin.com/en/home, https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Those pages describe HTTP protection. They do not describe a GraphQL parser, query-depth limiter, persisted-query allowlist, or cost analyzer. If you need schema-aware blocking, keep it in the GraphQL server or gateway. Use the WAF for the HTTP problems the docs actually name.

What this checklist decides

Answer these points before you change DNS.

1. Is the GraphQL API reached over HTTP or HTTPS? SafeLine is documented as filtering HTTP/S traffic. A resolver that never accepts external HTTP is a different problem, and this checklist does not cover it.
2. Can every caller tolerate a reverse proxy? Documented setup asks for a domain, hostname, or IP; a listen port such as 80 or 443; the SSL option for HTTPS apps; and an upstream address. You then resolve that domain to the SafeLine server (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Browser apps, mobile apps, and server-to-server callers must accept the extra hop and the certificate you present.
3. Which documented controls match this API? Core capabilities listed in the introduction are defenses for web attacks, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. The feature list adds rate limiting for DoS attacks, bruteforce attempts, traffic surges, and other abuse; CAPTCHA challenges that allow human users and block crawlers and bots; an authentication challenge that blocks visitors who do not enter a password; and dynamic protection that encrypts HTML and JS on each visit (https://docs.waf.chaitin.com/en/home).
4. Which of those controls would break legitimate clients? A JSON API used by scripts should not silently depend on CAPTCHA or a password page. Dynamic HTML and JS encryption does not protect a response that is only JSON. IP rate limits can blunt floods and credential stuffing, but they do not measure query complexity.
5. Which threats stay in the application? Depth limits, alias limits, complexity budgets, authorization on every resolver, introspection policy, batching limits, and timeouts are GraphQL controls. A WAF checklist does not replace them.

Map documented defenses to the HTTP surface

The introduction lists SQL injection, XSS, code injection, OS command injection, CRLF injection, LDAP injection, XPath injection, RCE, XXE, SSRF, path traversal, backdoor, bruteforce, HTTP flood, and bot abuse, among others (https://docs.waf.chaitin.com/en/home). GraphQL does not remove those classes. A resolver that concatenates a variable into SQL, a shell command, a file path, or an outbound URL can still be attacked. The payload may arrive in a query string, a header, or a JSON body.

The application guide demonstrates blocking with URL samples for SQL injection, XSS, path traversal, code injection, and XXE, and it tells you to replace the sample domain with your own. A blocking page means the test was stopped, and the web console attack list plus its detail view is the documented place to inspect it (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Use those samples as HTTP smoke tests against the protected domain. Do not treat them as proof that every GraphQL operation was semantically parsed. After the smoke tests, send benign queries and mutations, including large but legitimate documents, and confirm that normal API traffic still reaches the upstream.

Rate limiting is the control most API teams reach for first. The docs describe throttling traffic that exceeds defined limits, and they list IP-based rate limiting among core capabilities. That is a useful backstop against HTTP floods, bruteforce, and traffic surges. It is still a coarse gate. Ten cheap operations and one deeply nested operation can look identical at the IP layer. Keep a complexity limit in the GraphQL service if expensive queries are in your threat model.

Bot and authentication challenges need an explicit client decision. CAPTCHA is documented as allowing human users while blocking crawlers and bots. The authentication challenge requires a password, otherwise the visitor is blocked. Both can fit a browser-only console. They are a poor default for a machine client that posts JSON to a single endpoint. If you enable either one, test every first-party caller before cutover.

Deployment checks that the docs actually specify

Installation is not GraphQL-specific. The deploy 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. The CPU must support ssse3. The same page states that SafeLine installed on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Confirm architecture, Docker versions, memory, disk, and ssse3 before production DNS points at the proxy.

Both the documented automatic install and the manual compose flow end at the same operating model: a web console on port 9443 by default, an administrator account created with docker exec safeline-mgt resetadmin, and an application entry with domain, port, SSL, and upstream. For this use, the upstream is the real address of the GraphQL service. The domain clients already use should resolve to SafeLine. If clients expect HTTPS, use the documented SSL option. After cutover, run the official sample attacks against your domain, confirm the blocking page, then run ordinary GraphQL operations and confirm they still succeed.

The introduction calls SafeLine production-ready, protecting over 1,000,000 websites and handling over 30,000,000,000 HTTP requests daily (https://docs.waf.chaitin.com/en/home). That statement is about HTTP handling, not about GraphQL semantics. As of September 30, 2026, SafeLine surpassed 700,000 installations worldwide. Those figures do not size your node. The minimum environment in the deploy guide is an installation floor, not a capacity promise for a busy API.

A practical order of work

1. Inventory callers: browsers, mobile apps, partner servers, and CI jobs.
2. Confirm the API is external HTTP/S and that DNS can move to a reverse proxy.
3. List threats you expect an HTTP WAF to see: injection payloads, path traversal, floods, bruteforce, and bot abuse.
4. List threats you will not assign to it: query depth, resolver authorization, and schema leaks.
5. Install only on a host that meets the documented dependencies. If the host is ARM, plan for Pro.
6. Add the application with domain, listen port, SSL when needed, and the GraphQL upstream.
7. Smoke-test with the documented attack URLs, then with real GraphQL operations.
8. Enable rate limiting only after you know normal request rates. Leave CAPTCHA, the authentication challenge, and HTML/JS dynamic protection off unless a browser client needs them and you have tested the result.
9. Watch the console attack list during a canary window before you retire the old path.

That order protects the HTTP front door. It does not promise a GraphQL integration the official sources do not document.

Does SafeLine document a GraphQL rule set?

No. The official pages describe an HTTP/HTTPS reverse proxy, web-attack defenses, rate limiting, bot and authentication challenges, dynamic HTML and JS protection, and an access control list. They do not document GraphQL query parsing or schema-aware policies. Keep those controls in the API.

Can IP rate limiting replace query cost limits?

No. Documented rate limiting throttles traffic that exceeds defined limits, including IP-based limiting. That helps with floods, bruteforce, and surges. It does not calculate GraphQL complexity. Use both if expensive queries are a real risk.

Should a GraphQL API use the authentication challenge?

Only when every legitimate caller can complete it. The documented behavior blocks visitors who do not enter the password. Machine clients that post JSON will fail closed if you enable it without a separate tested path.

How do I know the proxy is in front of the API?

Follow the application guide: set domain, port, SSL when required, and upstream, then resolve the domain to the SafeLine host (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Traffic to that domain should reach SafeLine before the GraphQL process. Use the console attack list to inspect blocked tests.

What should stay off for a JSON-only API?

Leave HTML and JS dynamic encryption off. That feature encrypts HTML and JS returned by the web server on each visit, which does not authorize GraphQL operations. Leave CAPTCHA off for non-browser callers unless every client has a tested fallback.

If you are deciding whether a reverse-proxy WAF belongs in front of your GraphQL service, read the official docs, reproduce the documented install and application flow in staging, and compare the attack list with your own benign queries before you change production DNS. I welcome questions about that checklist, especially where client behavior and rate limits interact. SafeLine Pro annual promotional pricing is $650-$880 versus the $1,000 regular price.

Project: https://github.com/chaitin/SafeLine
Docs: https://docs.waf.chaitin.com/en/home
Promotion: https://cyberserval.tech/landing/lto