Peakhour.IO - Rate Limiting

An Operating Model for API and Account Protection

2026-06-19T00:00:00+10:00

API and account protection is often discussed as a stack of controls: authentication, MFA, bot detection, rate limiting, WAF rules, logging, fraud checks, and incident response. Those controls matter, but the missing piece is usually the operating model.

Who owns the route? Which signals are trusted? What action should happen before origin? What evidence is preserved? When does a rule move from monitor to enforce? How does the team know whether it helped or hurt?

Without those answers, account protection becomes a set of disconnected gates. The login page has one policy. The mobile API has another. Password reset is reviewed only after support tickets appear. Rate limits are tuned during incidents, then left in place because nobody wants to touch them.

A better model is route first, signal second, action third, evidence always.

1. Map the Routes That Matter

Start with the account and API routes that change trust, money, access, or user state. Do not begin with every endpoint in the estate. Begin with the flows where abuse has a clear consequence.

Typical routes include:

Login and token issue.
Token refresh.
Password reset start and completion.
MFA enrolment and recovery.
New account registration.
Email, phone, address, and password changes.
Stored payment, wallet, loyalty, or checkout actions.
High-volume read APIs.
Partner or machine-to-machine API access.

For each route, record the owner, normal traffic shape, expected clients, authentication method, downstream cost, and likely abuse case. A login endpoint and a product search endpoint can both be APIs, but they should not have the same policy.

This is where traffic control becomes part of account security. The route tells the edge what kind of decision is being made: allow, challenge, throttle, block, route, cache, or log.

2. Classify the Signals Before Choosing the Action

A useful account decision combines several signal families:

Identity and token state.
Credential exposure or failed-login history.
Residential proxy, VPN, hosting, mobile, or office network context.
IP reputation and ASN behaviour.
Client, browser, TLS, or HTTP fingerprint.
Request rate and response codes.
Route sequence and session behaviour.
Account event context, such as reset, recovery, or profile change.

The mistake is treating any one signal as the whole answer. A residential proxy signal on a low-risk route may only need monitoring. The same signal on a password reset route, with repeated failures and a first-seen client, should be handled differently.

This is the job of contextual security: apply friction where the request context justifies it, while keeping trusted users on the shortest path.

3. Choose Actions That Match Route Risk

Not every suspicious request should be blocked. Blocking is one action, and it should be available, but account protection needs a wider set of responses.

Common actions include:

Allow and record.
Log only.
Add to a rate-limit zone.
Throttle or return a 429.
Require a challenge.
Require step-up authentication.
Deny the request.
Route to a safer path.
Alert security or support.

Advanced rate limiting is useful here because the counter does not have to be the source IP. For API traffic, a policy may key on an Authorization header, token, fingerprint, route, cookie, response code, or a combination of fields. For account flows, response-aware limits can count failed logins or suspicious reset attempts, then apply a stricter rule on the next request.

This matters for distributed abuse. If attackers rotate through residential proxies, a simple IP counter sees fragments. A route-aware, signal-aware policy can still recognise the behaviour that matters.

4. Preserve Evidence While the Control Runs

A security decision that cannot be explained will be difficult to tune and harder to defend internally. Teams need to know why a request was allowed, challenged, throttled, or blocked.

The evidence should keep the request, route, signal, policy, action, and outcome together. That includes useful fields such as the matched route, rate-limit zone, proxy or IP classification, fingerprint, response code, decision reason, and timestamp.

Log forwarding is part of the operating model, not an afterthought. If the evidence only exists in a dashboard screenshot or a short-lived edge event, support, fraud, platform, and security teams will end up reconstructing incidents by hand. Forwarded logs should carry enough context into the SIEM, object store, or observability pipeline for investigation and tuning.

This also protects the rollout. When a control is in monitor mode, evidence shows who would have been affected. When it is enforced, evidence shows who was affected and why.

5. Tune From Monitor to Enforce

The safest way to deploy account and API controls is usually staged:

Monitor the route and collect baseline evidence.
Add low-friction actions, such as logging or soft thresholds.
Review false positives, support impact, and route ownership.
Enforce on the clearest abuse patterns.
Expand enforcement only where evidence supports it.
Keep rollback and emergency tightening paths documented.

This avoids two common failures. The first is leaving controls in monitor mode forever because nobody owns the decision to enforce. The second is enforcing too broadly and creating customer friction that causes the business to bypass the control.

A staged model gives security, platform, product, and support teams a shared language. The rule is not "on" or "off". It has a route, a risk case, an action, evidence, and a review cycle.

6. Fit the Model to the Edge You Already Run

Some teams want Peakhour as the active application edge. Others need to keep Cloudflare, Fastly, CloudFront, another CDN, or an existing hosting edge in place. That deployment choice should not change the operating principle.

The goal is still to classify request context before origin, apply the right action, and preserve evidence. Bring Your Own Edge matters because many organisations cannot redesign delivery just to improve account protection. They need a control path that fits the architecture they already operate.

The practical test is straightforward: can the team explain what happened to a sensitive account or API request without guessing?

If the answer is no, the next step is not another generic control. It is an operating model: map the route, classify the signals, choose the action, preserve the evidence, and tune the policy from observed behaviour.

That is how API and account protection becomes something the organisation can run, not just something it bought.

API Bot Abuse Does Not Stay in One Endpoint

2026-06-19T00:00:00+10:00

API bot abuse rarely stays politely inside one endpoint.

A campaign may start at login, move through token refresh, test account recovery, check saved addresses, probe checkout, abuse coupons, scrape product availability, and then return to account actions once a working session is found. Looking at each route alone makes the activity seem smaller than it is.

The pattern matters more than the individual request.

That is why API bot protection has to follow journeys, not just endpoints.

Login Is the First Measurement Point

Login endpoints are the obvious place to look for bot abuse. Credential stuffing, password spraying, brute force attempts, and token abuse all show up there.

But the login endpoint is only the first measurement point. Attackers are not trying to create a failed-login graph. They are trying to find usable accounts and move to the next action.

A bot campaign may keep failed attempts low per IP address. It may rotate through residential proxies. It may slow down to avoid simple thresholds. It may mimic the browser request shape closely enough to get past a basic check. It may use an API route that exists for the mobile app rather than the public login form.

So the useful question is not just "how many login attempts did we see?" It is "which client, route, network, fingerprint, account, and response pattern suggests automation?"

That is where bot management belongs in the account journey. It should not be an isolated "human or bot" label. It should become part of the request evidence used for login, recovery, checkout, and account-change decisions.

Checkout Abuse Is Often API Abuse

Checkout abuse is not always a stolen-card problem. It can be a request-path problem.

Bots can test coupon codes, reserve inventory, create carts, check delivery combinations, retry payment flows, and exploit business logic at machine speed. Some of this happens through visible browser journeys. Much of it happens through APIs used by the front end or mobile app.

The damage is not always dramatic in a single request. A few extra cart creations may look normal. A small number of coupon checks may be expected. A payment retry can be legitimate. The problem is the campaign shape across routes.

If the same automation profile moves through login, cart, promo, shipping, and payment APIs with abnormal timing or sequencing, the response should not depend on one endpoint crossing a crude global limit.

It should be route-aware.

A checkout API can tolerate different behaviour from a catalogue API. A payment route deserves different thresholds from a product search route. A coupon route may need controls around account age, session state, rate, and client evidence. A cart route may be harmless in one context and abusive in another.

Account Journeys Need Sensitive-Action Controls

Account abuse becomes most damaging when a session moves into sensitive actions.

Changing an email address, resetting a password, adding a new delivery address, viewing stored payment details, redeeming loyalty value, or placing an order are different from normal browsing. They deserve stronger context.

The request may be technically valid. The token may pass validation. The password may be correct. The API schema may be satisfied. That does not mean the action is safe.

A strong control model looks at the full path into that action. Did the session begin with credential stuffing signals? Is the client first seen? Did the network change? Is there proxy or fingerprint drift? Has the account recently failed login attempts? Is the request cadence consistent with a human journey? Is the action unusually soon after authentication?

These are not abstract "zero trust" slogans. They are practical checks on the account request path.

Rate Limits Need Better Keys

API abuse prevention often starts with rate limiting, but IP-only limits struggle with distributed automation and shared networks. The hard part is deciding what to count.

For API bot abuse, useful rate keys can include route, method, account, token, API key, response code, ASN, country, TLS or HTTP fingerprint, verified bot state, and combinations of headers. The right key depends on the journey.

A login endpoint might count failed attempts by account and fingerprint. A token endpoint might count refresh patterns by client and session. A checkout route might count attempts by account, payment state, and client fingerprint. A partner API might count by API key and route.

Advanced rate limiting is valuable because it can model the abusive actor more precisely than a single IP address. It also gives teams response options short of blanket blocking: log, challenge, throttle, or deny depending on the route and risk.

That matters because real API traffic includes customers, mobile apps, partners, service clients, good bots, bad bots, and increasingly AI-driven agents.

Agents Will Make the Journey Problem Harder

The next wave of automated API use will not all look like simple scripts. As discussed in Agentic AI vs. Your API, reasoning agents can explore, adapt, and change their behaviour based on responses.

That does not mean every AI agent is malicious. It does mean endpoint-by-endpoint rules will age quickly.

A reasoning agent can try one path, observe the result, and adjust. It can move from documentation to browser-backed APIs to mobile-shaped requests. It can test which routes are protected, which errors reveal state, and which actions trigger stronger checks.

Defence needs the same journey view. The campaign should be visible as it moves, even when the exact request pattern changes.

Keep Evidence Attached to the Campaign

API bot abuse is easier to manage when the evidence stays attached.

The useful record is not just "blocked by rule 42". It is the route, account state, token or key context, fingerprint, proxy signal, rate key, response pattern, action taken, and protected business step. That evidence lets teams tune controls without guessing and investigate incidents without reconstructing the whole path from raw logs.

For broader background, API abuse prevention covers the categories. The operational point is narrower: login, checkout, and account APIs should not be defended as separate islands.

Attackers use the journey.

The defence should too.

API Protection and Account Protection Are One Request-Path Problem

2026-06-19T00:00:00+10:00

Account protection is often discussed as if it belongs to the login page. That made sense when most account abuse looked like someone submitting a username and password into a web form.

That is not how modern account journeys work.

A customer signs in through a browser, a mobile app, a partner integration, a password reset flow, a token refresh endpoint, a profile update request, a checkout API, and sometimes a service-to-service call that exists nowhere in the visible front end. The account is not protected by one screen. It is protected, or exposed, by the whole request path.

That is why API security and account protection should not be treated as separate operating problems. The API route, the identity context, the client evidence, the rate pattern, the token behaviour, the bot signal, and the account action all arrive together. Splitting those signals across disconnected tools makes the final decision weaker.

The Login Is Only the Start

Credential stuffing is the obvious example. Attackers test leaked credentials against login endpoints, but the useful outcome is rarely the login itself. The value comes after the session opens.

They try to change the email address. They add a shipping address. They reset a password. They check stored cards. They redeem loyalty value. They place an order. They call account APIs that were built for the real customer journey and then abuse them in a different sequence.

If the login defence is separate from the API defence, the organisation may see only fragments:

A spike in failed logins in one dashboard.
A suspicious token refresh pattern somewhere else.
A burst of profile-change requests in application logs.
A fraud case after checkout.

Each of those is useful. None is the full story.

The better model is to keep the decision close to the request. A request to /login is different from a request to /account/email, /checkout/payment, or /api/token/refresh. The route matters. So does the method, the session state, the previous failures, the network, the client evidence, and the account action being attempted.

APIs Carry Account Risk

APIs are not just developer plumbing. They are where many account journeys now happen.

Mobile apps use APIs for login, registration, password reset, saved addresses, payment methods, and checkout. Single-page applications call APIs behind browser journeys. Partner systems may call account or order APIs directly. Internal services may use API keys or service credentials that function like non-human accounts.

That creates a practical issue: account protection must cover both human and non-human identity paths.

OAuth, JWTs, API keys, refresh tokens, and service credentials all need lifecycle control, least-privilege access, rotation, validation, and monitoring. But those controls are still not enough if the protected API cannot see whether the request is behaving like abuse.

A valid token can be stolen. A valid API key can be overused. A real session can be driven by automation. A known customer can suddenly perform a high-risk action from a first-seen client through proxy infrastructure.

The request has to be judged in context.

Rate Limiting Has to Follow Business Logic

Basic rate limiting often starts with an IP address. That is an understandable first step, but it is not enough for account protection. Attackers rotate through proxy networks. Legitimate users may share a carrier or office IP. Some attacks are low and slow enough that no single IP looks exceptional.

For account journeys, rate limiting needs to be tied to the thing being protected.

Login attempts can be counted differently from password resets. Token refreshes can be counted differently from product searches. A failed authentication response can be treated differently from a normal read request. A route hit by a first-seen client can be treated differently from one used by a known browser session.

That is the point of API protection as an operating layer, not just an API inventory exercise. The route, schema, authentication state, bot signal, and rate key should be available to the same decision. Otherwise teams end up writing compensating rules in several systems and hoping the gaps line up.

The Edge Decision Needs Options

Not every suspicious request should be blocked. Some should be logged. Some should be rate limited. Some should be challenged. Some should be allowed because the business impact of a false positive is worse than the risk presented by that specific request.

Account protection is strongest when the action matches the journey.

A login request with weak risk signals might be allowed but watched. A password reset request with stronger signals might require step-up. A checkout attempt from a newly compromised session might be blocked or reviewed. A partner API key exceeding expected usage might be throttled without affecting normal customers.

Peakhour's position here is simple: API, bot, WAF, rate, and account controls work better when they share request evidence. That can run on Peakhour Edge, or it can sit beside the CDN and cloud edge already in place through bring your own edge. The important part is not the label on the component. It is whether the request path has enough context to make the right decision.

Account Protection Is a Journey Control

A useful account protection programme should be able to answer operational questions.

Which routes are involved in account takeover attempts?
Which sessions moved from suspicious login behaviour into account changes?
Which tokens or API keys are behaving outside their expected pattern?
Which controls created friction, and where?
Which blocked requests actually protected account, checkout, or recovery actions?

Those questions cannot be answered from a login form alone. They require API visibility, account-event context, rate data, bot signals, and reviewable evidence.

That is the thesis of this series: API protection and account protection are one request-path problem. The account is compromised through a sequence of requests. The defence needs to see that sequence early enough to act.

For teams already working on account takeover prevention, the next step is not simply adding another login prompt. It is connecting the account journey to the API routes that now carry it.

How Residential Proxies Changed API and Account Abuse

2026-06-19T00:00:00+10:00

Residential proxies have changed the shape of API and account abuse. The old picture was easier to reason about: too many failed logins from one IP, a known hosting provider range, an obvious bot user agent, or a burst that crossed a threshold quickly enough to trip a rule.

That still happens, but it is not the harder problem.

The harder problem is the attempt that arrives through ordinary consumer networks, spreads itself across many addresses, and behaves just slowly enough to avoid looking like an incident. One login attempt here. A password reset probe there. A token refresh pattern that is unusual only when it is seen beside the route, the client, the ASN, the credential history, and the account event.

That is why residential proxy detection should be treated as part of the account and API decision path, not as a standalone allow/block list.

The Account Workflow Is Now a Distributed Target

Attackers do not need to break the whole application at once. They can work through the account surface in pieces:

Login attempts against known usernames.
Password reset initiation and verification.
New account registration.
Token issue and refresh routes.
Payment, address, profile, and email changes.
Loyalty, wallet, checkout, or stored-value workflows.
API calls that reveal whether an account or credential is valid.

Each route may look acceptable in isolation. The risk appears when the pattern is joined together.

A residential proxy network helps the attacker keep that pattern quiet. Requests rotate through many residential-looking exits. IP-based rate limits see different sources. A reputation feed may not have labelled a fresh or private proxy network yet. Geo checks can look plausible enough. The traffic does not necessarily arrive as a clean burst.

This is where static thinking breaks down. If the only question is "is this IP bad?", the answer will often arrive too late or be too blunt to use safely.

Fresh and Private Proxy Networks Create a Timing Problem

Many teams think about proxy detection as a database problem: look up the IP, see whether it is a proxy, then block it. That works for some traffic, especially known data centre proxies and commodity infrastructure.

Residential proxy abuse is less tidy. Fresh networks can appear before public datasets have a confident label. Private networks may not show up in broad feeds at all. Some exit points are shared with legitimate users. Some sit behind carrier-grade NAT or normal household connections. Blocking the address outright can create customer pain, while allowing it without context leaves the account flow exposed.

This is the practical reason Peakhour talks about residential proxy use as a signal. The signal matters, but it has to sit beside IP intelligence, connection characteristics, client history, request behaviour, account state, and route sensitivity.

A residential proxy on a marketing page may only need logging. The same proxy signal on a login route with recent failures may justify a challenge. On a password reset or high-value account change, it may justify step-up authentication, throttling, or blocking depending on the rest of the evidence.

The control should match the risk of the action.

Low-and-Slow Behaviour Is Still Automation

Low-and-slow abuse is uncomfortable because it avoids the easy operational story. There is no dramatic spike. There may be no single IP worth banning. The application may not be overloaded. Support may only see a few confused users, a few locked accounts, or a gradual rise in reset attempts.

For API and account workflows, this is still automation. It just looks less like a flood and more like a background process.

Useful signals include:

Repeated failed authentication across a shared fingerprint or client pattern.
Many accounts touched by similar request timing.
Token or reset routes used out of sequence.
Browser characteristics that do not match the claimed client.
Residential proxy use on sensitive account routes.
Fresh IP or ASN patterns appearing around account events.
Similar request shapes distributed across unrelated accounts.

None of these signals has to prove abuse by itself. The point is to combine them early enough that the application does not have to make the decision alone.

Peakhour's view is that proxy detection belongs in the same operating model as bot management, rate limiting, account risk scoring, and event evidence. The useful question is not "can we block every residential proxy?" It is "what should this route do when proxy use appears with this account, this client, this credential pattern, and this recent behaviour?"

API Routes Need the Same Treatment as Browser Flows

A common gap is protecting the visible login page while leaving API routes with weaker controls. Browser-side checks can help on web flows, but many account actions now happen through mobile apps, single-page applications, partner integrations, and backend APIs.

Those routes still need context. They need request-level validation, route-aware thresholds, proxy and IP signals, token checks, and evidence that can be reviewed later. A login API, a reset API, and a profile-change API should not all receive the same action just because the source address has the same reputation.

This is also why rate limiting has to move beyond source IP. A rule can key on a token, header, fingerprint, account identifier, route, response code, or a combination of signals. That makes it possible to slow failed login behaviour without punishing every legitimate user behind the same network.

The background reading on proxy detection challenges and quantifying residential proxy risk covers the broader detection problem. For API and account teams, the immediate step is more operational: find the routes where a residential proxy signal should change the action.

The Right Outcome Is Controlled Friction

Residential proxy detection is not a magic verdict. It is a way to make the account decision more honest.

Some traffic should pass. Some should be logged. Some should be rate limited. Some should be challenged. Some should be blocked. The difference should come from route sensitivity, request context, and observed behaviour, not from a single IP label.

A practical policy might look like this:

Monitor proxy use across all account and API routes.
Apply tighter thresholds on login, reset, token, and account-change routes.
Combine proxy use with credential, client, rate, and behaviour signals.
Preserve decision records so security and support can explain what happened.
Move from monitor to enforce only after reviewing false positives and customer impact.

That model gives teams a way to respond to residential proxy abuse without turning every shared residential network into a casualty.

For a grounding definition, see What is Residential Proxy Detection?. For the product control, see Residential Proxy Detection.

The important shift is simple: residential proxies are not just a network category. In account and API protection, they are context for deciding how much trust a request deserves.

Beyond the IP Address

2025-09-01T00:00:00+10:00

For years, rate limiting has been a standard control for protecting websites and APIs from abuse. The basic model is simple: limit the number of requests a single "user" can make in a given period. If a user exceeds the limit (e.g., 10 login attempts in a minute), they are temporarily blocked.

The hard part has always been identifying that "user". Traditionally, the answer was the IP address. The assumption was that one IP address equaled one user. In the early days of the internet, this was a reasonable approximation. Today, that assumption no longer holds, and it leaves systems exposed to modern attacks.

The IP address is no longer a reliable identifier for a single user or device. There are three common reasons:

Proxy Networks: Attackers don't use a single IP address. They use large residential proxy networks to rotate requests through thousands or even millions of different IP addresses, making each request look like it comes from a new user.
Shared IPs (CGNAT): At the same time, a single IP address can represent thousands of legitimate users. Mobile carriers use Carrier-Grade NAT (CGNAT) to make many mobile devices share the same public IP. Similarly, an entire office building or university campus might appear to the internet as a single IP.
Distributed Attacks: Modern automated attacks, like Layer 7 DDoS or credential stuffing, are inherently distributed. Attackers use botnets or proxy networks to spread their attack across a large number of IPs, so no single IP ever exceeds a traditional rate limit.

Blocking a shared IP because of one bad actor can cause collateral damage, denying access to thousands of legitimate users. On the other side, failing to see that thousands of IPs are part of a single coordinated attack means the attack succeeds. Traditional IP-based rate limiting is no longer enough.

The New Way: Advanced Rate Limiting

Advanced Rate Limiting addresses this by moving beyond the IP address. Instead of grouping requests by a single, unreliable identifier, it lets you count requests using more stable and meaningful characteristics of the connection or the software making it.

This approach groups requests using identifiers like:

TLS/HTTP2 Fingerprints: Every client application (like a browser or a script) has a unique "fingerprint" based on how it initiates a secure connection (TLS) or communicates over HTTP/2. This fingerprint remains consistent even as an attacker rotates through thousands of IP addresses. By rate limiting based on the TLS fingerprint, you can track and block the underlying automation tool itself, not just the IPs it uses.
Device Characteristics: A fingerprint can be constructed from a range of attributes, including the device's operating system, browser version, and more. This allows for the detection of repeated requests coming from the same class of device.
A Combination of Headers: For authenticated APIs, you can group requests by an Authorization header or API key, enforcing fair usage and preventing abuse by a single authenticated client.

Practical Use Cases

The value of advanced rate limiting is clearest when it is applied to real-world threats:

Mitigating Distributed Credential Stuffing: An attacker using a tool like OpenBullet launches a credential stuffing attack against your login page, rotating through thousands of residential proxy IPs. Traditional rate limiting is ineffective here. However, the OpenBullet software has a consistent TLS fingerprint. By setting a rule to limit failed login attempts per TLS fingerprint, you can detect and block the entire distributed attack, regardless of how many IPs are involved.
Protecting APIs from Abuse: A partner is abusing their API key, sending far too many requests and degrading service for other users. By rate limiting based on the Authorization header, you can enforce usage limits on a per-client basis, keeping access fair without affecting other users.
Stopping Content Scrapers: A scraper is hammering your e-commerce site to steal pricing data. They are using a botnet to distribute the requests across hundreds of IPs. However, the scraping script has a unique combination of a user-agent and a TLS fingerprint. Advanced rate limiting can count requests based on this combined signature and block the scraper, protecting your intellectual property.

When attackers are distributed, your defences need to see the single actor behind the many IPs. Advanced rate limiting provides that visibility and should be part of a modern application security strategy.

The Bot Spectrum

2025-09-01T00:00:00+10:00

The word "bot" is often used as shorthand for unwanted automation: scripts trying to break into accounts, scrape content, or overwhelm websites. A large share of internet traffic does come from bad bots, but automated traffic is not automatically harmful. Some bots are part of how the web is discovered, monitored, and kept usable.

Effective bot management is not about blocking every automated request. It depends on accurate classification: separating good bots from bad bots, and recognising the "grey" bots that sit between them. That classification lets you apply controls that reduce risk without cutting off traffic that helps your site operate.

Good Bots: The Essential Workers of the Web

Good bots are automated programs that perform useful or necessary tasks. They are usually clear about who they are and respect the rules you set in your robots.txt file. Blocking them can damage search visibility, monitoring, or other business workflows.

Examples of Good Bots:

Search Engine Crawlers: Bots like Googlebot and Bingbot are the best-known good bots. They crawl and index your website's content, which is how your pages appear in search engine results. Blocking them would make your site invisible on Google.
Performance Monitoring Bots: These bots are used by services to check your website's uptime and performance from different locations around the world, and to alert you if your site goes down.
Copyright Bots: These bots scan the web for plagiarised content, helping to protect your intellectual property.

Management Strategy: Good bots should be identified and allowed to access your site freely. Verification techniques, such as reverse DNS lookups, can be used to confirm that a bot claiming to be Googlebot is actually coming from Google.

Bad Bots: The Malicious Actors

Bad bots are designed for malicious activity. They are a major reason bot management exists as a security function. These bots are deceptive, often hiding their identity and purpose, and they can be responsible for a wide range of costly and damaging activity.

Examples of Bad Bots:

Credential Stuffers: These bots use stolen usernames and passwords to carry out account takeover attacks.
Content and Price Scrapers: These bots steal your valuable content, product listings, and pricing data, often for use by competitors.
Spam Bots: These bots flood comment sections, forums, and contact forms with unwanted ads or malicious links.
Denial of Service (DDoS) Bots: These bots are part of a botnet used to overwhelm a website with traffic, causing it to slow down or crash.
Inventory Hoarding Bots: Common in e-commerce, these bots automatically add limited-edition products to shopping carts to prevent legitimate customers from buying them, often for resale at a higher price (scalping).

Management Strategy: Bad bots need to be accurately identified and blocked as quickly as possible, ideally at the network edge before they consume your server resources.

Grey Bots: The Nuanced Category

Grey bots are not inherently malicious, but their behaviour can still cause problems. They often serve a legitimate purpose, but become an issue when they crawl too aggressively, consume excessive bandwidth or server resources, and slow the site down for real users.

Examples of Grey Bots:

Aggressive SEO Tools: Bots from marketing tools like Ahrefs, SEMrush, and Majestic crawl websites to gather data for backlink analysis and competitive research. They can be useful, but their crawling can also be heavy.
Partner and Aggregator Bots: These could be bots from partner companies or price comparison websites that need to access your data. The activity may be legitimate, but it still needs to be managed.
Feed Fetchers: Bots that collect data for news aggregators or other applications fall into this category.

Management Strategy: Grey bots require more than a simple allow or block rule. The best strategy is often to rate-limit or tarpit them.

Rate-Limiting: This allows the bot to continue accessing your site, but slows it to a manageable level so it does not overwhelm your servers.
Tarpitting: This intentionally slows the connection for a specific bot, increasing the cost and time required to crawl your site and discouraging overly aggressive behaviour.

By classifying incoming bot traffic and applying the right control for each category, organisations can block threats, manage resource consumption, and allow the useful automation the modern web depends on.

Rate Limiting for API Security

2024-01-24T13:00:00+11:00

Rate limiting prevents servers from being overwhelmed by too many requests in a short period of time. Typically, rate limiting is configured using rules made up of a filter, for example a path like /login, and a limit on the number of requests a user can make in a given time, such as 10 requests in a minute. If a user exceeds this limit, they are usually blocked for a timeout period.

But how do you identify a user? Traditionally rate limiting has used the IP address for grouping requests, assuming that requests from the same IP address will be the same user. That assumption is now weak. IP addresses are rarely static and are often shared. For example, an office network might have hundreds of individual computers in it but present a single IP address for all those computers to the internet. Mobile operators commonly use carrier-grade network address translation (CGNAT) to share the same IP across thousands of devices or users. Bot networks, seeking to avoid security controls like rate limiting, will rotate their requests through thousands of different IP addresses. This makes rate limiting based on IP addresses a poor choice from both a functional and a security perspective.

Introducing Advanced Rate Limiting

Peakhour's Advanced Rate Limiting service lets you create filters using any HTTP request characteristic, for example URI, request method, headers, cookies, country, network fingerprints and more. You can also use response headers and response codes, so a rule can count failed login attempts, repeated 404s from a scraper, or traffic that crosses an API threshold.

For counting requests you can use the following fields for grouping:

IP Address
ASN
Country Code
HTTP/2 Fingerprint
TLS Fingerprint
Any combination of Request Headers

You can use one of those fields, or a combination of them, to identify users with more control than IP address alone.

You can also separate the filter and mitigation expression. For example excessive attempts to /login can be blocked on the entire site.

This matters because rate limiting is not just a request counter. In Peakhour it sits beside bot management, WAF, DDoS protection, traffic controls, and origin shielding on the same managed edge path. That gives operators a practical way to set different thresholds for verified crawlers, suspicious automation, authenticated API clients, and normal visitors without pushing every policy change into the application. It also gives them allowed, blocked, and threshold-hit evidence to tune the rule after it is deployed, whether Peakhour is the active edge or adding controls beside an existing CDN or cloud edge.

Putting it into action

Advanced Rate Limiting can help protect applications from attacks like Layer 7 DDoS, Account Takeovers, Credential Stuffing, and more. Here are some real world examples you can configure using our dashboard and API.

Protect against general site abuse

Our example website is a medium-sized ecommerce store that has page URLs ending in /. It serves Australian clients and typically sees around 100 page requests a minute from non-search-engine traffic during peak traffic times. With that baseline, we can set up rate limiting to prevent general site abuse and protect against layer 7 DDoS attacks.

Peakhour rate limiting starts with zones. You specify your request limits in these zones.

Here we've specified a maximum of 45 requests in 1 minute. We're going to apply this limit to page loads only. Since our typical maximum for all users on this website is 100 in a minute, it seems reasonable that a real user is not going to view 40 pages in 1 minute. We could also specify a value for error responses in a minute. An error could be a 404, which a scraper might typically get when looking for removed URLs.

Now let's define our filter and our counter. For our filter we mentioned that pages end in /, so we'll use that, but exclude verified bots to make sure they're not restricted when crawling the site. A verified bot is a crawler like Google or Bing, that Peakhour has verified as legitimate by using reverse DNS to confirm they are who they say they are.

Attackers, scrapers, and others looking to abuse a site will launch an attack using a particular piece of software. That piece of software will have a TLS fingerprint (like JA3) that remains the same, even as the attacker rotates their user-agent, IP address, and other characteristics, so we'll use the TLS fingerprint as our request counter.

Rate Limit authenticated API Users

It is common for APIs to require an Authorization header as part of the request to authenticate access. By grouping requests on the value of this header, we can rate limit a specific API client even if it uses multiple applications, or if its credentials are stolen.

Protecting from Account Takeovers

Account Takeover attacks have been in the news recently, with several high-profile websites being victims. Credential Stuffing and Brute Force attacks rely on attempting lots of logins to identify valid credentials. Along with lots of attempts come lots of failures. Attackers will rely on software like openbullet to carry out their attacks, using proxy networks to constantly rotate IP addresses and defeat traditional rate limiting.

The program the attacker is using will present a consistent TLS fingerprint. We can make a special rule for our login form that tracks failed login attempts by TLS Fingerprint, effectively tracking the attacker as they rotate IP address.

If the attack is low and slow, we can track failed attempts over a longer timeframe by using the response from the server when adding to our counting zone.

Final Thoughts

Advanced rate limiting is a practical response to the limits of IP-based controls. IP address rotation is the standard amongst attackers and scrapers, rendering the traditional approach obsolete. Useful protection now needs to identify the actor behind the requests, protect the origin before expensive application work is triggered, and give teams enough evidence to adjust the policy without guesswork. Counting requests against a combination of network fingerprints, request fields, response signals, and bot context is how you stop abuse from scrapers, SEO spiders, and layer 7 attackers without treating every visitor the same.

RFC 9460

2023-11-16T00:00:00+11:00

RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.

Understanding the Current Process

Traditionally, when a browser connects to a website, it follows a sequence:

Browser requests site via HTTP.
Server redirects request to HTTPS.
Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.

The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.

The Impact of SVCB and HTTPS Records

SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.

Adoption and Industry Response

Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.

As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.

What the Records Look Like

A typical SVCB record might look like this:

_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")

This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.

An HTTPS record could be:

example.com. 3600 IN HTTPS 0 svc.example.net.

This record suggests that example.com should be accessed securely through svc.example.net.

Apex Domains and the Importance of SVCB/HTTPS Records

One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.

These records enhance capability

1. Load Balancing:

Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.

example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")

In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.

2. Failover Mechanism:

For a service that requires high availability, SVCB records can express failover directly:

critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")

Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.

3. Apex Domain Usage:

A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.

example.com. IN HTTPS 0 cdn-provider.example.net.

This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.

4. Encrypted ClientHello Support:

Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.

secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")

This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.

5. Directing Traffic to Specific Protocols:

For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.

api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")

Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.

The Long Wait

HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.

It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.

Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies

Final Thoughts

RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.

HTTP/2 Rapid Reset Attack Deepdive

2023-10-12T00:00:00+11:00

Distributed Denial of Service (DDoS) attack vectors keep changing. The recent spike in HTTP/2-based DDoS attacks has been notable for its volume, with some attacks surpassing 398 million requests per second. Peakhour observed these attacks and worked through how to understand and mitigate them. This article explains how they work and what operators can do to reduce exposure.

The Rise of HTTP/2 in DDoS Attacks

HTTP/2 was designed to make web traffic more efficient. The same features that improve performance for legitimate users can also be abused in DDoS traffic.

Much of HTTP/2's efficiency lies in "stream multiplexing." It allows multiple messages to be sent over a single TCP connection. While HTTP/1.1 processes each request serially, HTTP/2 can manage multiple concurrent streams on a single connection. This means a client can send multiple requests in a single round trip, increasing how much work each connection can drive.

The 'Rapid Reset' Attack Explained

The "Rapid Reset" attack is a specific DDoS technique built around HTTP/2. The attacker starts by opening multiple streams, much like in a standard HTTP/2 attack. However, instead of waiting for responses, they cancel each request immediately.

The client does this by sending a RST_STREAM frame, indicating that a previous stream should be cancelled. The rapid request-and-reset sequence means the server spends resources processing the request, only for it to be cancelled before a response is generated. This tactic amplifies the server's workload without the attacker needing to wait for responses, which increases the pressure each connection can place on the server.

Variants of the Rapid Reset Attack

Attackers also used variations of the Rapid Reset attack:

One variant involves delaying the reset action. The attacker opens multiple streams, waits, then cancels the streams and instantly opens new ones. This method can evade some rate-based defences.
Another variant avoids stream cancellations. Instead, the attacker tries to open more streams than the server allows. This aims to keep the server continually busy, processing a near-constant flow of requests.

Effective Mitigation Techniques

Mitigation is not as simple as blocking individual malicious requests. A more effective approach is to close the entire TCP connection when malicious activity is detected. The HTTP/2 protocol supports connection termination through the GOAWAY frame. This feature needs to be used aggressively to prevent Rapid Reset attacks, rather than relying on the more passive, standard implementation.

Deciding which connections to treat as malicious is a challenge. One potential strategy is to monitor connection statistics. If a connection exceeds a set threshold of cancelled requests, it might be deemed malicious. Responses to suspect activity could range from sending a GOAWAY frame to terminating the TCP connection.

For the non-cancelling variant, the best approach is to shut down connections that breach the concurrent stream limit, either immediately or after a few violations.

Broader Protocol Implications

These attack techniques are specific to HTTP/2, but the wider protocol lesson still matters. The HTTP/3 (QUIC) protocol isn't directly vulnerable in the same way. As a precaution, server implementations should consider limiting the work done by a single connection.

The Importance of Industry Collaboration

When the threat of the Rapid Reset attack became apparent, the industry collaborated to address the issue. The vulnerability was disclosed to key HTTP/2 implementers, helping to devise and distribute effective countermeasures. The vulnerability is logged against CVE-2023-44487.

HTTP/2 'Rapid Reset' DDoS attacks pose a serious risk to services using the protocol. To reduce exposure, service providers should promptly apply available software patches and updates.

Learn how Peakhour's Application Security Platform helps protect against Layer 7 DDoS attacks, including the HTTP/2 Rapid Reset vulnerability. Contact our team to secure your infrastructure.

Understanding the HTTP/2 Rapid Reset Attack

2023-10-11T00:00:00+11:00

The discovery of the HTTP/2 Rapid Reset flaw exposed a serious weakness in a widely used version of the HTTP protocol. When exploited, it can be used to generate large Distributed Denial of Service (DDoS) attacks against HTTP/2 services. This post explains how the attack works and what operators can do to strengthen their defences.

A Deep Dive into the HTTP/2 Rapid Reset Flaw

HTTP/2 is widely deployed, so a flaw in how implementations handle rapid stream resets can have a large operational impact. To take advantage of the issue, a malicious actor sends a request and immediately cancels it, then repeats that pattern over the same HTTP/2 connection. By scaling this "request, cancel" behaviour thousands of times, an attacker can overwhelm vulnerable HTTP/2 implementations. The result is DDoS attacks at the application layer, with potential downtime and disruption.

Major companies including Cloudflare and Google have dealt with this issue. Google, for example, mitigated a DDoS attack reaching a peak of 398 million requests per second that relied on this technique. For scale, this two-minute-long attack generated more requests than the total number of article views reported by Wikipedia in September 2023.

Mitigating the Threat

Large infrastructure providers have led much of the work to understand the attack mechanics and develop mitigations:

Patching Systems: Prompt patching is the primary control for the HTTP/2 Rapid Reset attack. Companies including Peakhour, Microsoft, and others have tested and patched their systems against this threat.
Rate Limiting: Advanced rate limiting has been a recommended action. It provides an extra layer of protection, minimising the risk of massive request inflows.
Collaborative Efforts: Google and Microsoft have both shared intelligence and collaborated with other cloud providers and software maintainers implementing the HTTP/2 protocol stack. This has resulted in patches and mitigation techniques now employed by numerous large infrastructure providers.

What's Next for Users and Enterprises?

If you serve an HTTP-based workload online, understand whether this attack affects your environment. Verify that servers supporting HTTP/2 are either not vulnerable or have applied the necessary patches. Stay informed and consider reaching out to your service providers or account representatives for configuration assistance and guidance.

The HTTP/2 Rapid Reset flaw is a serious application-layer DDoS risk, but it is manageable with the right mitigations in place. Apply the recommended patches and keep HTTP/2-facing services under active review.

Discover how Peakhour's Application Security Platform protects against Layer 7 DDoS attacks, including the HTTP/2 Rapid Reset vulnerability. Contact our team to secure your infrastructure.

ZDNS - scan the entire internet

2023-06-20T13:00:00+10:00

The lack of a free Reverse DNS (rDNS) lookup database has made large-scale DNS research harder. To address this, we used ZDNS, an open-source, high-performance DNS toolkit developed by Stanford University, to create our own rDNS database. To reduce UDP timeout issues during rDNS operations, we devised a scan-ordering approach that randomised the IP space and improved the efficiency of the scanning process.

Leveraging ZDNS for rDNS Lookups Across the Internet

Understanding rDNS is useful for internet operations and research. Active DNS measurement helps us inspect how providers advertise the use of their IP address space. One of the components of this ecosystem is Reverse DNS (rDNS), which serves an important role in IP database categorisation and ASN (Autonomous System Number) classification. However, running rDNS across the entire internet is not a trivial task.

Previously, Rapid7 provided a free database for rDNS lookups, but it has discontinued the offering. This situation has prompted the need to create our own database, calling for a robust, efficient, and scalable tool to accomplish the task. ZDNS was the right fit.

Introducing ZDNS

ZDNS, a part of the ZMap.io project, is a capable tool developed by Stanford University to support scalable and reproducible DNS research. ZDNS is an open-source DNS measurement framework specifically optimised for large-scale DNS research on the public internet. It can resolve 50 million domains in 10 minutes and query the PTR records of the complete public IPv4 address space in approximately 12 hours.

This high-performance toolkit offers a modular interface, enabling researchers to safely implement new functionalities. Its architecture is designed to expose DNS lookup chains by performing recursive resolution. ZDNS supports a command-line interface and outputs results in JSON, a machine-parsable format.

Enhancements by ZDNS

ZDNS's architecture and feature set are tailored to the challenges of extensive DNS research. Its guiding principles are that the DNS lookup chain is exposed, and that the tool is safe, easy to use, and extensible.

ZDNS's performance optimisations make it a suitable tool for DNS experiments that require querying a large number of names. Parallelism, UDP socket reuse, and selective caching are some of the critical performance optimisations that enable ZDNS to efficiently handle large volumes of DNS queries.

ZDNS's scalability, execution time, and success rate have been evaluated against several existing tools, showcasing its performance. For instance, when it comes to exposing the DNS lookup chain, ZDNS is 85 times faster than Dig. ZDNS also outperforms other higher-performance tools, achieving 2.6 to 3.6 times more successful queries per second and experiencing about 30% less packet drop than MassDNS.

Our rDNS Journey

When we started scanning the whole internet with rDNS, we hit a practical roadblock: UDP timeouts made the scans slow. The system spent too much time waiting for responses from parts of the internet that were either empty or broken.

We used two changes. Firstly, instead of scanning the internet's addresses in order, we mixed them up and scanned randomly. This spread out our requests and stopped the system from getting stuck on troublesome ranges. Secondly, we checked smaller sections of the internet first, so we did not waste time waiting for big chunks of the internet that weren't responding.

With these changes, we scanned the whole internet in 13 days, finding over a billion addresses. The main lesson was straightforward: scan order matters when timeout behaviour dominates runtime.

Wrapping Up

ZDNS has proven to be a valuable tool for DNS research, especially for substantial tasks like performing a reverse DNS scan of the entire internet. Our experience underscores the value of practical adjustments when dealing with large-scale challenges, like randomising the IP space to avoid delays caused by UDP timeouts.

As an open-source tool, ZDNS is available on Github. For more detail, read the award-winning paper presented at IMC 2022.

Our work with ZDNS shows its value in DNS research and the operational detail involved in large-scale DNS work. By randomising the scan order, we mitigated timeout issues and improved the efficiency of our scanning process.

Izhikevich, L., Akiwate, G., Berger, B., Drakontaidis, S., Ascheman, A., Pearce, P., Adrian, D., & Durumeric, Z. (2022). ZDNS: a fast DNS toolkit for internet measurement. In Proceedings of the 22nd ACM Internet Measurement Conference (pp. 33-43). https://doi.org/10.1145/3517745.3561434 ↩
ZMap Project. (n.d.). ZDNS. GitHub. Retrieved 2023-05-15 13:00, from https://github.com/zmap/zdns. ↩

Enterprise DDoS Protection

2023-06-19T00:00:00+10:00

Cyber threats continue to grow in complexity and volume, and Layer 7 attacks remain especially difficult to defend against¹. Each layer presents its own set of vulnerabilities for threat actors to exploit. The 7th layer, or application layer, handles application-specific communications. That makes it a useful target because modern applications are complex and varied.

Defending against Layer 7 attacks requires continuous tuning and adaptation¹. Microsoft highlighted the issue in June 2023, when it reported a traffic surge that temporarily affected the availability of some of its services¹.

Microsoft's Layer 7 DDoS Attacks

Microsoft's security team detected and tracked DDoS activity from a threat actor it called Storm-1359. The actor used a mix of resources, including multiple virtual private servers (VPS), rented cloud infrastructure, open proxies, and DDoS tools¹.

The activity did not target layers 3 or 4. It targeted layer 7, where requests can look like regular traffic and arrive from source IPs distributed around the world.

The Attack Methods

Storm-1359 used several attack types, including:

HTTP(S) Flood Attack: The attacker aimed to exhaust system resources with a high load of SSL/TLS handshakes and HTTP(S) request processing. This attack led the application backend to run out of compute resources such as CPU and memory¹.
Cache Bypass: The attacker attempted to overload the origin servers by bypassing the CDN layer¹.
Slowloris: In this case, the client opens a connection to a web server, requests a resource, such as an image, but fails to acknowledge the download or accepts it slowly. This causes the web server to keep the connection open and hold the requested resource in memory¹. Strengthening Layer 7 Protections

Microsoft mitigated the majority of disruptions by hardening its Layer 7 protections. It fine-tuned Azure Web Application Firewall (WAF) to better defend customers from the impact of similar DDoS attacks¹.

Azure Web Application Firewall, ModSecurity, and DDoS Attacks

Azure Web Application Firewall (WAF), part of Microsoft's security architecture, is built upon ModSecurity⁴, a well-established open-source Web Application Firewall (WAF) module¹. The DDoS attack Microsoft faced highlighted potential limitations in using ModSecurity, or any conventional WAF, as the primary defence mechanism against such threats.

ModSecurity's Limitations in DDoS Defence

ModSecurity is effective against a variety of web application threats, but it has limitations when dealing with DDoS attacks:

Lack of Scalability: ModSecurity is not inherently scalable. It can struggle to handle the enormous traffic volume associated with DDoS attacks.
Delayed Response: ModSecurity's rule-based approach can result in slower response times to evolving DDoS threats. While it can block threats based on established rules, it can take time to identify and create rules for new or uncommon attack patterns.
Operational Complexity: ModSecurity requires substantial expertise and constant fine-tuning to remain effective, potentially slowing down response times during a fast-paced DDoS attack.

These limitations were visible during the DDoS attack Microsoft experienced. Even though Microsoft utilised ModSecurity via Azure WAF, the time it took for Azure to respond underlines the challenge of using traditional WAFs for this class of attack¹.

The Role of Residential Proxy Networks in Layer 7 DDoS Attacks

Residential proxy networks create a specific problem in the defence against Layer 7 DDoS attacks³. These networks use IP addresses tied to physical locations, often originating from typical home or office internet connections. That makes it harder to separate legitimate traffic from malicious traffic.

Unlike traditional proxy or VPN networks, where traffic can be blocked or rate-limited based on their recognisable IP ranges, residential proxy networks blend in with legitimate users. That complicates identifying and blocking malicious requests, as any blocking or limiting measures could affect legitimate traffic from residential IPs.

A Potential Solution

In this context, fingerprinting can help distinguish between legitimate clients and malicious actors. Fingerprinting involves gathering data points from each client request, including user agent, IP address, headers, cookies, and more. The combination of these data points creates a unique 'fingerprint' for each client.

By analysing these fingerprints, it is possible to detect anomalous request patterns and potentially identify malicious clients hidden behind residential IPs. Fingerprinting can improve the accuracy of identifying malicious traffic, but it is not foolproof and should sit inside a broader, layered defence strategy.

Implementing effective fingerprinting also requires substantial technical expertise and resources. The measures need to avoid degrading user experience or breaching privacy regulations.

The Need for Specialised Rate Limiting Services

A specialised rate limiting service could have offered a faster and more effective response to the DDoS attack. Rate limiting restricts the number of requests that an IP address can make within a specific time period².

Such a service offers several advantages when defending against DDoS attacks:

Rapid Response: Rate limiting can provide a quick initial defence against a DDoS attack by immediately limiting traffic from suspicious IP addresses.
Flexibility: Rate limiting rules can be applied to factors such as IP addresses, URL, headers, response codes, and more, creating more granular defence mechanisms.
Reduced Load: By limiting the rate of requests, these services can reduce the load on the server, preserving resources for legitimate traffic.

Advanced Rate Limiting and Custom Keys

One way to defend against these attacks is through advanced rate limiting². Rate limiting restricts the number of requests an IP address, URL, or another custom key can make in a set time period. This can stop a single actor from flooding a network with traffic.

Criteria Used in Rate Limiting

Rate limits can be defined using different criteria:

IP Address
URL
Query String
Headers
Response Codes
GeoIP Information: ASN or Country Code
Parsed User Agent Information: Different rules for search engines vs. generic 'bots'
Fingerprints: TCP, TLS or H2 fingerprints can uniquely identify the connecting software
Meta Information: From bot protection service²

This allows rate limiting to 'bucket' requests using different criteria, effectively rate limiting a larger group of connections.

The Role of Anomaly Detection

Anomaly detection is another useful tool against these attacks. It identifies patterns or events that deviate from the norm and may indicate suspicious activity. Detecting those anomalies quickly can help teams respond faster, identify a suitable rate limit key and stop the potential attack.

Caching as a Mitigation Strategy

Caching is an effective mitigation strategy for Layer 7 attacks. It stores static responses to requests, reducing load on the server by serving those responses instead of processing each request individually. In a DDoS scenario, where a flood of requests is sent to the server, caching can help maintain availability. Ignoring client-provided 'Cache Control' headers such as 'max-age=0' or 'no-cache' can be effective because these headers are typically used to bypass a CDN.

Recommendations for Defence Against Layer 7 Attacks

Use anomaly detection to identify an active attack.
Use Layer 7 protection services, including rate limiting, with past 99th percentile hit rates as a starting point.
Apply bot mitigation techniques, as most Layer 7 attacks originate from bots.
Use IP reputation as an early warning sign, as many IPs have been involved in attacks before.
Block, limit, or redirect traffic from outside a defined geographic region.
Rate limit or block requests from data centre and hosting ASNs.
Create custom WAF rules to automatically block and rate limit HTTP or HTTPS attacks with known signatures.
Use effective CDN caching and ignore client-presented Cache-Control headers.

Defending against Layer 7 attacks requires several controls working together. Rate limiting, anomaly detection, and effective caching all have a role.

Peakhour's advanced rate limiting and DDoS mitigation strategies help protect applications from sophisticated Layer 7 attacks. Contact our team to strengthen your defences.

Understanding HTTP Link Headers

2023-05-24T13:00:00+10:00

HTTP headers are part of browser requests and server responses. They carry information about the connecting client, the requested resource, the server, and other request context. An HTTP header has a case-insensitive name followed by a colon (:), then its value. Headers are used for authentication information, content negotiation, and related protocol behaviour. Here are some sample request headers sent by my browser when requesting a page on the Peakhour website:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-AU,en;q=0.9
Connection: keep-alive
Cookie: _ga_NRWSVE0PSC=GS1.1.1685943893.13.0.1685943893.0.0.0
Host: www.peakhour.io
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4.1 Safari/605.1.15

The HTTP Link header

An HTTP Link header lets a server send context about a document back to a client. It can identify related resources or the direct location of a specific asset. For page-load optimisation, Link headers can be an alternative to putting preload/preconnect/prefetch hints in the HTML.

History

HTTP Link headers were proposed as a standard in the late 1990s, around the same time the HTTP/1.1 protocol was defined. However, it wasn't until 2010 that HTTP Link headers were officially recognised by the Internet Engineering Task Force (IETF) in RFC 5988, which described their purpose and functionality.

Uses

HTTP Link headers have several uses in web development. Some common examples are:

Pagination: Say we have a blog site with hundreds of posts, and we display 10 posts per page. When a user requests a page, we can use Link headers to provide URLs for the next and previous pages. This helps navigation through the large list of posts. Here's an example of how it might look:
```
Link: </posts?page=2>; rel="next", </posts?page=4>; rel="prev"
```
Preloading: Suppose we have a heavy image or a large CSS file that we know will be required for a webpage. We can use a Link header to tell the browser to start downloading it early, improving the perceived page load speed. For instance:
```
Link: </images/big-picture.jpg>; rel=preload; as=image
```
Resource Hints: Link headers can give the browser hints about resources that might be needed in the future, so the browser can decide whether to fetch them ahead of time. For instance:
```
Link: </scripts/myscript.js>; rel=prefetch
```

Comparison to Link Tags and Why Headers Can Be Better

Now you might be wondering, "Why use Link headers when we can use HTML Link tags?" There are several reasons HTTP Link headers might be a better choice:

Faster Processing: Since HTTP Link headers are part of the HTTP response, they arrive before the HTML document. This allows browsers to start preloading or prefetching resources sooner, which can improve page load times.
Greater Flexibility: HTTP Link headers can be used in situations where HTML Link tags cannot. For instance, they can be used with file types that don't support HTML, like JSON or XML. They can also be added by a third party, e.g., an edge delivery layer such as Peakhour, without the need to parse and rewrite the HTML document.
Less Clutter: Link headers can make your HTML less cluttered, as you can avoid filling the HTML document with numerous Link tags.

Conclusion

HTTP Link headers are a small part of HTTP, but they are useful for performance and flexibility. An edge delivery layer can add Link headers without the overhead of parsing or manipulating the main document, which makes them useful for optimising website performance.

Consistent Hash with Bounded Loads

2023-05-15T13:00:00+10:00

A consistent hash with load bounds extends the basic consistent hashing technique. Standard consistent hashing distributes keys across servers in a way that minimises rehashing when servers are added or removed, but it does not guarantee a perfectly even load distribution. Random hash collisions can leave some servers responsible for significantly more keys than others, creating an imbalance in the load distribution.

Consistent hashing with bounded loads, or bounded-load hashing, addresses this issue. It keeps the load (i.e., the number of keys assigned) on any given server within a factor of the average load across all servers.

The approach still uses a hash ring, but with an additional constraint that no server can exceed a certain load limit. When a key is hashed and the corresponding server in the hash ring is already at its load limit, the key is assigned to the next server in the hash ring that isn't at its load limit. This process is repeated until all keys have been assigned.

Here's a rough pseudocode example:

# Function to add a key with bounded loads
def add_key_bounded(key):
    position = hash_function(key)

    # Find the server for this key
    for i in range(position, position+1000):
        i = i % 1000  # To loop back to the beginning of the ring
        if hash_ring[i] is not None and server_loads[hash_ring[i]] < LOAD_LIMIT:
            server_loads[hash_ring[i]] += 1  # Increment the server's load
            return hash_ring[i]  # Return the server that should handle this key

In this example, server_loads is a dictionary that tracks how many keys each server is responsible for, and LOAD_LIMIT is the maximum number of keys any server is allowed to handle.

By bounding the load on each server, this approach can produce a more balanced distribution of keys across servers. However, it's worth noting that this algorithm can result in keys being assigned to servers that are not their nearest neighbours in the hash ring, which can increase latency in some cases. As with any algorithm, there's a trade-off between load balancing and other factors such as latency and computational overhead.

The Google Cloud team, in collaboration with visiting researcher Mikkel Thorup from the University of Copenhagen, devised an efficient allocation algorithm to improve load balancing in large-scale web services such as content hosting. The results of their research were detailed in a paper titled “Consistent Hashing with Bounded Loads” that was published in August 2016.

Load balancing in large-scale web services means distributing client requests evenly across multiple servers to prevent any individual server from becoming overloaded. An ideal load-balancing system distributes the load uniformly and minimises the changes to the system when servers or clients are added or removed. This consistency matters in dynamic environments where servers and clients can change over time.

Traditional consistent hashing techniques, although effective for load balancing in dynamic environments, can still lead to sub-optimal load distribution across servers in certain scenarios. As both servers and clients can be added or removed frequently, the load balancing algorithm needs to stay dynamic and adaptive, maintaining an evenly distributed load while minimising the number of client reassignments whenever a change occurs.

Google's algorithm addresses these challenges. To explain their method, they use an analogy of servers as bins and clients as balls. The goal is for all bins (servers) to have a load (clients) roughly equal to the average density, with a small tolerance factor, ε. The algorithm is designed to ensure that every bin has a capacity within the range of the average load times (1+ε), which helps achieve both uniformity and consistency in client-server allocations.

The algorithm employs two separate hash functions to assign positions to balls (clients) and bins (servers) on a circular continuum. The balls are then allocated in a specific order (say, based on their ID), with each ball being assigned to the first bin it encounters with spare capacity as it moves clockwise on the circle.

The algorithm recomputes the allocation whenever an update occurs (i.e., the addition or removal of a client or server) to maintain the uniform distribution of load. The paper proves that every ball removal or insertion in the system results in O(1/ε²) movements of other balls. Importantly, this upper bound is independent of the total number of balls or bins in the system, which means the algorithm scales well with increasing size.

The algorithm creates a trade-off between uniformity and consistency. A smaller ε value provides better uniformity but compromises consistency, while a larger ε value improves consistency but reduces uniformity. The algorithm performs well even in worst-case scenarios, making it ideal for dynamic, large-scale environments like content hosting services.

Google's algorithm has been used in production. Andrew Rodland from Vimeo implemented it in HAProxy, a popular open-source software package, for their load balancing project, resulting in a substantial decrease in cache bandwidth by almost a factor of 8. This eliminated a significant scaling bottleneck, showing the algorithm's practical effectiveness.

Overall, the work of the Google Cloud team and Mikkel Thorup is a useful contribution to load balancing. By addressing the challenges of uniformity and consistency in dynamic environments, their algorithm provides a robust solution for managing large-scale web services efficiently. The team's research and its open-source availability give the broader community a practical implementation path.

Multi-Origin Load Balancing

2023-04-11T13:00:00+10:00

Websites and applications with global audiences often run into a problem that a standard CDN cannot always hide: not every request can be served from cache. Traditional Content Delivery Networks (CDNs) reduce latency by distributing content across multiple points of presence (POPs) around the world. But when content has to be fetched from a distant origin server, for example dynamic content that cannot be cached, users still wait on that round trip. This post explains the problem multi-origin load balancing solves and how Peakhour handles it.

Understanding the Problem

Web content usually starts from a single server, called the origin server. As a website's audience grows, that server takes more traffic, which can slow response times. CDNs reduce the pressure by caching and delivering content from servers distributed across multiple geographic locations. When the content is already cached, this reduces origin load and lowers latency for users accessing the content.

However, traditional CDNs still have limits when serving global audiences. If a user requests content that is not cached in the CDN, the request has to go back to the origin server. If that origin is far away from the user, latency increases and pages take longer to load.

Multi-origin load balancing addresses that remaining gap in CDN performance and further reduces latency.

Introducing Multi-Origin Load Balancing

Traditional load balancing distributes traffic evenly across two or more servers that are physically hosted in the same location.

Multi-origin load balancing extends that approach across origin servers in different geographical locations. The Peakhour EDGE can select the closest origin server to a user, or choose a different origin based on criteria such as device type, user preferences, or URL. For requests not stored in the CDN, this reduces the time spent crossing long network paths.

Real-Time Performance Monitoring: Peakhour continuously monitors its global network of servers in real time. This allows the system to detect potential issues or bottlenecks and adjust routing. If one origin server experiences high traffic or goes offline, Peakhour can reroute user requests to the next best server to keep the site responsive.

Adaptive Content Caching: Peakhour Edge uses adaptive content caching strategies, which dynamically cache both static and dynamic content based on user behaviour and request patterns. Frequently requested dynamic elements, such as personalised user data or search results, are cached on edge servers, reducing the need to fetch content from the origin servers and further minimising latency.

Load Balancing and Failover: Peakhour's multi-origin load balancing is complemented by load balancing and failover mechanisms. These features keep the system resilient and responsive during periods of high traffic or server outages. By distributing user requests evenly across origin servers and automatically redirecting traffic when a server fails, Peakhour maintains a stable and reliable content delivery experience for users worldwide.

Conclusion

Multi-origin load balancing addresses the limitations of traditional CDNs by optimising content delivery for a global audience. Peakhour Edge reduces latency and improves the experience for users who would otherwise wait on a distant origin server.

As web content and applications grow in complexity and reach, origin placement and routing become part of performance planning. Peakhour implements multi-origin load balancing with clients' origin servers so requests can be sent to the most suitable origin instead of treating a single distant server as the only fallback.

Introducing Automatic Cache Tags in the Updated Peakhour WordPress Plugin

2023-03-20T13:00:00+11:00

We have updated the Peakhour WordPress plugin with automatic cache tag generation. The update is designed to help keep cached WordPress content accurate without forcing full cache clears for routine content changes. We have also checked compatibility with the latest versions of WordPress and PHP.

What are Cache Tags?

Cache tags are labels that CDNs such as Peakhour use to manage cached content more precisely. Instead of clearing the whole cache when one page changes, you can purge only the content associated with the relevant tag. Visitors get the updated content, while the rest of the site can continue to be served from cache.

A Cache Tag Example

Suppose you run a site with a home page, product pages, and blog articles. Without cache tags, updating one product page or article may require clearing the entire cache. With cache tags, each part of the site can use its own tag, such as "homepage," "product," and "blog." When you update content, you only need to purge the cache for the affected tag. That means less unnecessary cache invalidation and a faster site for visitors.

Automatic Cache Tags in the Peakhour WordPress Plugin

The updated Peakhour WordPress plugin generates cache tags automatically for your site's content. When you update content in the WordPress admin, the plugin sends the relevant purge requests to Peakhour. The result is more targeted cache clearing without extra manual work.

How to Get Started with Automatic Cache Tags

Update to the latest version of the Peakhour WordPress plugin.
Follow the instructions to configure cache tags in the Peakhour admin.
Flush your cache.

After that, the plugin generates cache tags and sends purge requests to Peakhour whenever you update content in the WordPress admin.

Final Thoughts

Automatic cache tags in the Peakhour WordPress plugin make cache purging more precise. They help improve performance, give you more flexibility, and reduce unnecessary cache clears. Try the updated plugin and let us know how it works for you.

Layer 7 DDoS Protection

2023-02-07T13:00:00+11:00

In previous blog posts we've covered the benefits that full page caching has on page load performance. We also covered how caching pages lowers origin server utilisation, so the site can handle more customers. A lesser-known side benefit is protection against Layer 7 denial of service (DoS) attacks.

What is a Denial of Service attack?

The goal of a DoS attack is to make a network resource, such as a website or networked service, unavailable to users by overwhelming it with excessive traffic or requests. DoS attacks can be launched from a single source or from multiple sources (known as a distributed denial of service, or DDoS attack).

Typically, an attacker floods the web server with HTTP or API requests to try to overwhelm it. An attacker might also launch a 'slow attack', especially if they find a weak point in the application that consumes a lot of server resources for a single request. One example is repeatedly using a site search function. By slowing down the rate at which requests are sent, the attacker can bypass common rate-limiting and traffic-shaping mechanisms that are designed to block high-volume traffic spikes.

DoS conditions can also be inadvertent. A CMS like Magento or WordPress on an underpowered server can be overwhelmed, or slowed to a crawl, by so-called 'grey' bots. Examples include Semrush, Ahrefs, dotbot, and MJ12Bot. These spiders can crawl a site aggressively enough to bring it to its knees. Even Bing or Google can negatively impact a site.

What is Layer 7?

In networking parlance, Layer 7 refers to the actual application running on a web server. It is part of the OSI (Open Systems Interconnection) model used to describe the various functions in transmitting data over a network. The model is as follows:

Layer 1 -> Physical Layer, responsible for transmitting raw bits of data, e.g., a wire or wireless link
Layer 2 -> Data Link, responsible for transmitting data frames between network devices and detecting transmission errors.
Layer 3 -> Network Layer, responsible for routing data packets between networks and determining the best path for transmission.
Layer 4 -> Transport Layer, responsible for end-to-end communication between applications, providing reliable data transmission and flow control.
Layer 5 -> Session Layer, responsible for establishing, maintaining, and terminating communication sessions between applications.
Layer 6 -> Presentation Layer, responsible for formatting data to be presented to the application layer and for converting data from the application layer into a standardised format for transmission.
Layer 7 -> Application Layer, responsible for providing services to the user, such as file transfer, email, and web access.

How Full Page Caching helps

Full page caching helps by reducing the number of dynamic requests to the server. Caching the entire page allows the server to serve pre-generated content to visitors, rather than generating it dynamically each time a page is requested. This reduces the server's processing load and helps prevent excessive requests from overloading the server or making it unavailable.

A real world example

As part of a series of Peakhour recommendations to 'harden' its website against layer 7 attacks, a Peakhour client (a government site) applied limited full page caching with a time to live of 10 minutes. This means that Peakhour will serve a page from its Edge cache for 10 minutes before hitting the origin again for a new version.

Not long after implementation, that change was tested: a DDoS originating from hundreds of IPs across multiple countries hammered a set of 5 pages. The attack was spread over several days with bursts of activity lasting about 15 minutes. With the first hit, the page was cached and every subsequent hit was served from our high-performance Edge cache. No slowdown was observed and the attackers gave up.

Real attack on a Peakhour client; the spikes formed in 15 minute bursts.

Real page load times measured in the client browser

But my site is dynamic...

Many websites have a small dynamic component on the page. For ecommerce sites this might be the mini cart in the top right showing the number of items in the cart, or it might be some personalisation for a user. Often these dynamic parts of the page can be rendered in the browser using Ajax or local storage, rather than rendered on the server. By moving the dynamic components to the browser, the full page becomes cacheable. Another option is to use Edge Side Includes (ESI), which enables the majority of the page to be cached in the CDN while the dynamic parts are fetched separately before serving the full page to the user.

Peakhour can help move dynamic page components from the server to the browser and cache more at the edge. We also have a range of CMS plugins that do just that. Contact us if you want some help.

Final Thoughts

Layer 7 DoS attacks have become more common than traditional DoS attacks, as they typically require far fewer resources from the attacker. Reducing dynamic requests to the origin using full page caching is a useful but underappreciated way to mitigate them. If you're concerned about website security, resilience, and performance, Peakhour helps you cache more so you can protect, accelerate, and scale your website.

Automatic Image Optimisation

2022-12-06T13:00:00+11:00

Since releasing our automatic image optimisation capability in 2019, Peakhour optimises more than 35 million images each month. On average, clients reduce page download time by 35% and image sizes by 91%.

Automatic image optimisation offers a number of benefits over manual optimisation:

Image formats are dynamically chosen based on the content of the image.
Files are optimised based on client capabilities.
Designer time is saved by offloading image optimisation work.
Page load times can be reduced across an entire website.

What is Image Optimisation?

Image optimisation means delivering high quality images in the right format and resolution for the device viewing them. The aim is to minimise file size without compromising visual quality. Smaller image files generally load faster in a visitor's browser, which can improve website speed, reduce traffic and support higher page visits and conversions.

Why dynamically choose the image format?

Using a one size fits all optimisation process does not account for the different types of images used across a typical website.

Website images can include:

Photographs, such as product images, demonstration photos and title photos.
Logos, which are typically text and can include animation.
Illustrations that incorporate custom graphics to support the quick perception of information.
3D graphics from computer renders including buildings, interior and exterior designs and products.
Combinations of the above!

Any optimisation process needs to account for the end user's device type, supported file formats, resolution and the content of the image. For example, a photograph with text needs different optimisation parameters so the text remains crisp, while images with large areas of colour may need different formats to avoid colours being degraded by lossy compression.

Fine developer control

With the image optimisation API, your developers can enable reactive images by resizing images on the edge. Peakhour serves and caches these optimisations, reducing origin requests and traffic, cutting costs and making image changes faster to ship. You no longer need to wait for a designer to resize, crop or re-orient an image for a page.

How does image optimisation effect web application performance

Large portions of a website are typically built from images. Large images loading over a 4G network in a train can delay image rendering and create a poor user experience. Layout shifts can occur as the browser attempts to render the page, and the user's perceived page load time will be affected.

You can see the benefit of automatic image optimisation with our free tool. It will analyse any website, calculate its optimisation potential and let you download the optimised images.

See how it can help in a real life example below

security.png

Original

2362 x 1266px

PNG

190.2 kb

Optimised

605 x 324px

png

10.8 kb

jpeg

15.4 kb

[webp](/products/image-optimisation-and-transformation/)

10.7 kb

avif

8.2 kb

Benefits of Peakhour Automatic Image Optimisation

Peakhour image optimisation is integrated into your website so you can reduce traffic, speed up page loads and remove manual image preparation from the design workflow.

Transforming images on the Peakhour edge enables agility and offloads origin work.
User experience is improved through faster-loading pages, without a separate workflow for image optimisation.
Take advantage of new image formats, as supported by end users' browsers, to improve the page load experience.

Final Thoughts

Peakhour image optimisation runs on Peakhour Edge. Images are optimised as they pass through the Peakhour network, and optimised versions are cached for reuse. Peakhour image optimisation also works with Origin Shield, with the original and transformed images cached appropriately. This reduces origin hits and bandwidth while speeding up image delivery.

Drupal full page caching module

2022-10-05T13:00:00+11:00

Drupal is an open source content management system (CMS) widely used by Australian government websites. For example, GovCMS is a customised version of Drupal. Peakhour now provides a purge module for Drupal 8/9, extending our existing Drupal support.

The Peakhour Purge module extends the Drupal Purge module. The Purge module provides a standardised way of integrating third party CDNs, like Peakhour, with Drupal's native full page caching support. Drupal's native support is suitable for small websites, but has a number of drawbacks. These drawbacks include:

Doesn't support the Vary header.
Is served by PHP, so it doesn't scale well.
Runs on the same server as Drupal, so geographic latency is still an issue.

Peakhour's edge cache and delivery layer removes these issues before requests reach origin, and also adds image/content optimisation and website security.

Default Caching

Since version 8, Drupal has supported cache tags to provide efficient, targeted invalidation of content for anonymous browser sessions. In this context, anonymous means a user that does not have a Drupal Session cookie. Peakhour supports cache tags for all sites, a feature some competitors reserve for 'Enterprise' plans.

Cache tags are great, but another default setting is not. That setting is to add a:

Vary: Cookie

Header to the page response to make sure that logged-in users don't get cached pages. The Vary header informs a cache that different content may be served from origin based on the value in the Cookie header sent by the browser.

This is fine if you are using Drupal with no third party javascript libraries. If you do use third party libraries, it can render page caching close to useless. For example, drupal.org itself uses perimeterx for bot detection, which results in a unique session cookie being set on the very first request.

The first request to drupal.org results in a unique cookie being set by perimiterx

If you use Google analytics, Facebook, or any of a wide array of popular third party libraries, the same thing can happen.

This means only the very first request from the user could be served from a general page cache. Hit rates would be virtually zero.

Fix the Vary issue with Skip Cache on Cookie

Peakhour gives you a way to work around this. The first step is to disable the Vary: Cookie header. Then, to make sure any user with a Drupal Session bypasses the cache, use Peakhour's Skip Cache on Cookie feature. As soon as Drupal sets a session cookie, eg when someone logs in, Peakhour will pass requests through to the origin. Full instructions on how to do this are provided on our drupal module documentation

eCommerce Drupal sites

If you are running an ecommerce store, or some other type of site that might serve customised information on a page, for example a mini cart with cart count/information, then you will have to do custom development to continue caching pages. A workaround for a mini cart would be to make it load via Ajax or to use local browser storage, and Peakhour assists in making that happen.

Future features

Hopefully in the future Drupal will support setting its own cookie for varying the cache, in a similar manner to Magento 2. eg X-Drupal-Vary, this would allow Peakhour to store multiple versions of a page to serve to different users. For example, a user in Germany might get a version of a page in German with German currency.

IP Threat Intelligence

2022-07-15T13:00:00+10:00

Threat intelligence helps organisations make earlier decisions about cyber attacks. One of the most common forms of threat intelligence in cyber security is IP reputation lists. For example, a given IP address might have a poor reputation for spam, ddos attacks, malware, and several other categories. IP reputation lists often form a front line of defence in Web Application Firewalls and cyber security solutions.

How Peakhour uses IP threat intelligence

Peakhour supports threat intelligence across more than 20 categories, including:

Active DDoS attacks
Brute forcing
Active attackers
Computers infected with malware
Anonymous Proxies
Forum Spammers
TOR anonymous users
IPs with poor reputation
Unroutable and unassigned IPs
Robots and web scrapers
Datacenter
Hosting Providers
Crawlers
And more

Customers have access to all 10 lists, which can be enabled as blocklists or used as part of a custom firewall rule, rate limiting rule, or page rule. For example, you may want to disallow POSTs from forum spammers, rate limit proxies, and outright deny traffic from known brute-forcing IPs.

Creating a spammer can't post rule

How does Peakhour assemble these lists?

The IP reputation lists are sourced from third-party sources, including open source intelligence feeds (OSINT), commercial feeds, community feeds, and our own threat intelligence. IPs are categorised into our pre-defined lists and made available to the WAF and rules engine. Each list is re-evaluated and updated based on the data provider's update schedule; some are updated every minute.

Internally managed feeds include bot sources that are verified using reverse DNS lookups, PTR record lookups, and WHOIS verification (such as Facebook IPs). WAF hits across customers are consolidated and made available as the Active Attacker list, which is updated in near real time. Our Malware and C&C nodes lists are generated from various partnerships.

The Anonymous Proxies list contains known open proxies, services that relay traffic without authentication, whilst our targeted VPN list tracks known third-party VPN services.

IPs are fed back into our system for re-evaluation to help identify emerging behaviour within our customer data.

Data visualisation

Requests from IPs that match a blocklist are tagged with the lists they belong to. Firewall events are enriched with this information, providing visibility into security threats. This context helps you decide how to handle requests, whether they should be blocked, rate limited or observed.

Firewall events generated by reputation matches

Blocks generated by our reputation lists can also be viewed in our analytics section.

Firewall events generated by reputation matches

Future work

We are working on additional data sources to further refine and expand our lists. This includes further segregating our data centre lists and categorising IPs that appear on several lists. We are also introducing our threat research centre to discover possible threats and enrich data blocked only by our WAF.

IP threat intelligence adds another layer of security to a cyber defence system. Peakhour sources and maintains up-to-date threat intelligence, helping our clients better protect themselves against would-be attackers.

See how Peakhour's IP threat intelligence supports the first line of defence for your applications. Contact our team to discuss your security requirements.

CVE-2022-26134

2022-06-02T00:00:00+10:00

On June 2, 2022, Volexity announced active exploitation of Atlassian Confluence. The issue is a Remote Code Execution vulnerability via OGNL injection, tracked as CVE-2022-26134, and impacts all Confluence Server and Data Center versions greater than 1.3.0.

Atlassian has released its security advisory with patches and mitigation instructions.

Peakhour WAF clients are already protected. Since the vulnerability was announced on June 2nd, we have observed a 200% increase in OGNL-based exploit attempts.

Peakhour's Web Application Firewall helps protect applications against zero-day exploitation attempts such as CVE-2022-26134. Contact our team to secure your applications.

Intelligent Rate Limiting

2022-05-16T13:00:00+10:00

Rate limits protect web applications from clients making excessive requests. Peakhour.IO supports rate limits with flexible controls for selecting which clients are limited and which type of limit applies.

What kinds of attacks are stopped by rate limiting

When an application is protected with rate limiting, the main attack patterns are:

Brute force and enumeration attacks
Denial of Service (DoS) and Distributed Denial of Service (DDoS)
Site scraping
Vulnerability scanners

What else can rate limiting protect

Public APIs and authenticated APIs can be abused or misused. Sensible rate limit policies on these endpoints can reduce attack traffic and help maintain service availability. Rate limiting can protect:

APIs
Overzealous 'good bots'

How does it work?

Rate limiting focuses on a connecting client and their IP address. The following measures can be used to track client requests for rate limiting:

Concurrent connections
Connections per interval
Hits per interval
HTTP 4xx responses per interval
HTTP 5xx responses per interval
Custom criteria

How granular can rate limiting be?

Using wirefilter rules, rate limiting can identify clients from both the HTTP request and response, allowing rate limits to be separated by endpoint or behaviour. For example, the URL /api can be rate limited separately from the /login endpoint. Rate limits can also be set on response codes; for example, the endpoint /search can be protected from scraping by rate limiting clients with excessive 4xx response codes.

What types of criteria can be used to define rate limits?

Rate limits can include any information defined in an HTTP request and response, including:

IP address
URL
Query string
Headers
Response codes
GeoIP information such as ASN or country code
Parsed user agent information allowing different rules for search engines vs generic 'bots'
Metadata we make available from our BOT protection service

Defining your rate limits

Picking sensible rate limits is difficult without adequate analytics on how the web application is typically used. The Peakhour dashboard includes rate-based analytics to help with setup.

Peakhour's Application Security Platform combines high-performance delivery and cache capabilities with security controls for applications and APIs. It maintains caching performance while applying advanced threat protection. Contact our team to discuss how rate limiting can improve application performance and security posture.

Rate limiting

2022-05-16T13:00:00+10:00

Rate limits are a useful control for protecting a web application from abuse. When setting them for a web application, the key elements to consider are:

What endpoints on the web application require protecting?
Do different endpoints require separate handling?
What is the normal request rate for the entire application over a time period?
How many concurrent connections are typically used by your clients?
What errors does your API endpoint return in response to requests?

Before setting those policies, it helps to understand how rate limits protect an application from abuse or misuse, the types of attacks they can reduce, and how the rate limiting algorithm makes decisions.

What kinds of attacks are stopped by rate limiting?

When protecting an application with rate limiting, common attack scenarios include:

Brute force and enumeration attacks
Denial of Service (DoS) and Distributed Denial of Service (DDoS)
Site scraping

What else can rate limiting protect?

Public APIs and authenticated APIs can be subject to both abuse and misuse. Sensible rate limit policies can be applied on these endpoints to help prevent attacks and maintain service availability. Rate limiting can help protect these endpoints.

How does rate limiting work with user logins?

A well designed web application should allow only a limited number of failed login attempts before locking an account and requiring a password reset. This is designed to protect against brute force attacks against an account. Bots commonly attempt to brute force logins to WordPress and other popular web applications. Determined attackers can also attempt to brute force API login endpoints.

Rate limiting on a login page can be applied to the IP address of a user attempting to log in. By rate limiting by IP address, you can limit both password brute force attacks and simpler username enumeration attempts.

Using Peakhour.IO rate limiting, responses to requests can be monitored and IPs blocked for administrator-defined periods. This saves origin server resources and stops repeated attempts before they reach the application.

How could API rate limiting work?

APIs are ubiquitous across the modern web. Single Page Applications (SPAs) can be built almost entirely on REST or GraphQL APIs, while legacy applications often use form submits. Even when browsing this blog, you have consumed a range of APIs.

Because APIs are often publicly available, rate limits are commonly used to reduce abuse. Rate limiting for APIs can protect against malicious attacks. An attacker could script a bot to perform many API calls and make the service unavailable for other users, causing unplanned downtime - a layer 7 DoS or DDoS attack.

APIs

Public and private APIs can be subject to abuse or misuse. Public APIs are discoverable by anyone and can be scripted for data mining or attacks. Rate limiting these endpoints based on fair use policies is commonplace. Keeping track of this within an endpoint can be expensive, so handling it through Peakhour can offload that work from developers.

Overzealous 'good bots'

Peakhour has seen websites where up to 65% of requests come from automated bots. These bots are typically indiscriminate when mining information, and they do not carry the operational cost when your site slows down or fails. Rate limiting good bots separately from your main users helps ensure these crawlers do not stop your site from generating revenue.

How is rate limiting implemented?

Rate limiting is typically implemented using several common methods:

Fixed window

Window-based rate limiting is the simplest to understand. Fixed window limits are easy to define, such as 5,000 requests per 60 minutes. Fixed window rate limiting is subject to spikes at the edges of the window. For example, 5,000 requests in the first 5 minutes of the window may overwhelm a service.

Sliding window

A sliding window keeps much of the simplicity of a fixed window, but uses a rolling window. This allows bursts to be smoothed.

Token bucket

A token bucket is an algorithm where tokens are placed into a fixed-capacity bucket. Tokens could be defined as bytes transferred or hits to an API. When a request is considered for rate limiting, tokens are removed from the bucket. If the bucket has a sufficient quantity of tokens, the request can proceed. If there are insufficient tokens, the request is considered to be non-conforming. Non-conforming requests are dropped.

Leaky bucket

Leaky buckets are a mirror image of token buckets. Instead of removing tokens from a bucket, tokens are added to a bucket. Tokens are removed from the bucket (leaks) at a fixed rate. When a request is considered for rate limiting, it is compared to the number of tokens in the bucket. If the bucket is full, the request is considered non-conforming and is dropped.

If rate limiting is something you need to do to protect and secure your website, reach out to see how we can help.

Learn how Peakhour's Application Security Platform can improve your application's performance and security. Contact our team to get started.

Request collapsing

2022-05-16T11:00:00+10:00

Request collapsing protects busy origin servers that serve changing content. On a high traffic site, a cache miss after content expires can amplify one expired resource into many simultaneous origin requests. This behaviour is commonly called a cache stampede or dog-piling.

When request collapsing is enabled, only a single request is sent to an origin server for a given resource, then the resulting body is used to satisfy pending requests.

This can stop a popular cached resource from causing a flood of requests to an origin server when it expires. On high traffic sites, enabling the feature for the right resources can smooth request volume and traffic to origin servers.

How it works

Request collapsing is implemented internally using cache keys and queues. Cache keys are used as keys to a map, with client requests tracked using a queue. Secondary response keys are then used to match waiting client requests to origin responses. Matching requests can then be fulfilled using the same response.

Failed requests are retried in the same manner.

If a response to an active request is marked as private with Cache-Control: private or Set-Cookie, then all queued and future matching requests will go directly to the origin without trying to match them.

This implementation allows Peakhour to serialise requests to an origin, so it's important to enable the feature only on resources that you know will be cacheable, either through cache-control headers or Peakhour configuration.

How do you know its working?

Request collapsing can be verified with Debug enabled and the cache-status header in the response. A collapsed request looks like the example below, with 'collapsed' at the end.

cache-status: peakhour.io; fwd=uri-miss; key="https://website.com/home-eco.jpg"; ttl=86400; collapsed

How its used in practice?

Image optimisation

Peakhour.IO uses request collapsing internally for image transforms. The feature ensures we only transform a single image when a resource expires on the edge, reducing latency sensitive image transformation work, client transform costs and avoidable delays for end users.

Dynamic page caching

Request collapsing is a good fit when enabling caching of expensive dynamically written pages. Peakhour.IO can cache server heavy WordPress, Magento, PrestaShop, Drupal and other platforms via our caching plugin. The plugin keeps the CDN in sync by notifying us when content changes.

Content still needs to change during busy periods such as sales or item purchases. During these periods servers can be overwhelmed when pages incur a cache miss. Request collapsing can help smooth out this traffic and maintain response times for users.

Cdn-Cache-Control

2022-02-28T13:00:00+11:00

Caching headers are easy to get wrong. Public resources may be cached in one layer, while the server configuration prevents an otherwise cacheable resource from being stored where you expect.

Controlling caching without a service like Peakhour usually means working directly with Cache-Control headers. This header has a wide range of fields and directives. Each one tells downstream clients (e.g., proxies, shared caches, and end browsers) how to handle caching for a particular resource.

Getting this right can be complicated, and it can become brittle when web server configuration also affects the response.

Enter CDN-Cache-Control

CDN-Cache-Control is a recently proposed header specified in https://datatracker.ietf.org/doc/html/draft-cdn-control-header-01

The draft RFC states:

This specification defines a convention for HTTP response header
fields that allow directives controlling caching to be targeted at
specific caches or classes of caches.  It also defines one such
header field, targeted at [Content Delivery Network](/learning/cdn/) (CDN) caches.

What does this mean in practice? Imagine a Magento application where pages should be cacheable by a shared cache but not by a browser. A Cache-Control header could look like:

Cache-Control: max-age=0, s-max-age=600

This tells browser caches not to reuse the response, while shared caches may cache it for 600 seconds.

What if the application does not want every shared cache to store the resource, because the application already sends purges to the cache when content changes?

Cache-Control does not give you that separation. The header above enables any shared cache to store the resource for the specified time. With CDN-Cache-Control, the application could instead send:

Cache-Control: max-age=0, s-max-age=60
CDN-Cache-Control: max-age=3600

This tells the browser not to cache the page, allows a shared cache to keep the page for 60s, and allows the CDN to keep it for one hour.

Targeted CDN-Cache-Control

What if you need to target a specific CDN only? Use the provider's targeted CDN-Cache-Control header.

For example, Peakhour-CDN-Cache-Control instructs Peakhour only to cache the resource. Other CDNs in the request path will not honour this header.

Header format

Examples

The following header fields instruct a CDN cache to consider the response fresh for 600 seconds, other shared caches for 120 seconds, and any remaining caches for 60 seconds:

Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=600

These header fields instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches are prevented from storing it:

Cache-Control: no-store
CDN-Cache-Control: max-age=600

Because CDN-Cache-Control is not present, this header field prevent all caches from storing the response:

Cache-Control: no-store

Whereas these prevent all caches except CDN caches from storing the response:

Cache-Control: no-store
CDN-Cache-Control: none

(note that 'none' is not a registered cache directive; it is used here to avoid sending a header field with an empty value, because such a header might not be preserved in all cases).

Cache-Status

2022-02-25T13:00:00+11:00

Diagnosing CDN caching can be complex, with multiple cache layers, Origin Shielding, and local caching. Understanding how these layers interact can mean spending weeks working through RFCs for the finer details of ETag, Cache-Control, and Last-Modified headers - before you even account for advanced controls that override them.

When you have a problem, or are trying to optimise caching, the first thing you need is visibility into how a request was handled.

This is where the new Cache-Status header helps. The new draft RFC, RFC draft-ietf-httpbis-cache-header-08, aims to:

  aide debugging by standardising the format of various non-standard debug headers
  used by major CDN providers. The semantics of these headers are often unclear and vary
  between implementations.

The draft RFC proposes a new header, Cache-Status, with a uniform format for showing how multiple caching providers interact and handle a request. The Cache-Status header forms a list. Each member of the list represents a cache that has handled the request, and the last member belongs to the cache that most recently served the user. The header is only applicable to responses directly generated by an origin server. Each member can add a parameter indicating how it handled the request.

A Cache-Status header looks like this:

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; fwd=uri-miss;

It is formatted and labelled, with each cache in the line separated in list format by a ','.

The format of the Cache-Status header is a list comprising of the following possible parameters:

hit = boolean
fwd = (bypass, method, uri-miss, vary-miss, request, stale, partial)
fwd-status = integer
ttl = integer
stored = boolean
collapsed = boolean
key = string
detail = token / string

What the parameters mean

Hit

The hit parameter signifies that a request was satisfied by the cache. It is a boolean parameter meaning that its presence indicates a cache hit.

For example:

  Cache-Status: Peakhour.IO; hit

Fwd

The Fwd parameter indicates when a response was forwarded to an origin server - and why. The Fwd parameter contains one of the following arguments:

bypass - The cache was configured to not handle this request
method - The request method's semantics require the request to be forwarded
uri-miss - The cache did not contain any responses that matched the request URI
vary-miss - The cache contained a response that matched the request URI, but could not select a response based upon this request's headers and stored Vary headers.
miss - The cache did not contain any responses that could be used to satisfy this request (to be used when an implementation cannot distinguish between uri-miss and vary-miss)
request - The cache was able to select a fresh response for the request, but the request's semantics (e.g., Cache-Control request directives) did not allow its use
stale - The cache was able to select a response for the request, but it was stale
partial - The cache was able to select a partial response for the request, but it did not contain all of the requested ranges (or the request was for the complete response)

For example:

  Cache-Status: Peakhour.IO; fwd=uri-miss

Fwd-status

The fwd-status parameter indicates the status code the next hop returned in response to the request. It is only meaningful when "fwd" is present. For example, a complete miss would look like fwd=uri-miss and the HTTP status code of the downstream response would be supplied in the fwd-status:

The following example shows that the cache did not satisfy the request and that the downstream server indicated an HTTP 304 response - HTTP Not Modified.

  Cache-Status: Peakhour.IO; fwd=uri-miss; fwd-status=304

ttl

Each cache item is associated with a lifetime, referred to as the Time To Live (TTL). A TTL is in seconds and indicates the remaining freshness of the resource. This value is calculated by the cache.

For example, a cache hit showing that the resource has a freshness of 376 seconds.

  Cache-Status: ExampleCache; hit; ttl=376

Another example shows a cache hit with negative freshness - a stale resource.

  Cache-Status: ExampleCache; hit; ttl=-412

stored

Indicates whether the received response was stored by the cache. This example shows a cache miss and the cache storing the response for the next hit.

  Cache-Status: ExampleCache; fwd=uri-miss; stored;

collapsed

Indicates whether the received response was collapsed with another request.

key

The key is the lookup index into a cache. Cache keys convey a representation of how the cache will look up the resource used for the response. The cache key is implementation-specific.

This example shows a cache hit, the cache key and secondary key, and the remaining TTL of the resource.

  cache-status: peakhour.io; hit; key="https://example.com/calendar.css"; secondary-key="encoding::gzip"; ttl=30674859

detail

Allows additional implementation-specific information not captured by other parameters.

Multiple layers of caching

The header allows multiple layers of caching. For example, a global CDN may sit in front of a local varnish server. Each cache appends its cache-status to the header, so the last item is the closest cache to the actual application and the first item is the closest cache to the accessing user.

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; hit; ttl=545

Security

There are security implications to consider with this header. Making it public gives an attacker insight into how the cache is configured, which may help them bypass a cache entirely and access an origin server directly. Cache header security is provider-specific, but could involve enabling it only when required, restricting access to specific IP addresses, or requiring a custom request header to trigger the cache-status header.

Peakhour.IO regularly sees automated scans sending other providers' headers to trigger a cache-status header response.

Conclusion

The Cache-Status header gives clear insight into how cache layers interact on a website. It provides a standardised format for showing how a cache handled a request and allows multiple caches to report their part of the request path.

Peakhour fully supports this new header, and it can be enabled/disabled and secured in the dashboard.

Website Optimisation

2021-05-17T13:00:00+10:00

We've previously covered ways to find resources that block rendering in a browser. Now we'll cover techniques for loading those resources without letting them block rendering. Before making changes, always run some website performance tests using your favourite testing tool to get a baseline so you can measure any improvements. We recommend testing with webpagetest.org.

Before we get into the techniques, it is worth defining the problem.

What is a Blocking Resource?

When a browser loads a page from a website it reads the HTML markup from top to bottom. If it encounters a CSS or JavaScript file while it's reading, the browser stops while it downloads and parses that file. While the browser is waiting it can’t process the rest of the HTML or display content to the user. Rendering is blocked.

Why is this a problem?

It would not be a problem if every page included only the information required to display it. Most websites do not work that way. They are typically built using prebuilt themes and third-party libraries that can contain lots of CSS and JavaScript. Only a tiny fraction of this code might be used on the current page, or it might only be needed for ‘below the fold’ content, or on another page of the site. Note: Below the fold means the content of a page that doesn't initially fit on the screen. Any unnecessary information keeps the browser blocked for longer than needed, slowing the load experience for the user.

CSS and JavaScript files are usually at the very top of the HTML document before any of the content. This means they have to be downloaded and parsed before the browser can display anything. Even a website that has extremely fast server response times can still seem very slow if it has blocking resources.

Take a simple example: a website that includes a live chat widget. The JavaScript for the widget is included at the very top of the page in the section. The browser has to stop, download, and parse the CSS and JavaScript for the widget (usually downloaded from a third-party domain) before any content is displayed to the user. The chat widget could appear after the rest of the content without affecting the user experience.

Things you should always be doing

Before targeting CSS- or JavaScript-specific techniques, cover the basics for both.

1. Minify all files

Minification is the removal of all non-essential characters in a file, e.g. irrelevant whitespace and code comments. It can make a substantial difference to the file size.

2. Ensure compression is enabled on your server

Make sure your server is configured to use either gzip or Brotli compression when serving CSS and JavaScript.

3. Self host files

If the CSS or JavaScript is on a third-party domain, i.e. not the domain name your website is on, you should strongly consider uploading the file to your website and serving it from your domain. This might not always be possible, but if it is it eliminates the overhead of the browser opening a connection to another domain, and it removes the possibility that the third party is not compressing, minifying, or using HTTP/2.

After the implementation of cache partitioning in the major browsers, there is no longer any potential advantage to using third-party CDNs to serve assets like JavaScript, fonts, or CSS. Make a copy on your server and host them on your domain.

4. If you can't self host then preconnect to third party domains

If external assets are on third-party domains, and you absolutely can't self host them, then you can improve loading by telling the browser to preconnect to the third-party domain.

Using preconnect tells the browser to establish an early connection to the domain before it has discovered the asset while reading the HTML. Use preconnect in the head of the HTML, e.g.:

Establishing early connections can shave 100-500ms off third-party load times, which is worth having. You should only use preconnect on critical third-party resources. For all the others you can use dns-prefetch, e.g.:

This tells the browser to perform DNS resolution of the domain early, which is similar to looking up a phone number in the phone book. Pre-resolving DNS can save 20-120ms. That sounds like small numbers, but remember, differences as small as 100ms can have large measurable impacts on conversion rates.

5. Select only what you need from frameworks

It is common for users of frameworks like Bootstrap or jQuery UI to only use a fraction of the functionality provided. If this is you, then the first step is to cut out what you're not using. Bootstrap and jQuery UI are modular, you can either download everything in one bundle, or you can break it up to take just the bits you are using.

These points will ensure that blocking resources are downloaded as quickly as possible. Now we can discuss some specific techniques that will help minimise blocking and get your page displaying quickly. Please be aware that this is not an exhaustive overview, but these techniques will probably get you 90% of the benefit with 10% of the work. Getting that last 10% requires deeper technical work. If you want to go there, Google’s web.dev website is a good resource.

Techniques for Optimising Blocking Resources

Javascript

There are a few different techniques for optimising the loading of JavaScript. First, let's look at the default loading behaviour. Credit for the images goes to Daniel Imms and his website Growing with the web. As stated earlier, the default behaviour is to stop parsing the HTML document when a script is encountered, download the script and execute it.

Now let's look at how we can change this behaviour.

1. Moving scripts to the very bottom of the page, right before the closing tag.

This is the original optimisation technique, before defer and async were introduced. It works by moving scripts to the very end of the HTML document, where they are downloaded and parsed after everything else.

In our example in the previous section, the chat widget would now load and pop up after the rest of the content has been displayed to the user.

2. Defer and Async

<script> tags that have a src attribute can be marked as either deferred defer, or asynchronous async, or both. For example:

<script src=”https://www.somedomain.com/somescript.js” defer async>

This tells the browser to change the script loading behaviour.

Defer

Defer was the original browser-based support for improved JavaScript loading. It tells the browser to download the script asynchronously while it keeps reading the HTML, and then execute it once it has finished reading the whole HTML document. Here's the loading behaviour with defer enabled.

As you can see the script no longer blocks the browser from doing anything else while downloading. Defer preserves script execution order. This can be very important if a script depends on one declared earlier in the page.

As noted earlier, you can only mark <script> tags that have a src attribute as deferred. Inline scripts, e.g.:

<script type="text/javascript">
    console.log("Hi I'm some inline script!");
</script>

Any attempt to defer that inline block will simply be ignored. This can cause problems if you have inline script scattered through your code and rely on a deferred third-party library, e.g. jQuery. There are two potential solutions if you can't simply move the code to the bottom of the page:

Move each inline code block into its own file and include it using the src attribute so you can defer it.
Or you can try declaring the block as a module. Test this carefully, as browser support may be limited and it also places the script into strict mode, which may break it.

Async

The async attribute tells the browser to download the script now and execute it as soon as it has finished. Like defer, the downloading is done asynchronously. Unlike defer, the script is executed as soon as it is downloaded. Here is the behaviour:

As you can see the browser doesn't stop while downloading, but does pause once downloading is finished so it can execute the script. async doesn't preserve script order, which can potentially cause issues when there are script dependencies.

All three methods have pros and cons. Defer and async result in faster page loads overall as the scripts are downloaded while the browser reads the HTML. Moving the script to the bottom of the page shifts the sequence around.

Your first option should be to defer all scripts. Then, if some above the fold content is taking too long because it has a JavaScript dependency, e.g. a carousel in the hero section, you can try making the necessary scripts async instead.

Optimising CSS

The key to fast CSS loading is to prioritise the CSS needed for the immediate above the fold content and then defer the rest. Many articles advocate extracting the precise CSS and then including it inline in the HTML document in a style block, i.e.:

<style type="text/css">
     .accordion-btn {background-color: #ADD8E6;color: #444;cursor: pointer;padding: 18px;width: 100%;border: none;text-align: left;outline: none;font-size: 15px;transition: 0.4s;}.container {padding: 0 18px;display: none;background-color: white;overflow: hidden;}h1 {word-spacing: 5px;color: blue;font-weight: bold;text-align: center;}
</style>

However, you have to do this on every possible landing page where the critical CSS might be different per page. Inlining CSS also adds to the download size for each page, and forces the browser to reparse the CSS rules for every load rather than being able to use a cached file for repeat views.

We advocate for putting the critical CSS into its own file and loading that normally, and then deferring any other non critical CSS. Identifying the critical CSS is the main task. The first thing to do is to look at the included CSS on your website and see if you can identify any non-core files. You can defer those files using this pattern:

<link as="style" href="/styles.css" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

The as="style" lets the browser download the file asynchronously. The onload changes the type to stylesheet, telling the browser to parse the file. Finally, we include a <noscript> to enable the CSS to load normally if JavaScript is turned off.

Once you've deferred non-core CSS files you can still check whether your core ones contain lots of unused rules. Google Chrome's coverage tool can show unused rules, but it doesn’t let you easily export used and unused rules. You have to go through it yourself, programmatically, or use a third-party tool to make two files: the critical CSS, and the non-critical CSS which can be deferred.

Conclusion

Eliminating, or at least minimising, blocking resources can be one of the biggest improvements to user experience you can make to your site. With Google Web Vitals being introduced soon as a search signal, it is important to make sure your website loads as fast as possible so your users stay longer and buy more from your site.

Secure Dynamic Content Caching

2021-02-09T13:00:00+11:00

Last time we covered how slow server performance can have a negative, sometimes very negative, effect on your website load times. The causes of slow server responses are many and varied, and not necessarily tied to the server specification. Diagnosing and dealing with them can be difficult, time-consuming, and costly. One practical way to reduce the impact is to look for opportunities to cache dynamic content.

What is Dynamic Content?

Content delivered by a web server is categorised as either static or dynamic. Static content is the same for every user and is delivered without being generated or processed by the server. Static content is fast to deliver and does not tax a server's resources.

Dynamic content is generated by the server for every request. That can involve querying a database several times and executing a large amount of code. Depending on the work required to generate the result, dynamic content can be resource-heavy.

Traditionally CDNs have only cached and served the static content of websites, usually the images, CSS files, Javascript files, etc. They required the webmaster to upload these resources to the CDN's servers and to modify their website source HTML to access the resources from the CDN. For example,

https://www.yourdomain.com/image1.jpg

would be changed to be something like

https://cdn.yourdomain.com/image1.jpg

Modern CDNs, like Peakhour, act as a reverse proxy{:target="learning"}, which means they sit between the end user and the website's origin server. This enables them to transparently cache a copy of anything cacheable being returned by the origin server. By transparently caching, we mean the caching happens without changes to the original website.

Full Page Caching

Full Page Caching (FPC) is where the actual HTML document of a web page is cached.

Most websites are built using a Content Management System (CMS). Widely used CMS platforms are Wordpress, Drupal, Magento, etc. By default, every time a page is viewed the CMS has to generate the content from its database. Most of the time this generation is unnecessary. The content is either the same for every user, changes very rarely, or only differs by a small amount of personalisation. In each case it is possible to perform Full Page Caching to improve page load times and to cut server load. Let's have a look at the difference full page caching makes to one of our clients, Magento 2 store savvysupporter.com.au.

Main document load before caching: 2.07s

Main document load after caching: 82ms!!

Caching the page has cut nearly 2 whole seconds from the download time. That matters: load differences as small as 100 milliseconds have measurable impacts on website conversion rates. With a Magento 2 website, it's possible to cache all full pages outside the checkout process and the customer/admin area. This can reduce load on the origin in the order of 60-70% and make the customer experience much better.

API (Application Programming Interface) Caching

Many API calls used by web applications are for the retrieval of information to be displayed to the end user. Examples include:

Pricing and product information
Form auto completion
Product catalogue searches

These are all strong candidates for caching, reducing load on your server and making websites faster.

Handling Stale Information

The one potential drawback of caching dynamic content is the possibility of returning out of date information to the end user. There are two strategies to deal with this risk.

Setting a short Time To Live (TTL) with the caching provider. By only keeping content cached for a short time, e.g. 5 minutes, the cache will never be without up to date information for very long. Cached content will expire and the new version fetched from the origin server. The drawback with this method is that, unless your site is very busy, cache hit rates can be low, users can frequently get slow loading pages, and stale content is still possible. However, for very busy sites this can be an effective, low-overhead strategy.
Flushing content when it changes. This strategy sets very long time to live in the cache, months or even years. When content is updated the cache is informed and the new version fetched. This notification of new content could happen manually or, in the case of some CMSs, automatically. For example, Magento 2 and Drupal 8 have a built in framework for integrating caching providers to handle flushing when content/stock changes. This strategy ensures very high hit rates, but unless the flushing is accurate and fast it can result in stale content.

Security-Performance Integration

Modern Application Security platforms like Peakhour combine caching with comprehensive security controls so performance optimisation does not weaken application protection:

Edge Security Processing

WAF/WAAP Integration: Security rules are processed at the edge before content is cached, ensuring malicious requests never reach your origin
Bot Management: Caching adapts based on traffic classification - legitimate users benefit from cached content whilst malicious bots are filtered out
API Protection: Secure caching of API responses with appropriate security headers and access controls

Cache Security Controls

Secure Purging: Authorised cache invalidation through secure API endpoints with proper authentication
Content Classification: Different caching policies for public, authenticated, and sensitive content
Header Security: Automatic injection of security headers (CSP, HSTS, etc.) into cached responses

Conclusion

Secure dynamic content caching works best when performance optimisation and application security are handled together. By implementing caching within an Application Security Platform, organisations can achieve:

Superior Performance: Dramatic improvements in load times and server capacity
Enhanced Security: Protection against threats at the edge before they impact cached content
Operational Efficiency: Reduced origin server load whilst maintaining security posture
Cost Optimisation: Lower infrastructure costs through intelligent caching and edge processing

For modern applications and APIs, secure dynamic caching should form part of the performance and security strategy, improving the user experience whilst maintaining threat protection.

Common Issues That Affect Website Performance

2020-11-30T13:00:00+11:00

Our last three website performance articles covered the why and how of testing website performance, and introduced our two favourite performance testing tools, WebPageTest.org, and Lighthouse. This article covers the common causes of slow loading times, and how to spot them using the same testing tools.

1. Latency

Latency is the time it takes for a request from a client's browser to traverse the internet to reach the website server. A number of factors affect latency, with physical distance usually the main one. Data on the internet travels at the speed of light, so distance may not sound like a major concern. In practice, small delays compound quickly. Here are some realistic examples of request latency:

Sydney to Melbourne: 5ms
Sydney to Perth: 25ms
Sydney to San Francisco: 75ms

NOTE: Common tools used to determine latency between servers are Ping and Traceroute, they will provide you with Request Round Trip (RTT) latency, ie the time it takes for a request to get to the server and back. So 2 times the numbers above.

Here is an example of latency during a webpage load. We'll ignore internet speed and any potential network congestion, and focus only on latency. We'll request a website hosted in San Francisco from a browser located in Sydney.

Browser establishes a TLS (Secure) connection with server, 6 * 75ms = 450ms
Browser sends HTTP Request for the main page = 75ms
Server sends HTTP Response containing page which specifies 10 assets = 75ms
Browser requests the 10 additional assets = 75ms
Server responds with 10 assets 10 * 75 = 750ms

In this example, a website with 10 assets, which is a fairly simple page, has nearly 1.5s added to the page load time through latency alone. If the same site was hosted in Melbourne, the time due to latency would be just 95ms. To solve this problem you would either move your website server closer to your customers, or use Peakhour Edge caching.

How do I check for latency problems?

If there is a long distance between your server and your customers, eg your website is hosted in the US and your customers are in Australia, page load times will be significantly affected by latency. A good tool for indicative RTT times between cities is provided by wonder network. Webpagetest.org also provides a Traceroute tool which can give you indicative RTT times between its testing locations and your website.

2. Old version of HTTP

Browsers communicate with websites using a protocol called HTTP. The protocol formalises the steps needed to connect a browser and server so a webpage can be downloaded. Since the introduction of the web, HTTP has gone through a number of revisions. The currently widely adopted version is HTTP/2.

Even though HTTP/2 was introduced over 5 years ago, over 50% of websites are still only served over HTTP/1.1. Without getting too technical, HTTP/2 has significant advantages over older versions because it reduces the number of connections between a browser and server, and transfers information more efficiently.

Serving your website over HTTP/2 can improve page load times by 10-15%.

How do I identify the version of HTTP my website is served over?

Run a performance test of your website using WebPageTest.org, once complete click on the 'Details' link in the report navigation. You will see the Waterfall View. Click on the first request, circled below in this image:

It will bring up the request details including the Protocol used, circled below:

3. Slow Server Performance

A slow initial response from the server is a common cause of poor page load performance. The majority of websites are built using some sort of Content Management System (CMS), eg Wordpress, Magento, Drupal, Shopify, to name a few. By default, a CMS has to construct a page each time a browser requests it, even when the content has not changed. That process can involve executing a lot of code and querying a database several times before returning the HTML that forms the page.

The specification of your server, the number of CMS plugins, the state of your database, and the number of simultaneous users can all affect the response time. A slow server may take 10s or more to respond, while even a fast server can still take over a second to generate a page. That is enough to pretty much make you fail the new Core Web Vitals guidelines before you even get started.

How do I check for slow server performance?

Server performance can be checked from the waterfall view in WebPageTest.org. The time taken to download the main document indicates whether server performance is affecting your page load. Here's an example:

The total time taken to download the main document here is over 1.3s. That is not too bad, but it has already used up over half the 2.5s required to achieve 'Good' for the Largest Contentful Paint (LCP) metric in web vitals

4. Page Weight

Even though internet speeds are getting faster, they are still a limiting factor to how fast a browser can download a page. If the requested page and the associated resources, eg images, javascript, CSS, are large files, it will take longer for the browser to download all the required information to display a page. Unoptimised images are a common culprit for inflating page weight. Unoptimised CMS themes and third party javascript libraries are another.

How do I check my page weight?

WebPageTest.org reports the page weight in the far right of its summary, circled here:

You should be aiming for 2mb or less. This particular website is more than a little obese, coming in at around 30mb... WebPageTest also has a section called 'Content Breakdown' which shows where the weight is, ie in images, javascript, etc.

Over 27mb in images is what's weighing down this page.

Peakhour also has a pageweight tool that you can run for a page on your website and receive a full optimisation report for the images on the page, along with downloadable optimised images.

5. Blocking Resources

Resources that can block a page include CSS and javascript. When the main HTML page is downloaded and parsed, the browser will not render anything to the screen until the CSS and javascript files that are referenced are downloaded and parsed. If your website includes a lot of CSS and javascript, which is not uncommon for pre built themes for CMS's like Wordpress and Magento, the downloading and parsing of these files can delay the browser from showing any content for several seconds.

How do I identify blocking resources?

The easiest way to check is to use Google Lighthouse) to identify them for you. After running the report, go to the opportunities section and expand the 'Eliminate render-blocking resources' section to see what it finds.

6. Third Party Resources

It is very common for websites to include third party resources. These are files that have to be fetched from a domain/url other than the one that the page is being requested on. Eg if you are requesting www.domain.com.au, it might include a resource from a third party, eg www.anotherdomain.com.au. Common third party resources might be analytics scripts (eg Google analytics), marketing tools (eg Mailchimp)

This forces the browser to open another connection to the third party. The time taken to do this, combined with the possibility that the third party might be slow to respond (see latency and server performance above), can often ruin load times. If the resource in question is also a blocking resource the problem is compounded.

Spotting a problem with third party resources

WebPageTest has a section 'Domains' which displays all the individual domains that the browser connected to when loading the page:

If your website is requesting resources from more than 10 separate domains then you should consider why that is happening and whether they are necessary. If you are using external CDNs to load javascript or CSS then you should probably move them onto your domain.

Social sharing plugins are notorious for pulling in a lot of resources from external domains. You should replace any share buttons using external scripts with simple static buttons. It is simple to do, and your website will be much smaller and faster. By using the javascript shares that social sites prescribe, you are slowing down your website and allowing third parties to track your clients across the internet.

Conclusion

There are many factors that can slow down your website, drive away customers, and cost you money. You have to regularly test your website to check for issues and address them when you find them. Next we'll cover what you can do to fix the issues we've mentioned here.

Test Your Website Performance With Google Lighthouse

2020-09-14T13:00:00+10:00

Today we're introducing our other favourite tool for testing website performance: Google Lighthouse (from here we'll just call it Lighthouse). Lighthouse measures page experience across accessibility, performance, SEO, and Progressive Web Apps for desktop and mobile devices.

Lighthouse is the engine behind web.dev/measure and PageSpeed Insights. It is also available in Chrome DevTools, via npm, or as a browser extension in Chrome and Firefox. At time of writing Lighthouse is up to version 6, which introduced Web Vitals as the basis for scoring. If you are unsure which version of the tool you are using, then scroll right to the bottom of the report it generates where it will state the version.

Lighthouse generates its report by simulating a specific device and network speed, rather than running at the full speed of your computer. That matters because speed issues are more noticeable on slower devices, and users are not all on newer devices or fast internet connections. You should test for a good load experience across that range. The current simulated mobile device is a Moto G4 on a ~1.5 megabit connection. For reference, it would take over 5s to download 1mb of data at this speed. If your page weight is typical, ie over 2.5mb, you should not expect a strong score.

How to use Google Lighthouse

There are two ways you can run a Google Lighthouse report:

In your local browser;
Online via web.dev/measure or PageSpeed Insights.

We recommend running Google Lighthouse in your local browser because the online versions operate out of the US. If your website and customers are elsewhere, that extra network latency can pull the score down.

Here we'll focus on running Lighthouse from within Chrome DevTools. To do this, click on the three vertical dots in the top right-hand corner, then select 'More Tools', then 'Developer Tools'.

The developer tools will then be displayed. Along the top of the tools window are a number of tabs. Select the 'Lighthouse' tab.

Since we're only interested in performance, make sure only the Performance category is ticked. You also want to make sure 'Clear storage' is ticked (in the top left) to simulate a first load of your site. Finally, choose the device you want to report on, mobile or desktop, and click 'Generate report'.

While the report is being generated, avoid doing anything else on your computer, and don't leave it busy with background tasks. Otherwise, the score can be affected.

Understanding the Score

Once the report has finished you'll see a performance summary, like this mobile one we ran on Peakhour.io while we were developing the website:

Scoring in version 6 is based on Google's web vitals, which are metrics that indicate a good user experience, and Webpagetest's speed index, which measures visual loading performance. Each metric is colour coded as good, ok, or bad. If the measurement is good you get a green circle to the left, if it's ok you get an orange square, if it is bad you get a red triangle.

Each raw metric (the number listed in the report) is compared to real website performance data sourced from the HTTP archive and converted into a score out of 100. This is done by grading the reference data on a curve, so if your website performs in the top 8% of websites, it gets a score of 90. Similarly, if it scores in the top 25%, it gets a score of 50. If you are interested in the technical details, Google has in-depth explanations of the scoring at web.dev

Each metric is assigned a weight, and the scores are tallied into one overall number based on the weighting. Here is a breakdown of the test we just ran (in the screen shot above), obtained by clicking on the 'See Calculator' link between the Metrics section and the screen shots:

Score Variability

79 is a good result for a mobile device. However, we ran it several times and obtained scores between 60 on the low end and 85 on the high end. Scores can fluctuate widely, even when testing on the same device repeatedly. Reasons for this include:

Small differences in internet performance.
Your computer CPU load when performing the test.
Web server variability.

Again, Google has in-depth documentation around what might be causing this.

Opportunities

If your site loads slowly then Lighthouse will list addressable reasons in the opportunities section of the report.

This is the part we generally find most useful. It identifies items that slow the initial load and items that affect the rendering of a website once it is downloaded. A page can be downloaded very quickly, but the end user still sees a slow site because CSS and Javascript are blocking rendering. This is a common problem in Wordpress and Magento themes. These themes include large amounts of third party code that ultimately never gets used for a particular site, but which the browser still has to download and parse before it can display anything.

In this case, the main bottleneck appears to be a font loaded from Google Fonts. This is delaying the rendering of our page by 1.3s.

Diagnostics

The diagnostics section provides additional information you can use to improve load times.

Here we have a few small problems, mainly associated with the development status of our site.

web.dev and PageSpeed Insights

If you do choose to run your report online, we recommend using PageSpeed Insights.

In addition to the generated report, PageSpeed Insights also shows you Field Data for the page you are testing, and an Origin Summary for all pages on the website.

This is real-world data gathered from Chrome users who have opted in to allowing Google to gather their data. If your site isn't very busy then Google might not have any data to share. It is not truly representative, but it is useful information and can often tell a very different story to your Lighthouse score.

Summary

Regular measurement matters because performance issues are often specific and easy to miss. Lighthouse is useful for identifying issues that affect website performance, and when used in conjunction with Webpagetest.org, you'll be in a better position to provide a good experience for your users. Next we'll cover common issues that can impact site speed, so read on.

Application Performance Optimisation

2020-09-12T13:00:00+10:00

Website performance testing is most useful when it explains where a request lost time. A single score can tell you that a page is slow, but it rarely tells the site team what to change next. The better starting point is the request path: where the visitor is, where the origin is, whether the response was cached, how much the browser had to download, and what work blocked rendering or interaction.

This article is a primer for that diagnosis. Start with a representative page, test it from a location that matches your users, then read the evidence in order.

Start With the First Request

The browser cannot render a page until it receives the main HTML document. That first request includes DNS lookup, TCP connection setup, TLS negotiation, any redirect, cache handling, origin processing, and the first byte coming back. When the origin is far away, latency compounds. Peakhour's performance material uses simple Australian examples: Sydney to Melbourne is about 5 ms one way, Sydney to Perth about 25 ms, and Sydney to San Francisco about 75 ms. Those numbers become larger when a page load needs several round trips.

This is why the main document matters in WebPageTest. In one Peakhour example, the main HTML document took 149 ms, which is fast. Many sites take 2 to 5 seconds before the browser receives that document. If the main response is already slow, the page has little chance of a good Largest Contentful Paint because the browser has not yet discovered the resources needed to paint the largest content.

Cache state is part of the same first request. A cache hit at the edge should look different from a miss that forwards to origin. Headers such as Cache-Status can show hit, miss, TTL, stored state, cache key, and collapsed request behaviour. Without that evidence, teams often guess whether a slow page is caused by the CDN, the origin, the application, or a cache-bypass rule.

Use WebPageTest for the Waterfall

WebPageTest is useful because it loads the page in a real browser and lets you choose test locations and connection profiles. That matters for Australian sites because a test from the wrong continent can make a local problem look worse or hide a regional problem from view.

The waterfall is the main working view. Read the first rows before looking at the rest of the page. A redirect on the first request adds delay before the useful page is even requested. Long DNS, connect, or TLS blocks point to connection setup or third-party domains. A long wait on the main document points to cache miss, origin processing, or backend work. Large downloads point to page weight. Red rows show broken requests, and the domain view shows how many external services the browser had to contact.

The filmstrip is just as important. It shows what the user saw while the waterfall was happening. If the HTML arrived quickly but the filmstrip stayed blank, the issue may be render-blocking CSS, JavaScript, fonts, or a hero image. If the page starts to render quickly but then jumps, you are looking at layout stability, not just network speed.

Use Lighthouse for Browser Work

Lighthouse is good at surfacing work inside the browser. It runs a controlled test, reports Core Web Vitals-related metrics, and lists opportunities such as eliminating render-blocking resources, reducing unused CSS, deferring JavaScript, compressing assets, and reducing main-thread work.

Treat the score as a prompt, not a verdict. Lighthouse scores can vary between runs because the local CPU, network conditions, and server response can vary. The useful part is the diagnostics. If Lighthouse points to a font, a theme stylesheet, or a third-party script that delays rendering, compare that with the WebPageTest waterfall and filmstrip. If both tools point to the same resource, you have a stronger case for change.

Connect Metrics to Causes

Core Web Vitals are easier to act on when each metric is tied to the part of the path it describes.

Symptom	Where to look	Likely next question
High TTFB	WebPageTest first row, cache headers, origin logs	Did the request hit cache, miss to origin, or wait on application work?
Slow FCP	Waterfall, filmstrip, render-blocking resources	Did HTML, CSS, or synchronous JavaScript stop the first paint?
Slow LCP	Main document timing, hero media, image weight	Was the largest element discovered and delivered early enough?
High CLS	Filmstrip, image dimensions, injected banners, fonts	Did content move after the visitor started reading?
Poor INP	Lighthouse main-thread diagnostics, third-party scripts	Is JavaScript delaying the next paint after interaction?
High page weight	WebPageTest content breakdown	Are images, JavaScript, fonts, or unused assets carrying the load?
Too many domains	WebPageTest domains view	Which third-party services are adding connection setup and blocking work?
Unclear cache behaviour	`Cache-Status`, CDN analytics, debug headers	Which paths are hits, misses, bypasses, stale responses, or collapsed misses?

This table is not a checklist to run forever. It is a triage map. Pick the symptom that matches the page, then follow the evidence to the next request-path decision.

Diagnose the Common Failures

Latency is the first failure to rule in or out. If the origin is in the United States and most customers are in Australia, the page can lose time before WordPress, Magento, Drupal, or a custom application has done any work. Edge caching helps when the response is safe to reuse, because the first byte can come from a location closer to the visitor.

Page weight is the next obvious drag. WebPageTest's content breakdown shows whether images, JavaScript, CSS, fonts, or other assets dominate the transfer. Unoptimised images are common, especially on CMS and ecommerce sites. Image variants in AVIF or WebP, responsive sizes, compression, and stable dimensions can improve both download time and LCP.

Render-blocking resources explain why a page can download quickly and still look blank. CSS and synchronous JavaScript in the head can stop the browser from painting. Large theme bundles and plugin scripts often include code that is not needed on the current page. The fix might be removing unused files, deferring non-critical scripts, splitting code by route, self-hosting critical third-party resources, or using preconnect only where the first view depends on a third-party domain.

Third-party domains need a sober review. Analytics, marketing tags, chat widgets, social embeds, payment scripts, and fonts can all be legitimate. They can also add DNS, TCP, TLS, download, parsing, and main-thread cost. If a third-party script is not needed for the first view, it should not block the first view.

Where Peakhour Evidence Fits

Peakhour performance work should show both user experience and origin relief. For caching, that means hit ratio, miss causes, Cache-Status, purge state, cache keys, shielded misses, collapsed requests, and origin fetch volume. For images, it means original size, transformed size, selected format, responsive variant, and cache hit state. For Core Web Vitals, it means LCP, CLS, INP, TTFB, page weight, and the same page tested before and after changes.

Security belongs in the performance review when it changes the request path. Bot filtering, WAF rules, rate limits, and login protection can reduce origin load by stopping abusive or noisy traffic before PHP, database, search, or API work begins. They can also create friction if rules are too broad. Measure the edge decision, the latency, the origin effect, and the false-positive risk. Do not treat "security enabled" as a generic performance story.

Good performance testing ends with a specific change to validate: cache this public route, purge it by tag, move this script later, replace this image variant, reduce these third-party domains, protect this login path, or investigate this slow origin query. Then run the same test again from the same location and compare the evidence.

WordPress Performance Optimisation

2019-05-27T13:00:00+10:00

WordPress speed problems are usually request-path problems. A public article, product page, or campaign landing page should not make PHP, plugins, and the database rebuild the same HTML for every visitor. A login attempt, checkout session, admin request, or private API call should not be treated like public content just because the site is under load.

The job is to separate those paths clearly. Cache what can be reused, protect the routes that are expensive or abused, and keep enough evidence to prove that the change improved the visitor experience without hiding origin risk.

Start With Public Page Caching

Most WordPress sites have a large set of pages that are dynamic only because WordPress generated them. The content itself is public and often identical for many visitors: posts, pages, category archives, product listings, campaign pages, media assets, CSS, and JavaScript. These are the paths where full-page caching and edge delivery can change the result quickly.

When a public page is served from cache, the browser avoids the long trip to origin and the origin avoids running WordPress for a repeat response. That can move Time to First Byte and Largest Contentful Paint in the right direction before anyone touches the theme. Peakhour's older full-page caching examples showed the practical size of this change: a Magento main document fell from 2.07 seconds before caching to 82 ms after caching. WordPress sites have different internals, but the same pattern applies when anonymous pages are safe to reuse.

The cache policy should be route-aware, not blanket. A simple operating model looks like this:

WordPress path	Delivery stance	What to check
Posts, pages, category pages, campaign pages	Cache publicly with tags and purge controls	Confirm logged-out content is shared and fresh after publishing.
Featured images, media library files, theme assets	Cache and optimise variants	Track image weight, format, dimensions, and cache hit state.
WooCommerce product and category pages	Cache when no cart/session dependency changes the response	Keep stock, price, and promotion purges tied to content changes.
Cart, checkout, account, previews, admin	Bypass shared cache	Preserve session privacy and correctness.
`wp-login.php`, `/wp-admin/`, `xmlrpc.php`, sensitive plugin endpoints	Protect and rate-limit before origin	Keep noisy automation away from PHP workers and admin paths.

Publishing Should Not Clear the Whole Site

Caching WordPress is easy until someone edits content. Clearing the whole cache after every post update is safe in the narrow sense, but it damages hit ratio and pushes avoidable traffic back to origin. During a busy publishing period or campaign, that can make the site slower exactly when fresh content is being promoted.

Cache tags are a better fit. Tags label cached responses by the content or template they depend on, so a post update can purge the post, related archives, and affected modules without invalidating unrelated pages. The updated Peakhour WordPress plugin generates cache tags automatically and sends purge requests when content changes in the WordPress admin. That lets teams set longer cache lifetimes for public content while still publishing with confidence.

This is where advanced caching becomes operational rather than theoretical. The site team can review which tags were purged, which routes stayed cached, and whether the next request was a hit, miss, or stored response.

Images and Browser Work Still Matter

Page caching improves the start of the request path. It does not fix a 3 MB hero image, missing image dimensions, unused CSS, or a third-party script that blocks rendering. WordPress themes and plugin stacks often ship CSS and JavaScript for features that are not used on the current page. The browser still has to download and parse that code before it can paint useful content.

Use Lighthouse to find render-blocking resources and main-thread pressure. Use WebPageTest to see whether the main HTML arrived quickly but the filmstrip still stayed blank while CSS, fonts, scripts, or images loaded. Those are different failures, and they need different fixes.

For images, the best results usually come from serving the right variant rather than only compressing the original. Peakhour image optimisation can generate AVIF or WebP outputs, choose responsive sizes, and cache the resulting variants. That helps LCP when the largest visible element is an image, and it helps CLS when dimensions are kept stable.

For CSS and JavaScript, remove unused files where possible, defer non-critical scripts, self-host critical third-party assets when practical, and reserve preconnect for third-party domains that genuinely affect the first view. Moving every script later can break dependencies, so test the actual page type rather than applying a generic rule across the whole theme.

Protect Expensive WordPress Paths

Performance and security meet at origin capacity. Login floods, XML-RPC abuse, aggressive crawlers, scraper traffic, and noisy plugin endpoints can consume PHP workers and database connections that should be serving real visitors. If those requests are filtered only after WordPress has loaded, the site can look like it has a speed problem when it really has an unsorted traffic problem.

For WordPress, protection should be specific. wp-login.php, /wp-admin/, xmlrpc.php, the REST API, and plugin-specific endpoints should have their own bot, WAAP, and rate-limit policy. WooCommerce needs separate handling again: public catalogue pages can often be cached, but cart, checkout, account, and payment paths must stay dynamic and private.

This does not mean putting heavy checks in front of every visitor. It means making edge decisions before origin work: allow clean public page requests, serve cache hits, challenge or rate-limit suspicious login traffic, bypass cache for private sessions, and log what happened.

Measure the Outcome

The evidence should line up across tools. WebPageTest should show a faster main document on cache hits, fewer slow origin fetches, and a waterfall where critical resources are visible early. Lighthouse should show fewer render-blocking opportunities and less main-thread pressure. Core Web Vitals should move where the page had the relevant bottleneck: LCP for slow HTML or heavy hero media, CLS for unstable layout, and INP for JavaScript and interaction work.

Peakhour evidence should add the delivery side: cache hit ratio, miss causes, purge state, Cache-Status, image savings, shielded misses, blocked login or XML-RPC abuse, and origin request volume. That combination tells the site team whether WordPress is faster because visitors received lighter pages from the edge, because abusive traffic stopped draining origin, or because browser work was reduced.

Fast WordPress is not a plugin list. It is a set of clear route decisions backed by before-and-after measurements.

Boost Your Website Speed with Peakhour's Full Page Caching

2019-04-02T13:00:00+11:00

Why Full Page Caching Matters

Site speed affects user experience, conversion, and server load. Slow pages can increase bounce rates and cost revenue. Full Page Caching improves response times by storing and serving static versions of dynamic pages. This reduces load on your server and gives visitors quicker page loads.

How Peakhour Optimises Your Site

Peakhour helps speed up and secure your website with a DNS change. Unlike basic caching solutions, Peakhour serves these static pages from its global ANYCast network. Your site's visitors download content from a server close to them, reducing latency and speeding up downloads.

Peakhour's Transparent Caching and Delivery

In addition to Full Page Caching, Peakhour can act as a transparent delivery and cache layer. It caches and optimises static assets like CSS, JavaScript, and images. You don't need to make any other changes to your site; a DNS change is all it takes.

Wordpress Plugin for Easy Integration

During our beta phase, many clients used early versions of our WordPress plugin. The plugin integrates with Peakhour's API to automate content flushing when you make edits in the WordPress admin panel. This simplifies publishing and allows you to set longer lifetimes for your dynamic content in our global cache.

Improved Performance Metrics

With Peakhour, sites can see faster download times, a higher cache hit rate, and reduced load on the origin server. Site owners get lower origin demand; visitors get faster pages.