Protection and speed
Every visit passes a web firewall and limits before it reaches your app. Turn on Under attack when you need it, and serve static files from a fast cache.
Updated 17 Oct 20263 min read
Every visit to your app reaches our door first, in your project's location. There it passes limits and a web firewall, and static files may be served from a cache, before anything reaches your app. You set it up on the app's page, in the Protection and speed card. There's nothing to install.
Limits on every visitor
| What | Limit |
|---|---|
| Requests from one visitor to one app | 50 a second, with bursts up to 300 |
| Login tries from one visitor to one app | 10 a minute |
| All requests to one app | 2,000 a second |
| One visitor while Under attack is on | 5 a second |
A visitor is an IPv4 address, or an IPv6 /64. Login tries are POSTs to login forms: WordPress's, Laravel's, /login, /admin, xmlrpc.php and the like. A visitor over a limit gets a 429 answer with Retry-After, on a plain page of ours.
An address shared by many people, like a mobile network's, is never banned as a whole: it gets a short check in the browser instead, so one attacker doesn't lock out a whole city's phones. Addresses caught attacking are banned at the door.
The web firewall
The web firewall reads each request for known attacks, like SQL injection or a script in a form field. For now it's watching: it records what it would block, and blocks nothing yet. Your app's logs show each one as "Web firewall would stop", with the rule's number. Once its false alarms are studied, we switch it to blocking, location by location, and the card says On.
If the firewall stops something legitimate, like a rich-text editor's HTML in a form:
Find the rule's number in the app's logs, six digits like 942100.
In Protection and speed, choose Relax a rule.
Type the Rule number and save.
Relaxing a rule is logged in the app's activity, and Restore puts it back. Only attack rules can be relaxed, up to 100 an app.
Under attack
Turn on Under attack while your app is being flooded. Every visitor then sees a short check in their browser first: a page with your site's address that says it's checking they're a person, for a few seconds. A visitor who passes goes through for 30 minutes, without being checked on every click, so carts, logins and forms keep working. Limits get stricter too.
Turning it on again checks every visitor again, even those who passed before. Webhooks and API calls aren't shown the check, since they can't pass it; they get the stricter limits instead. Turn it off once the attack is over.
Static files at the door
Pictures, styles, scripts, fonts, sound and video can be kept in memory at the door, so they reach visitors without your app doing any work. A file is kept only when it's safe to share:
a whole successful answer to a GET, with no login and no cookie set;
not marked
private,no-storeorno-cache;for as long as your app says with
max-ageors-maxage, or an hour when it says nothing, and never more than a day.
Each app has up to 64 MB, each file up to 8 MB. Every deploy and rollback clears it. To clear it by hand, choose Clear the cache.
Example: Asha's busy weekend
On a Saturday, duka's Requests jump and her logs fill with POSTs to /login from a few addresses. Each one is held at 10 tries a minute, so nobody can guess passwords fast, and the shop stays up. When thousands of addresses join in, she turns on Under attack. Real customers wait a few seconds once, then shop as usual. An hour later she turns it off.
Her product photos come from the cache at the door, so even during the rush her app spends its time on orders, not pictures. Her app says nothing about caching them, so each is kept for an hour; a file that sends Cache-Control: public, max-age=86400 would be kept for a day.
With Cloudflare
If your domain is on Cloudflare with its proxy on, our door knows Cloudflare's addresses and never bans them; the limits apply to your real visitors. See Connect Cloudflare.