API rate limiting & a managed WAF.
Automatic API rate limiting caps abuse per route, per IP and per account, and a managed WAF with 50k+ rules blocks SQL injection, XSS, SSRF and scanner bots. Tuned to be non-blocking: real users never hit a false alarm. Every request gets an auditable verdict, the rule, the payload, the reason. Installs in one line and always fails open.
- Auto API rate limits
- 50k+ managed rules
- No false alarms
- Always fails open
One managed firewall, watching every request.
The WAF runs inside your app and decides in about four milliseconds. You never touch a signature: the policy streams from Defenso and updates weekly, and it always fails open, so if we are ever unreachable your traffic flows untouched.
SQL injection, XSS, SSRF, command injection, path traversal and scanner bots, each rule tagged with its MITRE ATT&CK and OWASP ID so a verdict is never a black box. Updated weekly by us.
Your endpoints are discovered from real traffic and get per-route, per-IP rate limits. Login routes ship with brute-force caps out of the box, so credential stuffing and scraping stop at the door.
Confirmed attackers get coherent fakes and honeytokens instead of your real data. The loot is worthless, and the moment they touch the bait you get an early warning.
What the managed WAF blocks for you.
The attacks we stop in production, every day. Hover to pause and read.
SQL injection
User input concatenated straight into a query. We stop it before it reaches your database.
Cross-site scripting (XSS)
A script an attacker plants that would run on your users. Blocked at the edge.
SSRF
The server tricked into fetching internal URLs it should never touch.
Command injection
Shell commands smuggled through an input field. Caught by the managed rules.
Path traversal
Sneaky ../ paths reaching for files outside the web root.
SQL injection
User input concatenated straight into a query. We stop it before it reaches your database.
Cross-site scripting (XSS)
A script an attacker plants that would run on your users. Blocked at the edge.
SSRF
The server tricked into fetching internal URLs it should never touch.
Command injection
Shell commands smuggled through an input field. Caught by the managed rules.
Path traversal
Sneaky ../ paths reaching for files outside the web root.
Scanner & bad bots
Automated scanners and headless browsers fingerprinted by JA4 and behaviour.
Credential stuffing
Leaked-password login floods, stopped by per-account velocity limits.
Mass assignment
Extra fields slipped into a request to overwrite what they should not.
Brute force
Login and API hammering, capped per IP and per account out of the box.
NoSQL injection
Operator-injection payloads aimed at MongoDB and friends.
Scanner & bad bots
Automated scanners and headless browsers fingerprinted by JA4 and behaviour.
Credential stuffing
Leaked-password login floods, stopped by per-account velocity limits.
Mass assignment
Extra fields slipped into a request to overwrite what they should not.
Brute force
Login and API hammering, capped per IP and per account out of the box.
NoSQL injection
Operator-injection payloads aimed at MongoDB and friends.
Active deception, built into the firewall.
Blocking tells an attacker their probe was caught and invites a quieter payload. Active deception answers the same confirmed threat with a coherent, worthless world: it defangs the attack by serving fake .env files, decoy admin panels and honeytokens instead of your real data. The honeypot runs inside the request path the WAF already inspects, with nothing extra to deploy, and the moment they touch the bait you get the earliest possible warning.
Deception never fires on normal traffic. It engages only after a request has already earned a hostile verdict from the managed WAF: exploit payloads, path-traversal probes, scanner fingerprints, credential-stuffing bursts. Verified crawlers like Googlebot and Bingbot are on a permanent allowlist and are never shown bait, so your SEO and real users are untouched.
Probes for .env, .git, backup archives or admin panels return plausible files and pages instead of a status code. The fakes are internally consistent, so an attacker keeps pulling the thread into a sandbox while your real data stays out of reach. That is deception woven into the live request path, not a honeypot appliance sitting off to the side.
Every fake credential, API key and connection string is a honeytoken that works nowhere. The second one is used anywhere on the internet, you get an alert carrying the attacker fingerprint. Because only an attacker ever touches the bait, the signal has essentially no false positives, the earliest and cleanest breach detection you can run.
A firewall you never have to babysit.
Most firewalls hand you a rule engine and a manual. Ours ships 50k+ managed rules, runs inside your app, decides in about four milliseconds, and keeps its own policy current, so you spend zero time tuning signatures. It is tuned to be non-blocking: real users and legitimate API traffic never trip a false alarm.
The moment a request arrives, it is checked against a policy of 50,000+ MITRE ATT&CK and OWASP tagged rules that we update every week, including fresh rules for the attack patterns hitting apps right now. If it is hostile, it is stopped before it reaches your code, and the verdict is logged with the exact rule and payload so nothing is a black box. If it is clean, it passes through with a few milliseconds added.
The hard part of any WAF is not blocking attacks, it is not blocking your customers. Ours is designed against false positives: rules are scored and gated so a legitimate request is never dropped on a hunch, and the API rate limiting caps abuse per route, per IP and per account without throttling normal use. You get protection that stays quiet until it matters.
Because the policy lives with us, you are never the last site running a stale ruleset. New attack patterns are added centrally and take effect on your site the same day, with no deploy on your side. And it is fail-open by design: if our service is ever unreachable, every request is allowed through and your app keeps serving. Confirmed attackers do not just get blocked, they get actively deceived: coherent fake files and honeytokens instead of your real data, so a breach is worthless and you get the earliest possible warning.
Block the attack, or make it worthless.
Blocking and deception are not rivals. Defenso does both in one request path: hostile traffic is blocked where a block is enough, and deceived where you want the attacker to waste hours and hand you a fingerprint. Here is how active deception built into the app compares to blocking alone and to a traditional standalone honeypot appliance.
| Capability | Block-only WAF | Standalone honeypot | Defenso active deception |
|---|---|---|---|
| Stops the exploit outright | ✓ | × | ✓ |
| Attacker learns their probe was caught | Yes | No | No |
| Serves coherent fake files and decoy panels | × | Partial | ✓ |
| Honeytokens that alert when reused | × | ✓ | ✓ |
| Watermarked exfil you can trace later | × | × | ✓ |
| Fires only on confirmed attackers | n/a | × | ✓ |
| Verified crawlers never shown bait | n/a | × | ✓ |
| Runs inside your app, nothing to deploy | ✓ | × | ✓ |
| Included on every plan, Free too | Varies | × | ✓ |
Automatic API rate limiting.
The firewall does more than block payloads. It discovers your API endpoints from real traffic and caps abuse per route, per IP and per account, with no rules for you to write.
Endpoints found for you
Your routes are learned from real traffic, so you never maintain a list. New endpoints are picked up automatically and the ones that need protecting are flagged.
Per-route, per-IP, per-account
Limits apply where they matter: a login route, a search API, a write endpoint. Bursts from one IP or one account are throttled without touching your legitimate users.
Brute-force caps out of the box
Login and token routes ship with credential-stuffing and brute-force caps on day one, so password spraying and scraping stop at the door before you configure anything.
A managed WAF vs. a CDN or edge firewall.
A CDN like Cloudflare protects the edge in front of your app. Defenso protects the app itself, and adds the security work a CDN was never meant to do. Most teams run both.
| CDN / edge firewall | Defenso managed WAF | |
|---|---|---|
| Blocks SQLi, XSS, SSRF | ✓ | ✓ |
| Auditable rule + payload per request | sometimes | ✓ |
| Auto-detects your APIs & rate-limits them | × | ✓ |
| Active deception & honeytokens | × | ✓ |
| Website & repo security scans | × | ✓ |
| Pentest & compliance in the same account | × | ✓ |
| Works alongside your existing CDN | — | ✓ |
Frequently asked questions.
Everything people ask before they start. Still unsure? We are one message away.
No. The managed WAF ships with a policy of MITRE and OWASP tagged rules that we update weekly. It works out of the box, and you can add your own custom rules on Pro and above if you want to.
It should not. Verified crawlers like Google and Bing are allowlisted, and rules are tuned against real traffic. When a request is blocked you can see exactly which rule fired and the payload, so any false positive is easy to spot and adjust.
About four milliseconds per request. The check runs inside your app and returns a verdict fast, and safe GET responses can be cached at the edge to claw that back.
Nothing breaks. The WAF is fail-open by design: if our service is unreachable, every request is allowed through and your app keeps serving normally. Your app keeps serving the whole time; only our live policy updates pause until we are back.
No, it complements it. A CDN protects the edge; the managed WAF protects the app behind it and adds scans, pentest, deception and compliance. Most customers run both, and we keep our checker IPs off your CDN firewall so a rule never fakes a downtime alert.
Add one line of code with the SDK, or one click with the WordPress plugin. The managed firewall, rate limits and deception switch on together, with no config file to maintain.
Active deception answers a confirmed attacker with a coherent fake environment instead of an error: plausible fake files, decoy admin panels and honeytokens, so the attacker wastes time on worthless data while you get an early-warning breach alert. Unlike a traditional standalone honeypot you rack and monitor off to the side, Defenso deception runs inside your real app on the request path the WAF already inspects, so it engages the actual attacker hitting your live site, with nothing extra to deploy. It is included on every plan, Free too.
No. Deception only engages once a request has earned a hostile verdict from the WAF. Normal visitors and verified crawlers such as Googlebot and Bingbot are on a permanent allowlist and are never shown bait, so your users and search ranking are never affected. Honeytokens work nowhere, so no legitimate person ever touches them, which is why the alert has essentially no false positives.
Turn on the firewall in one line.
Free to start, no card needed. Add one line and the managed WAF, rate limits and deception begin blocking in production.