An online store is still a web application. Catalog search, account login, cart updates, and the staff console all arrive as HTTP or HTTPS requests. A web application firewall does not replace server-side validation, payment-provider controls, or careful coding. It can sit in front of the origin and filter that traffic. SafeLine is a self-hosted WAF that protects web apps by filtering and monitoring HTTP traffic between the application and the Internet, blocking malicious HTTP/S requests, and working to prevent unauthorized data from leaving the app, as described in the product introduction (https://docs.waf.chaitin.com/en/home). The supplied documents do not describe a store-platform plugin, a payment connector, or a checkout rule pack. Treat this as a placement and control checklist, not as a promise of an e-commerce integration.
Decide the protection unit before you debate individual attacks. SafeLine is a web application firewall developed on nginx. It acts as an HTTP and HTTPS reverse proxy: it receives traffic for the original site, cleans malicious attack traffic, and forwards the remaining traffic to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). In the console, an application is defined by a domain, hostname, or IP, a listen port such as 80 or 443, an SSL choice for HTTPS, and an upstream address. Shoppers reach the protected site only after that domain resolves to the SafeLine server. If DNS still points at the origin, none of the controls below see the request.
That application object is the practical boundary for an online store. The sources do not document a cart-path plugin or a per-URL policy builder. If the public catalog, the account hostname, and the staff console need different exposure, give them separate application entries rather than assuming one toggle can mean something different on /search and /admin. A staging hostname is the right place to prove a control before a sale. A staff hostname is the right place for a gate you would never put in front of ordinary shoppers.
Inventory the traffic anyway, even if the product unit is the application. Write down public catalog and search, account and session actions, cart and checkout posts, and staff or admin hostnames. Note which ones change state, which ones accept free text, and which ones must stay fast during a launch. A blocked product image is an annoyance. A missed bruteforce run against login, or an injection payload in a search parameter, is a different incident. The inventory tells you which hostname should carry the stricter control. It does not invent a feature the console does not show.
Map only documented controls onto those hostnames.
Web attack defense is the baseline for every application that faces the Internet. 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 the attack classes a WAF of this type is meant to address (https://docs.waf.chaitin.com/en/home). On a store, search parameters, review fields, and account forms are common places those classes show up. Keep parameterized queries and output encoding in the application. The WAF is an additional filter, not evidence that the code is safe.
IP-based rate limiting is the control to decide for hostnames that suffer volume. The feature list describes throttling traffic that exceeds defined limits in order to defend against denial-of-service attempts, bruteforce attempts, traffic surges, and other abuse (https://docs.waf.chaitin.com/en/home). A shared carrier address can represent many shoppers, so a limit that is sensible for a staff login can be too tight for a public catalog during a promotion. Record the limit in plain language, try it on staging, and watch real sessions before the campaign.
A CAPTCHA challenge answers a different question. When it is turned on, human visitors are allowed through and crawlers and bots are blocked (https://docs.waf.chaitin.com/en/home). That can be reasonable on an account hostname where automated signup or login abuse is the concern. It is a weak default for every catalog asset, because monitoring and legitimate automated fetches may look like bots. Do not describe rate limiting and CAPTCHA as interchangeable. One limits volume. The other challenges clients that are not human.
Authentication challenge is narrower still. When it is turned on, visitors must enter the password or they are blocked (https://docs.waf.chaitin.com/en/home). That is a site gate, not a shopper account system and not a substitute for your store login. It can fit a staging store or a staff-only hostname. Do not enable it on the public catalog and expect normal browsing or checkout to continue.
Dynamic protection encrypts HTML and JavaScript from the web server on each visit when it is turned on (https://docs.waf.chaitin.com/en/home). A storefront depends on scripts for carts, recommendations, and embedded payment steps. The sources do not promise compatibility with every storefront script, so treat this as a staging test: enable it, load a product page, sign in, and complete a test order. If the page no longer behaves, leave the control off until you understand the breakage. Do not discover that on launch day.
A web access control list is named as a core capability (https://docs.waf.chaitin.com/en/home). Use the idea only for a decision you can state clearly, such as keeping a staff hostname separate from the public store. The supplied pages do not include rule syntax, so this checklist does not invent allow or deny commands.
Infrastructure checks come before the first application entry. The deploy guide requires Linux on 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 (https://docs.waf.chaitin.com/en/GetStarted/Deploy). An ARM installation needs a Pro license to work properly; the Personal Edition is not supported on ARM. The published minimum is a floor, not a sizing guide for a sale. Confirm free disk and memory on the host that will proxy live traffic, and do not place the data directory on a volume that is already nearly full.
Add the store only after those checks. Log in to the web console, open Applications, and choose Add Application. Enter the domain shoppers use, the listen port, the SSL option for HTTPS, and the upstream address of the original app (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Then resolve that domain to the SafeLine server. Repeat the same fields for a separate staff or staging hostname if those properties should differ. Until DNS points at SafeLine, the live name is unprotected.
Verify with the published test cases, substituting your own domain. The add-application guide includes samples for SQL injection, XSS, path traversal, code injection, and XXE, and says a blocking page means the attack was defended (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). After each sample, open the attack list and click detail. Then load a normal product page, sign in, and complete a staging checkout. A proxy that blocks the samples and also blocks a legitimate cart post is not ready. Re-test one sample after any later control change so you know inspection still fires.
For launch week, keep the operating list short. Confirm the SSL choice matches the certificate path you intended. Confirm the upstream is the current origin, not an old staging box. Review blocked events on the account and staff applications before you raise a rate limit. None of those steps requires an undocumented payment integration.
Which storefront names should I proxy first?
Proxy the public shop hostname first, then add separate application entries for account or staff names if they need a different gate. Catalog pages still need web attack filtering. Bruteforce and flood decisions matter more where a client can change state or guess credentials. Path priority is an operator choice. It is not a built-in store profile in these documents.
Does a WAF replace checkout validation or payment-provider controls?
No. SafeLine receives traffic, cleans malicious attack traffic, and forwards the rest to the upstream application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). These sources do not say it tokenizes cards, calls a payment API, or certifies a checkout flow. Keep server-side validation, session checks, and the payment provider's own controls.
How do I confirm requests are actually inspected?
Resolve the store domain to the SafeLine server, add the application with the correct domain, port, SSL setting, and upstream, then send a documented attack sample to your own domain. A blocking page plus a row in the attack list, opened with detail, is the confirmation step in the official guide (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Repeat the check with a normal product view and a staging purchase.
When should I use rate limiting instead of a CAPTCHA challenge?
Use IP-based rate limiting when the problem is volume: login guesses, traffic surges, or repeated abuse against one application (https://docs.waf.chaitin.com/en/home). Use a CAPTCHA challenge when you need to separate human visitors from crawlers and bots. A sale hostname may need a higher limit and no challenge. An account hostname may need a challenge after you have measured false blocks on staging.
What should I check before I add the store application?
Check CPU architecture, Docker and Docker Compose versions, memory, disk, and ssse3 against the deploy guide (https://docs.waf.chaitin.com/en/GetStarted/Deploy). If the host is ARM, plan for a Pro license, because the Personal Edition is not supported there. Only then create the application and move DNS.
SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.