DEV Community

禾
禾

Posted on

Why I Do Not Enable Every WAF Control on Every Store Page

#ecommerce #waf #checkout #botdefense

An online store does not become safer because every firewall control is switched on at once. It becomes safer when shopper traffic actually passes through a reverse proxy, malicious HTTP is filtered, and extra challenges are reserved for flows that can tolerate them. I use that order on purpose. A catalog page, a search box, a login form, and a checkout request are different kinds of traffic, even when they share one domain. The practical version of how to protect an e-commerce site with a WAF is this decision, not a promise that a cart plugin will appear.

SafeLine is a self-hosted web application firewall. It protects web apps by filtering and monitoring HTTP traffic between the application and the Internet. Deployed in front of the origin, it is a reverse proxy: clients pass through the WAF before they reach the server. It applies policies that decide which traffic is malicious and which traffic is safe, and it is described as preventing unauthorized data from leaving the app (SafeLine introduction). For a store, that means inspect the requests your application already receives. These pages do not describe a native connector for a named shopping cart, payment gateway, or inventory system.

Put the existing store behind the proxy

SafeLine is developed on nginx. Its job is to receive network traffic for the original website, clean malicious attack traffic, and forward safe and reliable traffic to the original application (add an application). In the web admin console, open Applications and click Add Application. Enter the domain, hostname, or IP of the original app, the port SafeLine will listen on, and the upstream address of the real application. For an HTTPS app, check the SSL option. The guide uses ports such as 80 and 443 as listener examples. After that, resolve the domain to the IP of the server where SafeLine is running. Shoppers should then reach the store through that protected name.

If DNS still points at the origin, the WAF never sees the request. Attack filtering, rate limiting, and bot challenges all depend on that path. The upstream should stay the store you already run. Do not treat the firewall as a new commerce platform. Proxy the HTTP application, then prove the path with a test request.

The machine has to meet the published install floor before any of this matters. The install guide requires Linux, x86_64 or arm64, Docker 20.10.14 or above, Docker Compose 2.0.0 or above, and at least 1 CPU core, 1 GB of memory, and 5 GB of disk. The CPU must support the ssse3 instruction (install guide). An ARM install requires a Pro license. The Personal Edition is not supported on ARM. I read those lines as eligibility checks. They are not a sizing guide for a flash sale, and the guide does not publish storefront throughput figures, so I will not invent one.

Separate attack blocking from shopper friction

The introduction lists defenses for web attacks such as 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 also include proactive bot-abuse defense, HTML and JS code encryption, IP-based rate limiting, and a web access control list. I want the attack defenses on the proxied store, because search fields, account forms, and coupon parameters are ordinary injection targets. That baseline does not require me to challenge every human who opens a product page.

Rate limiting is a separate decision. The feature description says it defends apps against denial-of-service attacks, brute-force attempts, traffic surges, and other abuse by throttling traffic that exceeds defined limits. On a store, I map that to repetition: repeated login attempts, repeated password resets, or a flood against a cheap endpoint. I do not borrow a requests-per-minute number from another site. These documents do not publish a checkout limit. Choose a limit from your own traffic, then watch whether legitimate buyers are throttled.

CAPTCHA is narrower. When a CAPTCHA challenge is turned on, human users are allowed and crawlers and bots are blocked. That can fit a login page or a promotion page that is being scraped, after a real person can still pass. I do not start by challenging every catalog view. The docs do not describe a store-specific bypass for images or static theme files, so assume you must verify the shopper path after you enable the challenge.

Authentication challenge is stricter. Visitors need to enter the password, otherwise they are blocked. That fits a proxied application you intend to keep closed, such as a preview hostname added as its own application. It is a poor default for a public catalog, because a shared password gate is not how buyers expect to browse products.

Dynamic protection encrypts HTML and JS on each visit when it is turned on. I treat it as an optional layer and check catalog, cart, and account scripts afterward. Encrypting page code is not a substitute for fixing an injection bug in the application. The web access control list is named as a core capability, but these pages do not document a ready-made store policy, so I do not assume it already knows your office addresses or your payment vendor.

Prove a block before a campaign

The application guide includes test cases for SQL injection, XSS, path traversal, code injection, and XXE. Replace the example domain with your store domain and request them. If the blocking page appears, SafeLine stopped that test. Open the web console attack list and click detail to see the event. Prefer a staging hostname when you have one. Do not put live card numbers or account passwords into a test query. Nothing on these pages describes a special payment-field mode.

Keep the management console off the storefront. After installation, the console is at https://<safeline-ip>:9443/. The initial administrator account is created with docker exec safeline-mgt resetadmin. Keep that password out of the theme repository and out of tickets that your whole store team can read.

The introduction also publishes an effect evaluation on a fixed sample set. I do not treat that table as a measurement of your theme, your bots, or your checkout. It is not a false-positive promise for a particular storefront.

A first-week order that avoids guesswork

First, confirm placement: an application entry, SSL checked when the listener is HTTPS, DNS pointing at the SafeLine host, and one documented attack that produces both a blocking page and a detail record. Second, add rate limiting only where repetition is the abuse, using limits you derived rather than copied. Third, consider CAPTCHA only after a human can complete the challenged page. Leave authentication challenge off the public store. Turn on dynamic protection only after you have clicked through the pages your theme depends on.

A WAF in this role does not replace input validation, session handling, or the controls your payment provider already requires. It does give you a reverse proxy that filters malicious HTTP before the request reaches the origin, which is the protection these documents actually describe. If a control changes a legitimate purchase path, narrow it and retest login, search, cart, and checkout before the next campaign.

Does an online store need a cart plugin before this WAF can protect it?

No. The documented setup is a reverse proxy in front of the existing application. Add the domain, listener port, and upstream, then point DNS at the SafeLine server.

Should CAPTCHA be enabled on the entire catalog?

Not as a starting point. CAPTCHA is documented as a challenge that allows humans and blocks crawlers and bots. Enable it where bot traffic is the problem, then confirm a real shopper can still finish that page.

How is rate limiting different from attack blocking?

Attack blocking targets classes such as SQL injection, XSS, command injection, XXE, SSRF, and path traversal. Rate limiting throttles traffic that exceeds defined limits, including brute force, floods, and surges. A store can need both, for different requests.

What proves the store is actually behind the WAF?

The domain resolves to the SafeLine host, the application entry forwards to the real upstream, a published test payload returns the blocking page, and the console attack detail shows the event.

Is the published minimum server size enough for a sale?

The install guide minimum is 1 CPU core, 1 GB of memory, and 5 GB of disk. That is an installation floor, not a published sizing guide for peak storefront traffic. Measure your own peak before you treat it as capacity.

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)