Website and application defense baseline

Protect public pages, forms, login, APIs, and administration in layers, then tune rules from real traffic.

SECURITYINTERMEDIATE35 minutesOutcome: a defense matrix by entry point

Application defense is not limited to AI endpoints. A home page can receive DDoS traffic, forms attract spam, login attracts credential stuffing, APIs invite bulk scraping, and administration attracts scanning. Cloudflare network and application security must work with application authentication, authorization, input validation, and auditing.

Edge rules do not replace application authorization

WAF, Bot, and Rate Limiting reduce malicious traffic, but a Worker still verifies identity, role, tenant, and object ownership. Passing a challenge does not grant access to a record.

Five-entry matrix

Entry	Main risk	Cloudflare layer	Application layer
Public page	DDoS, malicious paths, resource exhaustion	Proxy, DDoS, WAF, cache	Security headers and stable 404
Form	Spam and automated registration	Turnstile and Rate Limiting	Server token validation, idempotency, field bounds
Login	Credential stuffing, enumeration, replay	WAF/Bot, challenge, Rate Limiting	Generic errors, session protection, audit
API	Brute calls, scraping, broken authorization	Per-path limits, WAF, API capabilities	Token, scope, tenant, and resource checks
Administration	Scanning, weak credentials, exposed origin	Access, Tunnel, WAF	Minimal role, reauthentication, action log

Defense sequence

Ensure traffic actually passes through Cloudflare

Hostnames that depend on WAF, Bot, and most edge controls must be on the proxied path. Confirm that no public origin address bypasses the policy. With Tunnel, an administrative service does not need a directly exposed inbound port.

Observe the normal baseline

Use Security Analytics and application logs to study normal rates, paths, methods, country/ASN distribution, and error states. Derive rate thresholds from real distributions and attack samples, not an arbitrary number copied from a tutorial.

Log or challenge before blocking

Scope new rules to specific paths and methods. Observe false positives, then move from logging or Managed Challenge to stronger actions. Avoid one rule that covers assets, search engines, and login together.

Validate forms twice

The Turnstile widget only produces a token. The server calls Siteverify, checks the response, and rejects duplicate, expired, or invalid tokens. The secret remains in a server-side binding.

Continue authorization inside the application

Every write and private read checks user, tenant, role, and object relationship. Database queries bind a tenant predicate, and a cross-tenant fixture proves that access is denied.

Correct rate limiting

Login, password reset, export, image/PDF conversion, and expensive search need different contexts. Common plans often count by IP, but NAT, mobile networks, and distributed attackers affect false positives and bypass. Advanced fields and counting characteristics depend on plan. A few excess requests may pass before distributed counters update, so a rate limit is not an exact billing meter or business quota.

Network abuse

WAF, DDoS, and Bot reduce obviously malicious requests first.

Human verification

Turnstile protects important interactions but requires server validation.

Business quota

Plan and user quotas live in trusted application data, not only an IP limit.

Administrative access

Access/Tunnel narrows entry while application roles still constrain operations.

Verification and rollback

Use a test path or controlled IP to verify challenges. Do not experiment with an immediate block for every production visitor. Record rule ID, target expression, expected match, false-positive signal, and rollback owner. If legitimate-user failures increase, disable the latest rule first and inspect events before changing several layers at once.

Next: run the production release checklist.