Cloudflare Application Protection: What It Stops and What Your Code Must Still Do

01

Put a guard at the edge, not an excuse in the code

A public web application has to accept requests from people it has never seen before. Some are customers. Some are search engines and integration partners. Others are automated scans, password guessing, scraping or attempts to exploit a known weakness.

Putting Cloudflare in front of the application gives that traffic a checkpoint before it reaches the hosting environment. Depending on the plan and configuration, that checkpoint can absorb denial of service traffic, apply managed Web Application Firewall rules, challenge bots, enforce custom conditions and slow repeated requests.

That is valuable because every blocked request is one less request using the application server, database and queue workers. The mistake is treating the checkpoint as proof that everything behind it is secure. A guard at the front gate does not decide who can open every filing cabinet inside the building.

02

Follow one customer portal request

Imagine a customer portal with three important journeys. A customer can sign in, upload supporting documents and view the invoices linked to their account. An administrator can review the documents and approve a case.

Cloudflare can inspect the request before the portal receives it. A managed rule may recognise a common injection attempt. A rate limit may slow repeated login requests. A bot control may challenge traffic that behaves like automation. If the request passes those controls, it continues to the origin server and the application runs as normal.

The application then has a different set of questions. Is the session valid? Does this user own the requested invoice? Is the administrator allowed to approve this particular case? Is the uploaded file within the allowed size and type? Does the action need an audit record?

Those questions depend on the data and rules inside the portal. An edge service cannot infer them reliably from the URL alone. That division of responsibility is the thread running through the rest of the protection plan.

03

Make the origin difficult to bypass

The edge controls only help when requests actually travel through them. If somebody can discover the origin IP address and connect to it directly, they may be able to avoid the WAF, rate limits and bot checks completely.

Origin protection should therefore be part of the setup, not an optional tidy-up. The hosting firewall can restrict inbound web traffic to Cloudflare addresses. Authenticated Origin Pulls can require a valid client certificate when Cloudflare connects to the origin. Cloudflare Tunnel is another route because the server creates an outbound connection rather than exposing a public inbound listener.

The exact choice depends on the hosting platform, but the test is simple: a direct request to the origin should not return the application to an ordinary internet client. Check every hostname too. A forgotten staging record or old subdomain can quietly reveal the same server you protected on the main domain.

Keep encryption strict between Cloudflare and the origin as well as between the visitor and Cloudflare. An edge certificate does not justify sending the second half of the journey over an unprotected connection.

04

Use managed WAF rules as a starting point

A Web Application Firewall compares incoming requests with rules for suspicious patterns and known attack techniques. Cloudflare provides maintained managed rulesets, including its own rules and an OWASP ruleset, while custom rules let a team protect routes and behaviours that matter to a particular application.

Managed rules are useful because the application does not have to recognise every common exploit attempt itself. They are still a starting point. A generic rule cannot understand every framework, legacy route, file format or integration used by the portal.

Turn on protection carefully and review the security events. A rule that correctly blocks a strange public request might also interrupt a trusted webhook or an older form that sends data in an unusual shape. The answer is usually a narrow exception for the understood traffic, not switching off a whole ruleset because one request failed.

Custom rules should describe a real policy. An administration route may only need to accept traffic from an agreed network or users who have passed another access layer. A webhook may require a known hostname and then still verify its signature inside the application. Clear rules are easier to review than a pile of emergency blocks added after each alert.

05

Rate limit valuable actions, not the whole website

Not every abusive request looks malicious on its own. A login attempt, password reset or document search can be perfectly valid once and damaging when repeated thousands of times.

Rate limiting works best when it follows the value and cost of the action. The customer portal may need separate limits for sign-in, password resets, file uploads, report generation and an expensive API search. A blanket limit across the whole site can punish genuine users while leaving the most costly route with too much room.

Choose the counting characteristic carefully. An IP address is a useful signal, but offices, mobile networks and privacy services can place many genuine users behind one address. Authenticated account IDs, session cookies, API keys or a combination of signals may fit some routes better, depending on the Cloudflare plan and the information available at that point.

Rate limits are not an exact accounting system. Cloudflare notes that enforcement can take a short time to update, so some requests may still reach the origin after a threshold is crossed. Keep application-level limits and idempotency controls where duplicate actions could create money movement, repeated emails or multiple records.

06

Treat bots as behaviour, not one bad category

Automated traffic is not automatically hostile. Search crawlers, monitoring services, accessibility tools, payment callbacks and your own integrations may all behave like bots because software is making the request.

The useful goal is to separate expected automation from behaviour that creates risk or cost. Repeated failed logins, rapid account creation, aggressive scraping and large numbers of missing-page requests deserve different handling from a verified search crawler.

Start with visibility, then challenge or block the behaviour you understand. Keep a clear allow route for trusted services, but do not rely only on a friendly user agent string. Webhooks and system integrations should authenticate their requests with signatures, tokens, mutual TLS or another mechanism appropriate to the service.

A bot challenge also needs a customer check. If it regularly interrupts users on a corporate network or blocks a legitimate API client, the protection is moving the problem rather than solving it.

07

Keep permissions and validation inside the application

Once a request reaches the portal, the code remains responsible for the business boundary. Authentication proves who the user is. Authorisation decides what that user can do. The application should check permission on every protected request, including calls made by JavaScript or a mobile client.

In the invoice example, changing an invoice ID in the URL must not reveal another customer's record. That rule belongs beside the data and user relationship inside the application. A WAF may stop an obviously malformed request, but a perfectly ordinary invoice number is not an attack pattern.

Input validation belongs in the same layer. The portal should check required fields, expected formats, file size, file type and business rules before saving or processing information. Uploaded files may need isolated storage and malware scanning. Sensitive actions may need fresh authentication, multi-factor authentication or approval by a second person.

Security logs should record meaningful events such as failed sign-ins, permission failures, administrator actions and changes to important records. Avoid logging passwords, tokens or sensitive document contents. The aim is enough evidence to investigate an event without creating another unprotected copy of the data.

08

Watch the controls before trusting them

A security setting is not finished when the toggle changes. It needs an owner, a reason and a way to tell whether it is helping.

Cloudflare events can show which rule matched, what action was taken and which route was involved. Application logs show what happened after an allowed request reached the code. Hosting metrics show whether CPU, memory, database connections or queues were put under pressure. The useful picture comes from joining those views rather than expecting one dashboard to explain the whole incident.

Introduce new rules in a measured way where the feature allows it. Observe likely matches, test important customer and integration journeys, then move to challenge or block once the effect is understood. Record exceptions and review them later. A temporary bypass has a habit of becoming permanent when nobody owns the follow-up.

Alert on outcomes that matter. A sudden rise in blocked login attempts is useful. A fall in successful customer sign-ins after a rule change may be even more important.

09

Plan for provider failure as well as attack

Adding an edge provider creates a dependency as well as protection. A bad rule, certificate problem, DNS mistake or provider incident can make a healthy application unavailable.

Keep Cloudflare changes under the same discipline as application changes. Use named access, multi-factor authentication, limited permissions and an audit trail. Export or manage important configuration as code where the plan and tooling make that practical. Test certificate renewal alerts and make sure more than one appropriate person can respond.

A continuity plan should not be a loose instruction to expose the origin whenever Cloudflare has a problem. That can remove the protection exactly when the team is under pressure. Decide in advance which services could use a controlled alternative, what DNS and certificate changes would be required, and which risks the business would accept during that period.

The simplest applications may not need every Cloudflare security product. They still benefit from a clear boundary: protect the route to the server, apply proportionate edge controls, keep permissions in the code and monitor both sides.

10

Build several useful layers

Cloudflare is strongest when it reduces the amount of hostile and wasteful traffic the application has to handle. The application is strongest when it assumes an allowed request can still be wrong, unauthorised or dangerous in its business context.

For the customer portal, that means the origin cannot be reached directly, common attacks meet managed WAF rules, expensive routes have measured rate limits and unexpected automation is visible. Behind those controls, the code still checks every invoice relationship, validates every upload and records every important approval.

No single layer has to recognise every threat. Each layer needs a clear job, a tested failure mode and somebody responsible for it. That is a much calmer protection plan than trusting one shield and hoping the application behind it never makes a mistake.