Improving bot protection does not have to mean replacing your CDN.
Many businesses are tied to an existing CDN through contracts, cloud architecture, caching rules or applications that are difficult to move. Meanwhile, problems such as residential proxies, credential stuffing, scraping, API abuse and Layer 7 DDoS attacks still need to be dealt with.
Peakhour supports both approaches:
Visitor → existing CDN → Peakhour → origin
or:
Visitor → Peakhour Edge → origin
The important part is not which diagram you use. It is making sure you can identify suspicious traffic, make a decision and act on it before that traffic reaches the application.
Decide Where You Trust the Data
When a website sits behind a CDN, the origin server sees a connection from the CDN, not directly from the visitor. This can affect the IP address, location, browser fingerprint and rate-limit data available to the application.
For each signal used in a security rule, you need to know where it was captured and whether it can be trusted. Any forwarding or fingerprint headers supplied by the visitor should be removed at the trusted edge and replaced with verified values.
This matters because a rate limit based on a spoofable IP address is easy to bypass. A browser fingerprint calculated at the origin may identify the CDN rather than the visitor. Security decisions are only as reliable as the data behind them.
Make the Decision Before the Damage Is Done
Security information is most useful when you can act on it while the request is still in progress.
Peakhour can combine signals such as:
- IP and network information
- residential proxy detection
- browser and network fingerprints
- credentials
- request behaviour
- bot detection
- rate limits
- WAF findings
The result can be used to allow, log, challenge, rate limit or block the request.
Your existing CDN can continue handling caching and content delivery. Peakhour can add another decision point for the traffic that needs closer inspection.
Timing matters. Detecting that a request was malicious after the application has already queried a database, processed a login or generated an expensive response may help with an investigation, but it did not protect the application from that request.
Start With One Problem
You do not need to migrate every security rule at once.
Start with one route that is causing problems, such as:
- login
- account creation
- search
- a heavily scraped page
- an expensive API operation
Run the new controls in monitoring mode first and compare the results with what your CDN and application are already seeing.
Once you are comfortable with the results, apply a reversible action such as a rate limit or browser challenge. Expand from there once you understand the effect on legitimate customers.
Avoid running the same controls independently in multiple places. If both your CDN and Peakhour decide to challenge the same visitor, for example, the customer could end up being challenged twice.
Each security action should have a clear owner.
Protect More Than the Login Page
Bots and proxies do not only affect authentication.
Scrapers and Layer 7 attacks can consume CDN capacity, application resources, database capacity and origin bandwidth. Some automated requests are also much more expensive to process than others.
This is why it helps to connect the security decision with what happened afterwards.
Useful information can include:
- whether the request was served from cache or reached the origin
- which page or API route was requested
- whether a proxy or bot was detected
- browser and network fingerprints
- rate-limit status
- the action taken
- the response status
- origin health
The goal is not simply to block as much traffic as possible.
For example, allowing harmless automated requests to be served from cache while rate limiting expensive requests that reach the application may protect the site better than blocking every suspected bot.
Keep the Trust Model Clear
Adding another security layer does not need to make the architecture complicated.
You need to know:
- where information about the visitor is captured
- which systems are trusted to provide it
- where the security decision is made
- which system takes the action
An existing CDN does not prevent you from improving bot and proxy protection. The CDN can continue doing the job it already does while another security layer handles the traffic that needs additional scrutiny.
Move the delivery layer when there is a good operational reason to do so, not because improving one security capability requires an all-or-nothing migration.
