DEV Community

Lia
Lia

Posted on

How to Protect an E-commerce Site with a WAF

#ecommerce #waf #checkout #botdefense

An online store is still a web application. Product search, login, reviews, coupons, and checkout are HTTP requests that happen to move money and inventory. SQL injection in a search parameter, cross-site scripting in a review, path traversal in a file URL, brute force on a login, and bot traffic against a cart all look like ordinary requests until they are filtered. A WAF is the layer that filters and monitors that traffic. It is not a substitute for server-side price checks, and these sources do not describe a plugin for any particular cart, payment processor, or storefront platform. The practical question is whether you can put your own hostname behind a reverse proxy and prove the shopper path still works.

SafeLine is a self-hosted WAF. Its documentation says it protects web apps by filtering and monitoring HTTP traffic between the application and the Internet, and that deploying it places a shield in front of the app. Clients reach the WAF first. SafeLine cleans malicious traffic and forwards the remaining requests to the upstream application. That is the whole integration these documents support: domain, listen port, upstream, and DNS pointed at the SafeLine host (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Start with the paths you control

Before you change a production record, list the hostnames you own. A catalog, an account site, a checkout application that terminates on your origin, and an admin panel can be proxied if you know the real upstream address. A payment page that lives only on another company's domain is outside this model. SafeLine cannot inspect traffic that never arrives at the application you added.

For each hostname, record the public port, whether shoppers use HTTPS, and the upstream address SafeLine should use. In the web console, open Applications, choose Add Application, and enter the domain, the port SafeLine will listen on, and the upstream. For an HTTPS app, check the SSL option. Then resolve that domain to the SafeLine server. Visitors should reach the store only through that proxy (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

Split the checklist by risk, not by department name:

  • Catalog and search URLs, where parameters are easy to abuse.
  • Account actions, especially login and password reset.
  • Cart and order actions that hit your origin, including coupon fields.
  • Admin and staging hostnames, which should not share a loose policy with the public grid.

Prices, stock, and payment status still have to be enforced in the application. Blocking a malicious request does not make a cart total trustworthy.

Use only the controls the docs actually name

The product introduction lists defenses against 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. Core capabilities named on the same page are web attack defense, proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list (https://docs.waf.chaitin.com/en/home).

Attack filtering is the baseline. The add-application guide includes test cases for SQL injection, XSS, path traversal, code injection, and XXE. It says a blocking page means the attack was defended, and that the console attack list shows the event, with a detail view for the specifics. Run those cases on a staging domain, not against live customer sessions.

Rate limiting is documented as throttling traffic that exceeds defined limits, aimed at DoS attacks, brute-force attempts, traffic surges, and other abuse. On a store, the candidates are login, password reset, coupon attempts, and repetitive inventory checks. Because the documented control is IP-based, a sale can also cluster many real shoppers behind one address. Watch blocks during a rehearsal, not only during an attack.

CAPTCHA challenge is documented as a way to allow human users while blocking crawlers and bots. Use it when scripted traffic is the problem. Do not assume it belongs on every product image request. Authentication challenge is different: when it is turned on, visitors must enter a password or they are blocked (https://docs.waf.chaitin.com/en/home). That is a reasonable gate for a private admin or staging hostname. It is a poor default for a public catalog.

Dynamic protection encrypts HTML and JavaScript on each visit. Storefronts depend on those scripts for galleries, carts, and embedded payment steps. Enable it only after a full click-through on a copy of the site: home, search, product, cart, login, and the checkout pages you host. If a page stops working, leave the control off for that application until you understand the breakage. The documents do not provide a per-framework exception list.

The same introduction publishes an effect evaluation on 33,669 samples. It lists SafeLine Balance at 71.65% detection, 0.07% false positive, and 99.45% accuracy, and SafeLine Strict at 76.17% detection, 0.22% false positive, and 99.38% accuracy (https://docs.waf.chaitin.com/en/home). Treat those figures as a published lab result, not as a prediction of checkout false positives. A store should still measure its own paths.

Rehearse the cutover on a small, correct host

The deploy guide requires Linux, x86_64 or arm64, Docker 20.10.14 or newer, and Docker Compose 2.0.0 or newer. The minimum environment is 1 CPU core, 1 GB of memory, and 5 GB of disk, and the CPU must support SSSE3. Confirm architecture, Docker versions, CPU flags, memory, and disk with the commands on that page before you install (https://docs.waf.chaitin.com/en/GetStarted/Deploy). A sale can exceed a minimum lab host. These documents do not publish checkout sizing, so capacity is your measurement, not a product claim.

ARM is a licensing constraint, not just an architecture flag. The deploy guide says SafeLine on ARM requires a Pro license to work properly, and that the Personal Edition is not supported on ARM. Check that before you build a store stack on an ARM machine.

After installation, the documented way to open the console is https://:9443/ when the management port is left at the example value 9443. Reset the administrator from the documented container command, store that initial password, and add the staging application first. Prove a normal browse, login, add-to-cart, and origin checkout. Prove the documented attack cases block and appear in the attack list. Then lower DNS TTL, point the production name at SafeLine, and keep the old record ready for rollback.

If you remove the proxy later, the uninstall steps are to enter the SafeLine directory, run docker compose down, and delete that directory. Do that only after DNS no longer sends shoppers to the WAF.

Does a WAF replace secure checkout code?

No. SafeLine is documented as a reverse proxy that filters and monitors HTTP traffic, blocks malicious requests, and applies policies that separate unsafe traffic from traffic forwarded upstream (https://docs.waf.chaitin.com/en/home). Order totals, coupon rules, session ownership, and payment authorization remain application responsibilities.

Can this protect a payment page on another company domain?

Only if that page is actually served through a hostname you proxy. SafeLine receives traffic for the application you add and forwards clean traffic to your upstream (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). Traffic that never reaches that hostname is not in scope. Do not plan on an undocumented processor integration.

Which controls fit a public catalog versus an admin host?

Keep web attack defense on for the catalog, then add rate limiting where brute force or floods are plausible and review IP-based false blocks. Use CAPTCHA when you need humans to pass and bots to fail. Keep authentication challenge for admin or staging, because it blocks visitors who do not enter the password. Test dynamic HTML and JS encryption on a staging copy before the public storefront.

How do I confirm shoppers are passing through SafeLine?

The domain in the application dialog must resolve to the SafeLine server, and the upstream must be the real store address. A normal page should load through that path. The attack cases in the add-application guide, pointed at your staging domain, should show the blocking page, and the console attack list should show the detail.

What should be true before a sale uses this path?

The host should meet the documented OS, CPU, Docker, and disk minimums, with ARM licensing settled if you are not on x86_64. Staging should already cover browse, login, cart, and the checkout you host. You should have a DNS rollback. You should not enable authentication challenge or dynamic encryption on the public site until those rehearsals pass.

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.

Top comments (0)