Peakhour.IO - API Security

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.

The Real Cost of Breached Credentials

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

The cost of breached credentials is usually counted in the wrong place.

When an organisation suffers a data breach, the obvious costs are incident response, legal work, notification, customer support, remediation, and regulatory attention. Those costs matter. IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at about USD 4.4 million. IBM's data breach explainer also says stolen or compromised credentials were one of the top five initial attack vectors in the 2025 report, accounting for 10% of breaches and taking up to 186 days to identify.

But that is only the first bill.

Once usernames and passwords leave the original system, they do not stay attached to the original incident. They are copied, sorted, bundled, tested, resold, and mixed with other personal data. Another company's breach becomes your login problem. A password reused somewhere else becomes your fraud queue, your support call, your chargeback, your locked account, your angry customer, and your next security review.

That is the real cost of breached credentials: not just the breach, but the long tail of account abuse that follows.

The Roundup: Breaches Are Feeding Account Abuse

The numbers are not subtle.

The Identity Theft Resource Center's 2025 Annual Data Breach Report tracked 3,322 data compromises in 2025, a record high and a 79% increase over five years. The same report found that 70% of breach notices did not include attack information, making it harder for consumers and downstream businesses to understand what risk they now carry.

The ITRC also introduced a category it calls Previously Compromised Data: old stolen data that is repackaged and recirculated. In the full report, the ITRC says there were four major PCD releases in 2025, including two incidents involving roughly 16 billion records with no known notices. Its warning is the important part: while this may not be "new" stolen data, aggregation makes it highly effective for credential stuffing and account takeover attacks.

That matches the operational pattern security teams see on login endpoints. OWASP describes credential stuffing as automated testing of stolen username and password pairs against login forms. The reason it works is boring and persistent: people reuse passwords. Attackers do not need to breach your site if a customer has already reused a working credential somewhere else.

For Australian organisations, the local signals are just as relevant. The OAIC received 532 Notifiable Data Breach notifications between January and June 2025, with malicious or criminal attacks remaining the largest source of notifications. ASD's Annual Cyber Threat Report 2024-25 notes that its credential exposure notification process proactively sent 9,587 credential exposure events to about 220 organisations between 19 November 2024 and 30 June 2025.

None of that means every fraud loss starts with a reused password. It does mean credential exposure is part of the operating environment. Attackers have supply, tooling, proxy infrastructure, and plenty of places to turn account access into money.

The FBI's 2025 IC3 report gives useful context for that monetisation path. Cyber-enabled fraud accounted for 452,868 complaints and USD 17.697 billion in reported losses. Those losses include many crime types, not just credential stuffing, but the transaction paths are familiar to anyone dealing with account abuse: wire and ACH transfers, cards, peer-to-peer transfers, prepaid and gift cards, and cryptocurrency.

Where the Cost Actually Lands

A breached credential is cheap for the attacker and expensive for everyone else.

The first cost is detection. A login using the right username and password does not automatically look malicious. If the attacker spreads attempts across residential proxy infrastructure, uses one attempt per account, or targets mobile API endpoints directly, simple IP-based rate limits may not see the pattern. Peakhour has written about this in The Australian epidemic of Account Takeover attacks and in Credential Stuffing Does Not Stop at the Login Form.

The second cost is fraud. Once a credential works, the attacker looks for value: stored cards, gift cards, loyalty points, refunds, store credit, subscription changes, delivery addresses, and saved payment flows. This is why account takeover is not just an authentication problem. The expensive moment may be checkout, not login.

The third cost is support. Customers do not usually know whether the original password leak happened somewhere else. They know their account was used, their card was charged, their loyalty balance disappeared, or their email address changed. The business still has to handle the support ticket, freeze the account, unwind the transaction, review the evidence, and explain what happened.

The fourth cost is trust. We have covered this before in The Cost of Credential Stuffing: the reputational damage is practical. Customers see refunds, account locks, suspicious messages, and public complaints. Even if the business was not the source of the original breach, it becomes the place where the harm is felt.

The fifth cost is friction. If the only response is to challenge everyone, the business pays through abandonment and customer frustration. If the response is too soft, the business pays through fraud. The work is to apply friction where the evidence justifies it.

You Do Not Need Surveillance to Secure Accounts

There is a bad version of account protection that tries to identify people everywhere they go. That is not necessary, and it is not the right model for this problem.

Credential abuse defence should be scoped to the account security decision in front of you. Is this login using a known exposed credential pair? Is the session coming from suspicious infrastructure? Is it a first-seen device for the account? Is it trying to change email, reset the password, add a payout method, redeem stored value, or check out with saved payment details? Did the same client pattern just test many accounts?

Those questions can be answered with security-specific signals, not advertising-style tracking. Hash the credential check. Treat fingerprints as evidence, not identity. Keep the evidence tied to the protected account and request path. Use network, device, route, behaviour, and credential-risk context to decide whether to allow, step up, throttle, block, or review. Do not build a cross-site identity graph when the job is to stop account abuse on your own service.

That distinction matters. Users should not have to trade privacy for basic account security. Businesses also do not need to choose between doing nothing and adding blanket friction. Contextual security is useful because it lets the response match the risk.

What Teams Should Measure

If breached credentials are a business cost, measure them like one.

Useful measures include:

How many login attempts match known breached credential pairs.
How many breached-credential attempts result in a successful login.
Which routes see the risk: login, password reset, email change, stored-card checkout, gift card redemption, account recovery, mobile API, partner API, or admin access.
How often high-risk sessions move from login into sensitive account actions.
Which signals appear together: breached credential, residential proxy, first-seen device, unusual geography, repeated failure, rapid checkout, or recovery-flow pressure.
How many support tickets, refunds, chargebacks, account locks, and fraud reviews are linked to account takeover.
How many controls create customer friction, and whether that friction is landing on risky sessions or ordinary customers.

This does not need to be perfect on day one. The important step is to stop treating credential stuffing as a vague security category and start treating it as an observable account-risk workflow.

The Control Pattern

The control pattern is layered.

Start with breached credential scanning so reused or exposed credentials are visible at login. Feed that signal into account takeover prevention rather than treating it as a standalone report. Add bot management and advanced rate limiting so automation and distributed testing are harder to run at scale. Use residential proxy detection as a risk signal, especially where attackers are trying to make automated traffic look like normal customer traffic.

Then carry the risk forward after login.

A low-risk page view and a saved-card checkout should not inherit the same level of trust just because the password worked. A session that begins with a breached credential match, comes through suspicious infrastructure, and immediately changes the email address or redeems stored value deserves a different response from a known customer browsing order history.

The response can be graduated:

Log low-risk activity for visibility.
Tighten rate limits on suspicious automation.
Require step-up verification before sensitive account changes.
Hold or review risky transactions.
Notify the customer when high-risk account changes are attempted.
Block sessions when the evidence is strong enough.

That is how breached credential data becomes useful. It is not a panic button. It is a signal that helps decide when trust should be earned again.

The Practical Takeaway

Breached credentials are not only a breach-response issue. They are an account protection issue, a fraud issue, a support issue, and a customer trust issue.

The original breach may have happened somewhere else. The cost can still land on your login form, your checkout, your API, and your support team.

The goal is not to make every login difficult. The goal is to make stolen credentials harder to turn into account control, money movement, stored-value abuse, or customer harm.

That starts by making credential risk visible, connecting it to session and route context, and applying proportionate controls where the cost would otherwise show up.

Credential Stuffing Does Not Stop at the Login Form

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

Credential stuffing is usually described as a login problem. An attacker takes breached username and password pairs, tests them against a site, and tries to find accounts where people reused passwords.

That description is accurate, but incomplete. The login is only the first gate. The real damage often happens in the flows that follow a successful login: password reset, email change, saved cards, loyalty balances, gift cards, account recovery, address changes, and checkout.

If account protection only watches the login form, it can miss the part of the attack that matters most to the business.

A successful credential stuffing attempt does not always look dramatic. The attacker may have valid credentials. They may come through residential proxy infrastructure. They may spread attempts across many IP addresses. They may slow the attack down to stay below simple thresholds. If the site treats a valid username and password as the end of the risk decision, the attacker inherits whatever the account can do.

That is why account takeover prevention needs to cover account actions, not just authentication.

The Attack Continues After the Password Works

Once an attacker is inside an account, they usually want persistence, value, or both.

A password reset or password change can lock the real customer out. An email change can move alerts, receipts, and recovery messages away from the owner. A phone number change can weaken later verification. A new shipping address can redirect physical goods. Stored payment methods can turn account access into immediate fraud. Gift cards, store credits, loyalty points, and refunds can be easier to monetise than a card transaction.

Checkout is often where the compromise becomes visible, but the risk builds earlier. A login from unfamiliar infrastructure followed by a profile change, then a saved-card purchase, is different from a returning customer browsing previous orders. A dormant account that suddenly redeems gift cards, changes email, and ships to a new address deserves more scrutiny than an ordinary login.

These flows are also common in APIs. Mobile apps, single-page applications, partner integrations, and checkout backends expose account actions through endpoints that may not share the same controls as the web login page. Attackers do not care whether the valuable step is behind /login, /api/account/email, or /checkout/payment. They follow the path that works.

Breached Credentials Are a Risk Signal

Breached credential checks are useful because they add context before the account is fully trusted. If a credential pair is known to have appeared in a breach, the site can treat the session differently from the start.

That does not mean every breached credential attempt should be handled the same way. A user may be genuinely logging in with a reused password. An attacker may be testing a combo list. A customer may be returning after a long period away. The point is to make the risk visible and carry it through the session.

Peakhour has written before about managing breached credential usage. The practical lesson is that credential risk should feed the wider account protection decision. A breached credential signal should be considered alongside client evidence, network context, request rate, route sensitivity, behaviour, and the action being attempted.

A low-risk page view and a stored-card checkout should not inherit the same confidence just because both follow a successful login.

MFA Helps, But It Does Not Close Every Path

Multi-factor authentication remains useful. It can stop many direct account takeover attempts and raise the cost of abuse. But MFA is not a complete defence when attackers use social engineering, session theft, weak recovery flows, trusted devices, or post-login actions that do not require step-up verification.

The better pattern is adaptive control. Let the login succeed when the evidence is low risk. Step up when the action matters. Ask for stronger verification before changing the email address, adding a new payout method, redeeming a stored balance, or checking out with saved payment details from an unfamiliar context.

This is not about adding friction everywhere. It is about reserving friction for the points where compromise turns into loss.

What to Monitor After Login

The useful signals are operational and specific:

Credential risk at login, including known breached username and password pairs.
New client, browser, or network evidence on an existing account.
Password reset, password change, email change, and phone change attempts.
New shipping addresses, payment method changes, stored-card use, gift card redemption, and loyalty balance activity.
Sudden changes in behaviour, such as rapid checkout after login or repeated account recovery attempts.
API routes that perform sensitive account actions without the same scrutiny as browser flows.

The response should match the confidence and consequence. Some events only need logging. Some need tighter rate limits. Some need a browser challenge, MFA step-up, temporary hold, customer notification, or review.

Credential stuffing defence is not finished when a password works or fails. The more useful question is: what does this session try to do next, and does the evidence justify trusting it?

For account protection, that is the line that matters.

Fingerprints Are Evidence, Not Identity

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

The word "fingerprint" can create the wrong expectation.

In security, a browser or network fingerprint is not the same as a human fingerprint. It does not prove who a person is. It does not remove uncertainty. It should not be treated as a permanent identity for a customer.

A fingerprint is evidence. Sometimes it is strong evidence. Sometimes it is weak, common, stale, or deliberately manipulated. Its value comes from how it is combined with route, behaviour, account state, network context, credential risk, and the action being requested.

That distinction is more than wording. It affects how security teams design controls, explain decisions, and avoid overblocking legitimate users.

What Network Fingerprints Can Tell You

Network fingerprinting compares connection and protocol evidence. TCP behaviour, TLS handshakes, JA3 or JA4-style representations, HTTP/2 settings, header shape, MTU, proxy indicators, ASN, and path characteristics can all help classify the client or infrastructure behind a request.

That can be useful during credential stuffing, scraping, scanning, API abuse, or Layer 7 attack pressure. Attackers may rotate IP addresses, but parts of the client stack or automation framework can remain consistent. Grouping requests by network evidence can make rate limiting, bot detection, and investigation more precise than IP-only rules.

But the fingerprint is still not identity.

Common browsers can share similar network shapes. Mobile networks and carrier-grade NAT can make unrelated users appear close together. VPNs and residential proxies can distort source context. Browser and library updates can change fingerprints overnight. Hashing can make signals portable while hiding useful detail. Attack tools can also try to imitate normal clients.

The right conclusion from a suspicious network fingerprint is not "we know who this is". It is "this request deserves a different level of confidence".

What Browser Fingerprints Can Add

Browser fingerprinting adds evidence from the application layer and, where appropriate, browser-side checks. Headers, client hints, JavaScript-visible properties, rendering behaviour, storage behaviour, timezone, language, permissions, and API availability can help decide whether a request looks like the browser it claims to be.

This matters because many attacks try to borrow the appearance of ordinary browser traffic. Automation frameworks, emulators, headless browsers, anti-detect browsers, and scripted API clients can all present a user-agent string that looks plausible. Browser evidence helps compare the claim with the rest of the request.

Again, the useful output is confidence, not identity. A browser fingerprint might support a challenge. It might support a lower rate limit. It might explain why a session changing an email address needs step-up verification. It might help bot management separate obvious automation from normal traffic.

It should not become a claim that one technical pattern equals one person.

The Comparison Matters

Peakhour's page on browser fingerprinting vs network fingerprinting makes the operational split clear. Network fingerprints usually come from passive connection and protocol evidence. Browser fingerprints often involve request and browser-side evidence. They answer related but different questions.

A strong decision often needs both.

A request claiming to be a normal browser should look broadly consistent across TLS, HTTP/2, headers, JavaScript-visible browser properties, proxy context, route behaviour, and account history. If the browser looks normal but the network path resembles a known automation cluster, that is useful. If the network path looks ordinary but the browser evidence is inconsistent or missing on a sensitive route, that is useful too.

The mismatch is the signal. The response still depends on consequence.

A suspicious request to a public asset route might only need logging. The same evidence on login, password reset, stored-card checkout, account email change, admin access, or an expensive API route may justify a challenge, tighter limit, temporary hold, or review.

How to Use Fingerprints Responsibly

Fingerprints work best when they are attached to an explainable decision. A security event should show the route, account or token context where relevant, source network evidence, browser evidence, policy action, response code, and review outcome. That gives operators a way to understand and correct decisions.

Peakhour's guide to network fingerprint signals and security decisions frames the choices properly: allow, log, challenge, rate limit, block, or review. A fingerprint should help choose among those actions. It should not replace judgement.

Responsible use also means accepting uncertainty. Fingerprints collide. They drift. They can be spoofed. Some privacy tools intentionally reduce or alter browser signals. Some legitimate users have unusual configurations. Some high-risk requests have only partial evidence.

That uncertainty does not make fingerprints useless. It means they should be one layer in a wider control set.

For account and API security, the practical question is not "can this fingerprint identify a person?" It is "does this evidence change the confidence we should place in this request?"

If the answer is yes, use it carefully. Increase scrutiny on sensitive actions. Reduce friction where evidence is clean. Preserve enough context for review. Avoid pretending that a technical fingerprint is a human identity.

That is the more accurate model, and it leads to better security decisions.

Account Security Without Tracking People

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

Account security needs evidence. A login request is not just a username and password; it has a route, client context, browser behaviour, network path, timing, session history, credential risk, and follow-on actions. Without some of that context, defenders are left with blunt controls: block too much, challenge everyone, or trust too easily.

The privacy problem starts when security teams confuse evidence with identity.

A risk signal should help answer a narrow operational question: should this login, password reset, email change, API call, or checkout step be allowed, challenged, rate limited, blocked, logged, or reviewed? It should not become a general-purpose profile of a person.

That distinction matters. Good contextual security is not surveillance dressed up as account protection. It is purpose-bound telemetry used to make proportionate security decisions.

Minimise the Signal Set

Security teams should start with the action they are protecting.

A login attempt may need credential risk, source network context, browser consistency, known client status, failed-attempt history, and session age. A password reset may need different evidence. A checkout using stored payment details may need another set again. There is rarely a good reason to collect every possible signal for every route.

This is especially important with browser and device evidence. Browser fingerprinting can include headers, client hints, JavaScript-visible properties, rendering behaviour, storage behaviour, timezone, language, and other consistency checks. Those signals can be useful for detecting automation, anti-detect browsers, session abuse, and high-risk account changes. They can also be privacy-sensitive if collected broadly or retained without a clear purpose.

The practical standard should be simple: collect what is needed for the account defence decision, attach it to that decision, and avoid turning uniqueness into the goal.

Use Evidence Over Identity

A security system does not need to know who a person "really" is to make a better login decision. It often only needs to know whether the request looks consistent with the account, route, browser, network path, and recent behaviour.

That is where verified browser trust fits. The point is not to label a human being. The point is to decide whether a browser-like request has returned enough trustworthy evidence to proceed on a sensitive path. If the evidence is weak, the system can choose a proportionate response: log, challenge, rate limit, step up authentication, or send the event for review.

Network evidence should be handled the same way. Network fingerprint signals can help distinguish ordinary browser traffic from automation, proxy paths, unusual client stacks, or inconsistent request shapes. But a network signal is not a person. It is one piece of evidence attached to a request.

That framing reduces overreach. It also improves operations because decisions remain reviewable. If a customer is challenged, support and security teams should be able to see the route, risk signals, and policy reason without needing a vague black-box identity claim.

Be Careful With Behavioural Analytics

Behavioural analytics can help detect account compromise, especially when a session changes sharply from normal account usage. A customer who normally logs in from one region and browses slowly may deserve extra scrutiny if the same account suddenly logs in from unfamiliar infrastructure, changes email, redeems stored value, and checks out quickly.

But behavioural systems have limits.

Some users are sporadic. Some travel. Some use privacy tools. Some share devices. Some change browsers or phones. Some only visit when there is a problem. If there is not enough history, the system should admit that uncertainty rather than pretending the baseline is stronger than it is.

That is where adaptive security is useful. Low-confidence evidence does not always justify a hard block. It might justify logging, a lower rate limit, a step-up challenge on a sensitive action, or a temporary hold on a risky change.

The aim is not perfect recognition. It is better decision-making under uncertainty.

Make Retention and Purpose Part of the Design

Privacy-respecting account security is not only about which signals are collected. It is also about how long they are kept, where they are used, and who can inspect them.

Useful practices include:

Tie telemetry to account defence purposes such as login risk, bot detection, account recovery, checkout abuse, and API misuse.
Prefer route-specific evidence over broad user profiling.
Keep raw signals only where they are needed for detection, audit, or investigation.
Store decision evidence in a way operators can review.
Avoid using security telemetry for unrelated marketing or behavioural targeting.
Tune controls so low-risk users are not repeatedly challenged without cause.

Peakhour should not pretend that account security can happen with no fingerprints, no telemetry, and no judgement. Modern attacks abuse valid credentials, residential proxy paths, automation frameworks, API routes, and post-login workflows. Defenders need evidence.

The privacy-respecting position is narrower and stronger: collect the right evidence for the security decision, minimise it, keep it purpose-bound, and treat fingerprints as confidence signals rather than personal identity.

That is how account security can become safer without turning every login into tracking for its own sake.

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.

Shadow APIs Are Account-Abuse Paths

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

A shadow API is not dangerous because it has a mysterious name. It is dangerous because it still accepts requests.

If an endpoint can reset a password, refresh a token, check an account, change a delivery address, apply a discount, validate a stored payment method, or expose customer data, it is part of the account-abuse surface. Whether it appears in the current OpenAPI file is secondary.

Attackers do not need your API catalogue to be tidy. They need one working route that your normal controls do not understand.

The Forgotten Paths Are Often Real Paths

Most organisations have more API surface than they think.

Mobile apps leave behind old versions. Partner integrations get built for a campaign and then stay online. Browser-backed APIs are treated as internal because they are called by the front end, even though anyone can inspect and replay the requests. Legacy account endpoints remain active because turning them off might break an unknown client.

None of this is unusual. It is how real systems evolve.

The risk appears when those routes keep accepting production traffic without the same security treatment as the visible application. A current login page may have bot detection, adaptive prompts, and tuned rate limits. An older mobile endpoint may only check whether the credentials are valid. A partner route may trust an API key that has not been rotated. A browser API may return more account state than the front end displays.

That gap is where account abuse gets practical.

Unknown Does Not Mean Unused

Security teams sometimes talk about discovery as if the main outcome is a cleaner inventory. Inventory matters, but the more useful question is: what can this route do?

A shadow API that serves public catalogue data has one risk profile. A shadow API that changes account details has another. A forgotten token endpoint is different again. A mobile route that accepts username and password combinations is a credential stuffing target, even if the public login page has already been hardened.

This is why API security has to stay connected to account context. Route discovery is only the start. The protection model needs to know method, schema, authentication state, response pattern, user journey, and business sensitivity.

A POST request to an account recovery endpoint deserves different treatment from a GET request to a static content API. A password reset route used by a first-seen client through rotating proxy infrastructure is not the same as the same route used by a known customer session.

The route matters because the account outcome matters.

Browser-Backed APIs Are Still APIs

A common blind spot is the API behind the web application.

The front end might make a neat request to /api/account/profile, /api/cart/apply-coupon, or /api/session/refresh. Because the route was designed for the browser, teams may assume the browser is the control. It is not.

Requests can be replayed outside the page. Headers can be copied. Tokens can be stolen. User agents can be faked. Automation can follow the same sequence as the application, only faster and at scale.

The right response is not to treat every browser-backed API as hostile. The right response is to attach evidence. Is this a known browser session? Is the TLS and HTTP behaviour consistent? Is the request sequence normal for the journey? Is the session suddenly moving from login to sensitive account changes? Does the schema match what the route expects?

Those questions sit between basic definitions of what API security is and the operational work of stopping abuse.

Mobile and Partner APIs Need Ownership

Mobile and partner APIs create a slightly different problem. They often have legitimate non-browser clients, so crude controls can break real use.

A mobile app may have older versions in the field. A partner may send traffic from fixed infrastructure, or from changing cloud infrastructure. A service client may authenticate with an API key rather than an interactive user session. Some requests will look less browser-like because they are not meant to be browsers.

That makes ownership important.

Each route should have an owner, expected clients, authentication model, rate expectation, schema expectation, and deprecation plan. API keys should be treated as credentials, not configuration strings. OAuth and JWT use should include short-lived access, appropriate scopes, and validation at the endpoint. Legacy flows should not survive indefinitely just because nobody is sure what they support.

For REST services, that discipline includes the basics covered in REST API security: method control, status-code handling, input validation, token handling, rate limiting, and useful logging. The account-abuse angle is narrower and more operational: which of these controls tells us whether this request can harm a customer account?

Discovery Has to Feed Enforcement

A report listing unknown endpoints is useful for a week. A discovery process that feeds policy is useful every day.

When a new route appears, the security question should be concrete:

Who owns it?
Is it authenticated?
Does it match a known schema?
Does it touch account state?
Can it reset trust, change value, or expose customer data?
What rate and behaviour patterns are normal?
Which action should apply when it is abused?

That is where API protection use cases become more than documentation. The goal is not to produce a perfect catalogue for its own sake. The goal is to reduce the number of unknown request paths that can be used for account abuse.

Shadow APIs are not a separate class of attack. They are normal APIs without enough operational visibility.

And when they sit on account journeys, they become a direct path from unknown surface to customer harm.

Price Transparency Is Now a Data Access Problem

2026-05-18T00:00:00+10:00

Australia's supermarket pricing debate can look like a consumer pricing story.

For digital teams, it is also a bot and API protection story.

The ACCC's final supermarket inquiry recommended that ALDI, Coles, and Woolworths publish prices on their websites. It also recommended that Coles and Woolworths make dynamic price APIs available for third-party comparison tools.

Then, on 18 May 2026, Guardian Australia reported on CW Scanner data about Coles and Woolworths promotion patterns. For digital teams, the operational detail is this: the report said CW Scanner's operator stated the service was not scraping, and instead used the supermarkets' website application programming interfaces.

That does not settle questions about permission, terms of use, supermarket approval, or the status of any specific API. It does make the practical problem sharper.

Price transparency increasingly depends on automated access to current data.

Every automated request still needs a decision.

APIs do not remove the bot problem

It is tempting to treat an API as the clean alternative to scraping. Sometimes it is cleaner. A documented API can make access more predictable, auditable, and easier to govern than repeated extraction from product pages.

But an API is still an automation surface.

The same retailer or marketplace may need to support:

public product pages;
price, promotion, search, listing, catalogue, and inventory routes;
browser-backed application calls;
documented APIs and partner feeds;
comparison tools and public-interest services;
search engines, monitoring systems, and accessibility tooling;
unknown collectors rebuilding price, inventory, availability, or ticketing datasets outside the intended access model.

Some of that traffic is useful. Some is commercially necessary. Some is abusive. Much of it will not identify itself honestly.

So the question is not "should bots be blocked?"

The question is: can you tell intended automated access from uncontrolled extraction?

The decision needs evidence

A blanket "block all automation" position can break comparison services, partner integrations, search visibility, monitoring, accessibility tooling, and APIs that were built to be automated.

A blanket "allow everything" position can expose pricing, product, inventory, account, checkout, ticketing, and API paths to extraction and abuse.

The practical middle ground is governed automation:

publish the access you want to support;
recognise the clients and behaviours you expect;
validate API route, schema, method, authentication, and client context;
detect traffic that has drifted from the intended use;
keep decision logs so security, legal, product, and commercial teams can review what happened;
respond proportionately with allow, log, rate-limit, challenge, block, or review decisions.

That is where bot protection becomes more than a yes-or-no control.

It supplies the evidence behind each access decision.

Where Peakhour fits

Scraping protection should identify repeated extraction across product, price, search, listing, catalogue, article, inventory, and availability routes. The goal is not to stop every non-human request. It is to separate expected access from collectors rebuilding data outside the site's control.

API bot protection applies the same discipline to automated API clients. APIs exist to be automated. The risk comes from unknown clients, unexpected route combinations, credential abuse, endpoint enumeration, excessive request volume, and business-logic abuse that generic perimeter controls cannot explain.

Bot management turns request evidence into a decision: allow trusted traffic, log expected automated access, rate-limit noisy collectors, challenge uncertain sessions, block confirmed abuse, or send edge cases to review.

Verified browser trust adds a useful signal when browser-backed journeys are being automated or replayed. Headers and cookies can be copied, proxy networks can rotate, and automation can mimic ordinary navigation. Peakhour can challenge the browser path, verify that the expected evidence came back, and attach that witness to the wider decision record.

That browser signal does not, by itself, prove the user, device, or account is trustworthy. It helps the risk engine decide what to do alongside route, proxy, device, behaviour, credential, and API context.

Why this matters beyond supermarkets

The ACCC's 2024 proceedings against Coles and Woolworths were about alleged false or misleading price statements, not supermarket price regulation, collusion, or anti-competitive conduct. The ACCC announced on 14 May 2026 that the Federal Court found Coles made false or misleading representations in 13 of 14 agreed sample "Down Down" tickets, with penalties and other orders still to be determined. For Woolworths, the separate "Prices Dropped" proceeding was awaiting judgment at publication.

Those legal details matter, but they are not the Peakhour point.

The Peakhour point is operational: when transparency, comparison, availability, or fairness depends on current digital data, organisations need a control plane that can support the access they intend and limit the extraction they do not.

That pattern shows up in retail, marketplaces, ticketing, travel, financial services, media, and any platform where public pages, browser-backed calls, and APIs expose commercially valuable data. It also shows up in adjacent problems like account abuse, checkout abuse, ticket scalping, product scraping, distorted analytics, and inventory harvesting.

The organisations that handle this well will not treat every automated request as the same.

They will be the ones that know what access they intend to allow, what behaviour they intend to stop, and why.

Agentic AI vs. Your API

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

For years, "bots" mostly meant simple, scripted programs. They followed rigid, predefined rules: if you see X, do Y. They were predictable. They could still do damage in attacks like credential stuffing, but their lack of intelligence made them relatively easy to detect. Their patterns were repetitive and clearly different from the complex, often messy, behaviour of human users.

That model is no longer reliable. The emergence of open and powerful reasoning models like DeepSeek has given rise to a new class of automation: agentic AI. These are not just scripts. They are autonomous agents that can reason, plan, and adapt their behaviour in real time. They don't need a human to write a script for every possibility. Give them a goal and they can work out the steps themselves. That changes the nature of automated threats, and security controls need to change with it.

The New API Consumer

Historically, APIs were consumed by two main groups: human users via a front-end application, and scripted bots following predictable patterns. Agentic AI introduces a third consumer, and one likely to become dominant. These AI agents are becoming primary users of web APIs, and they interact with them in materially different ways.

An AI agent can analyse an entire API surface in seconds, understand the relationships between different endpoints, and generate complex interaction patterns that a human developer would rarely attempt. They don't just follow a linear path; they can explore, learn, and optimise their interactions to achieve their goals, whether that's finding the best price on a product, gathering data, or probing for security weaknesses.

New Security Challenges: The Self-Hacking AI

The reasoning capabilities of these agents introduce security challenges that static, rule-based systems are poorly equipped to handle. An agentic AI doesn't just throw known exploits at a system; it can probe its defences and invent new attacks as it goes.

Consider a traditional Web Application Firewall (WAF) that relies on pattern-matching rules to block threats like SQL injection. An AI agent can send a series of carefully crafted requests, observe the WAF's responses, and systematically learn the structure of its rules. Once it understands the patterns the WAF is looking for, it can generate a custom exploit designed to bypass those rules while still achieving its malicious objective.

This isn't theoretical. Security teams are already reporting sophisticated attacks that adapt in real time, adjusting their tactics based on the system's defensive responses. These aren't simply pre-programmed behaviours; they are reasoning models at work.

A New Security Paradigm: From "Block Bots" to "Manage Agents"

The rise of agentic AI changes the security question. The old goal of "blocking all bots" is no longer viable or even desirable. AI agents will be used for both benign and malicious purposes. A customer's personal AI assistant booking a flight is useful automation; an attacker's AI agent trying to find vulnerabilities is not.

Bot management cannot stop at trying to keep automation out. It needs the intelligence to safely identify and manage AI agents. This requires moving away from static, signature-based detection and toward a more contextual, behavioural approach.

The key questions will no longer be "Is this a human or a bot?" but rather:

"What is the intent of this automated agent?"
"Is its behaviour consistent with a legitimate use case?"
"Can we trust this agent?"

This requires a new generation of security tools that can understand and adapt to agent behaviour, distinguishing between the legitimate AI assistants that will soon be a core part of our digital lives and the malicious ones that seek to exploit our systems. Organisations that fail to prepare for this shift risk having their defences systematically tested, mapped, and bypassed by the next wave of intelligent, automated threats.

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.

Key Considerations for Effective Bot Management

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

Introduction

Bots account for a large share of web traffic. Recent studies estimate that nearly 50% of all internet traffic is generated by automated programs. Some bots are necessary for the web to function, such as search engine crawlers, but a significant portion are malicious. These "bad bots" are used for content scraping, credential stuffing, spam, and DDoS attacks.

As bot operators become more sophisticated, bot management needs to cover detection, classification, and response. This article outlines the main considerations for security teams protecting intellectual property, online revenue, and user accounts.

The Goal: Accurate Bot Detection and Classification

The first step in effective bot management is separating legitimate users from automated threats. Identification is not enough on its own. Security teams also need accurate classification across good, bad, and "grey" bots.

Good Bots: Support normal internet operations, such as search engine crawlers (Googlebot, Bingbot) and performance monitoring bots.
Bad Bots: Carry out malicious activity such as content scraping, account takeover, and spamming.
Grey Bots: Serve a legitimate purpose but can cause problems when they crawl too aggressively, such as SEO and marketing bots (Ahrefs, SEMrush).

Effective detection usually needs more than basic signatures. A layered approach commonly includes:

Basic Protection: Targets simple bots using user agent checks and IP reputation databases.
Intermediate Protection: Uses JavaScript-based challenges and basic network fingerprinting, such as JA3/JA4, to detect less sophisticated bots.
Advanced Protection: Combines comprehensive network fingerprinting, behavioural analysis, and machine learning to identify sophisticated bots that mimic human behaviour, use residential proxies, or rely on anti-detect browsers.

Machine learning models help in this context because they can learn from changing bot strategies and inspect incoming traffic for subtle signs of automation.

The Method: Continuously Adaptive Detection and Response

Bot behaviour changes quickly. Threat actors modify tooling, traffic patterns, and infrastructure to avoid detection, so static defence rules degrade over time. Organisations need detection and response that can adapt as the attack changes.

That means correlating metadata with behavioural factors in real time, then applying the right response for the risk. When a bot attempts account takeover or data scraping, an adaptive response can act immediately to reduce the impact.

Effective adaptive responses include:

Advanced Rate Limiting: Goes beyond simple IP-based limits by grouping requests with more stable identifiers, such as TLS/HTTP2 fingerprints or device characteristics. This helps stop distributed attacks from tools like OpenBullet that rotate through thousands of IP addresses.
Web Application Firewalls (WAF): Provide an important first line of defence by filtering harmful Layer 7 traffic based on predefined rules.
Tarpitting: Slows malicious connections to increase cost and resource consumption for attackers.
Challenges: Traditional visible CAPTCHAs can harm user experience and are often solvable by modern bots. Invisible challenges can verify a legitimate browser environment with less friction.
Alternate Content Serving: Misleads scraping bots by serving alternate or cached content with incorrect information (e.g., higher prices), making their scraped data useless.

The same response process should also feed learning loops, building a repository of bot attack patterns that can train machine learning models and improve accuracy over time.

The Expected Outcomes: A Resilient Security Posture

An adaptive bot management strategy should support several practical outcomes:

Risk Mitigation: Reduce potential financial losses, service disruption, and data breaches associated with malicious bot activity such as credential stuffing, ad fraud, and inventory hoarding.
Improved User Experience: Keep disruption low for genuine users by using invisible challenges and behavioural analysis instead of frustrating CAPTCHAs, which can reduce conversions by up to 40%.
Intellectual Property Protection: Protect valuable content, pricing data, and other intellectual property from unauthorised scraping.
Online Revenue Security: Protect online revenue streams by preventing fraud, inventory scalping, and other malicious activity that targets e-commerce platforms.
Regulatory Compliance: Help organisations meet data protection and privacy regulations with a proactive bot management approach.

Conclusion: Fortifying Against Sophisticated Bots

Modern bot defence depends on accurate detection, precise classification, and adaptive response. Machine learning, comprehensive network fingerprinting, and behavioural analysis all contribute, but they work best as part of a layered control set.

With that approach, security teams can better protect intellectual property, online revenue, and user accounts from sophisticated bot activity.

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.

How to Use Bot Management for IAM Use Cases

2025-08-20T00:00:00+10:00

Automated attacks against identity and access management (IAM) systems are now a routine account protection problem. Malicious bots drive account takeovers (ATO), credential stuffing, brute-force login attempts, and fake account creation. As these attacks adapt, traditional IAM controls such as password policies and even multi-factor authentication (MFA) are not enough on their own.

Identity and access management leaders should treat bot management as part of the IAM control set, not a separate website security add-on. A dedicated capability helps reduce avoidable financial and reputational losses from account compromise. It also gives organisations a way to manage the risks created as AI agents become regular users of web applications and APIs.

Introduction

Some estimates suggest nearly half of all traffic is automated. That mix matters: useful crawlers and monitoring tools are part of normal internet traffic, but malicious automation is built to test web applications at scale. IAM systems, which control access to sensitive user accounts and data, are a primary target.

The most common bot attacks targeting IAM include:

Credential Stuffing: Attackers use lists of stolen usernames and passwords from third-party data breaches to gain unauthorised access to user accounts. This attack vector is effective because password reuse is still common.
Brute-Force Attacks: Automated scripts guess passwords for known usernames, often targeting login endpoints for platforms like WordPress and Magento.
Fake Account Creation: Bots create fraudulent accounts at scale, which can be used for spam, malware distribution, or to abuse promotional offers.

Recent attacks on major Australian retailers like The Iconic and Dan Murphy's show the practical impact. These incidents, driven by credential stuffing, resulted in reputational damage and financial loss, forcing the companies to issue refunds and publicly address security concerns.

Analysis

Defending IAM systems starts with why common controls fall short and where bot management adds useful signal.

Why Traditional IAM Defences Fail

Attackers have adapted their techniques to bypass legacy security controls. Simple IP-based rate limiting and reputation lists struggle against the combination of residential proxies and anti-detect browsers:

Residential Proxies: Attackers route their traffic through large networks of IP addresses belonging to real residential internet connections. This makes malicious traffic appear legitimate and allows attackers to bypass IP-based blocking and geolocation restrictions. Our own tests show that even leading IP intelligence services fail to detect the vast majority of residential proxy traffic.
Anti-Detect Browsers: These specialised browsers allow attackers to spoof their digital fingerprints, mimicking legitimate user devices and browser configurations. This weakens many JavaScript-based challenges and fingerprinting techniques.

Used with automation suites like OpenBullet, these tools let attackers run "low and slow" distributed attacks that blend into normal traffic. For more information on these tools, see our guide to enterprise bot management.

The Flawed Logic of CAPTCHA

For years, CAPTCHA has been the default way to distinguish humans from bots. It is now a weak control when used on its own. Our research shows that visible CAPTCHAs have a severe negative impact on user experience and conversions. Studies have found that CAPTCHAs can reduce form conversions by up to 40%, as frustrated users abandon purchases or sign-ups.

Modern bots can also solve CAPTCHAs with high accuracy, often more effectively than humans, by using CAPTCHA-solving farm services. Relying on CAPTCHA alone creates friction for legitimate users while providing a false sense of security. Modern bot management uses invisible challenges and behavioural analysis to validate users without disrupting their session.

Modern Bot Management Capabilities for IAM

An effective bot management solution provides a multi-layered defence that goes beyond simple signatures. Key capabilities include:

Advanced Rate Limiting: Instead of relying on IP addresses, modern solutions group requests using more stable identifiers like TLS/HTTP2 fingerprints, device characteristics, or a combination of headers. This helps detect distributed attacks from a single malicious tool, even as it rotates through thousands of IPs.
Network and Device Fingerprinting: By analysing the unique characteristics of a client's TCP and TLS implementation, it is possible to identify the underlying software making the request, regardless of the user-agent header. This helps distinguish between real browsers and automated scripts.
Behavioural Analysis: Systems can model normal user behaviour—such as mouse movements, typing speed, and page navigation—to identify anomalies that indicate automation.
Residential Proxy Detection: Specialised techniques are required to identify traffic coming from residential proxy networks, which is a strong indicator of malicious intent.
Breached Credential Integration: By checking login attempts against databases of known breached credentials, security teams can apply additional scrutiny to high-risk authentication events.

Together, these controls give IAM teams more useful decision points than an IP address, a password check, or a CAPTCHA challenge alone.

The Next Frontier

The next major change in automated traffic is agentic AI. As reasoning models like DeepSeek become more accessible, we are entering an era where AI agents are becoming primary consumers of APIs and web applications.

These are not just the rigid scripts of the past. AI agents can reason, plan, and adapt their behaviour in real-time based on a system's responses. They can analyse an entire API surface in seconds and generate complex interaction patterns that human developers would be unlikely to try manually.

This creates a harder IAM problem. Bot management has usually looked for patterns that differ from normal human behaviour. AI agents can make those patterns less reliable by imitating user behaviour while still operating at machine speed. The line between human and automated traffic blurs.

IAM leaders need bot management solutions that can adapt to this shift. The future of bot management will not only be about blocking bots; it will also be about deciding which automated agents are acceptable, under what conditions, and with which controls. This requires a shift from static, rule-based security to contextual analysis that understands and adapts to agent behaviour, distinguishing between legitimate AI assistants and malicious ones. Organisations that wait until agent traffic is common will have less time to distinguish useful automation from AI-driven attacks.

How AI Agents Are Writing Custom Exploits

2025-02-17T14:00:00+11:00

The trend is clear enough: AI agents can now craft exploits by analysing security responses in real time. That puts static security rules and traditional Web Application Firewalls (WAFs) under direct pressure. Here is why.

Last week I examined an AI agent probing a test environment. It sent requests, observed the responses, then built bypasses for each security control in sequence. The agent identified pattern-based rules, learned their structure, and generated variations until it found gaps. It did this without human intervention.

This kind of automated exploit development changes the operating conditions for defenders. Traditional defences rely on known patterns: regex rules, signature matching, IP reputation. Those approaches assume threats follow recognisable templates. That assumption is becoming much weaker.

Consider a standard WAF rule blocking SQL injection through pattern matching. An AI agent examines the responses, determines the matching patterns, then generates unique variants designed to bypass those rules while maintaining the exploit's functionality. The variants evolve as the agent learns which approaches succeed.

The same pattern applies beyond SQL injection. AI agents can probe XSS filters, access controls, and input validation in the same systematic way. Each static rule becomes something the agent can test, infer, and work around.

By 2026, I estimate AI agents will drive over 50% of exploit attempts. The speed of this shift stems from three factors:

AI agents operate continuously, testing and learning 24/7
Successful exploits feed back into training data, improving future attempts
Agents share knowledge, building collective intelligence about bypass techniques

This is the practical limit of static security. Traditional WAFs that rely on fixed rules and signatures struggle to keep pace with AI-generated exploits. Each rule loses value as agents discover new bypasses.

The path forward requires a different security architecture. Organisations need context-aware systems that analyse intent, not just patterns. These systems use behavioural AI to distinguish between legitimate requests and exploit attempts, even when the request structure changes.

Key elements of this new approach include:

Intent analysis through deep inspection of request sequences
Behavioural modelling of normal vs malicious patterns
Real-time adaptation as new exploit techniques emerge
Proactive identification of potential vulnerabilities
Integration of threat intelligence across systems

The challenge intensifies when AI agents leverage residential proxies. These proxies route traffic through real consumer IP addresses, bypassing location-based blocks. An AI agent operating through residential proxies can probe defences while appearing to come from legitimate users worldwide.

This combination of AI-driven exploit generation and residential proxy networks makes traditional controls much less reliable. Organisations that continue to rely on static rules face a growing risk of compromise.

Security teams should respond now:

Audit existing WAF rules to identify pattern-based weaknesses
Deploy behavioural analysis capabilities to detect malicious intent
Implement adaptive security controls that evolve with threats
Monitor for AI-driven probing attempts
Build detection for residential proxy traffic

Teams that wait risk watching their defences get mapped and bypassed by automated agents. Static rules alone are not enough for this level of probing.

This also requires a shift in how we approach security. Rather than only blocking specific patterns, we need to understand and control the broader context of system interactions. The goal moves from "preventing known attacks" to "identifying and blocking malicious behaviour, regardless of its specific form."

Adaptive security systems need to reason about traffic in the same context-aware way as the agents probing them. Static rules still have a role, but they cannot be the centre of the defence.

Security strategy needs to account for this now, because AI-driven probing is no longer hypothetical.

The Reasoning Model Revolution

The emergence of open reasoning models like DeepSeek pushes this further. Unlike traditional AI that follows programmed patterns, reasoning models understand context and adapt strategies dynamically. That creates harder security problems.

Consider how a reasoning model approaches security testing. Rather than simply probing for weaknesses, it builds a conceptual model of the system's defences. It understands the purpose of security controls and reasons about potential bypasses. That allows it to generate novel attack strategies that were not present in training data.

DeepSeek demonstrates this shift. Within months of release, it showed capabilities matching established players at a fraction of the cost. This rapid progress comes from reasoning models' ability to understand and adapt, not just pattern match.

For security teams, that is a material challenge. Reasoning models do not just find gaps in rules. They infer why rules exist, deduce the logic behind security controls, and generate attacks that exploit underlying assumptions.

By 2027, I expect reasoning models to handle most security testing and exploit development. Their advantages prove too compelling:

They understand system architecture and security principles
They generate novel attack strategies through reasoning
They adapt in real-time based on system responses
They share and build upon successful approaches

This shift pushes traditional security approaches past their useful boundary faster than many teams expect. Pattern matching and rule-based systems cannot reliably counter an opponent that understands and reasons about their operating logic.

The combination of reasoning models with residential proxies is especially difficult to defend against. Reasoning models devise sophisticated attacks while proxies mask their origin. Each successful breach feeds back into the model's understanding, improving future attempts.

Security teams must embrace a new paradigm focused on:

Understanding attack narratives rather than patterns
Detecting anomalous reasoning rather than known signatures
Building systems that adapt to novel attack strategies
Implementing security that reasons about intent
Developing defences that evolve through adversarial learning

Security systems need to reason about threats as effectively as the AI agents probing them. Traditional approaches will fail against opponents that understand the logic behind security controls and devise creative bypasses.

The age of reasoning security has begun. Static rules and pattern matching are no longer enough on their own.

The question is how quickly security teams can move from fixed patterns to adaptive, intent-aware defence.

When Bots Are Your Primary Users

2025-02-12T14:00:00+11:00

APIs have mostly been designed for human developers first. Reasoning models like DeepSeek make that assumption weaker. If an agent can inspect an API, plan a sequence of calls, and adapt as it goes, it becomes a different kind of consumer.

That is the part worth paying attention to. Many APIs still assume a human-first model while AI agents become regular, and in some cases primary, users. These are not simple scraping bots or automation scripts. Modern AI agents can plan, reason, and change their behaviour. They interact with APIs in ways many teams did not account for when they wrote their OpenAPI specifications and documentation.

A human developer reads documentation, tries a few calls, and works through errors. An AI agent can process the whole API surface in seconds, generate thousands of possible interaction patterns, and test them systematically. That difference changes both API design and API security.

The issue is not limited to technical specifications. API logs already show traffic patterns that challenge older assumptions. AI agents do not follow typical "business hours" usage. They do not slow down because a workflow becomes cognitively heavy. They process responses at machine speed and chain API calls in ways human developers rarely attempt.

This shift forces us to rethink several core aspects of API design:

Structure and Format

Human-readable formats still matter, but they are not the only target. JSON and REST endpoints work well for developers who need to read and understand responses. For AI agents, there may be room for more efficient formats that optimise for machine processing rather than human comprehension.

Rate Limiting and Quotas

Most rate limiting models still assume human consumption patterns. AI agents operate at machine speed and scale. New models need to account for that processing capacity while still preventing abuse. That may mean moving from simple request counts to complexity-based quotas.

Authentication and Security

Traditional API keys and OAuth flows centre on human developers. AI agents need security models that account for how they operate. The hard problem is verifying the identity and intentions of an AI agent without weakening the security controls around the API.

Documentation and Discovery

API documentation still focuses on human understanding. For AI agents, machine-readable specifications need to go beyond OpenAPI. They should describe what endpoints do, not just how to call them.

This also changes how we monitor and maintain APIs. Traditional metrics like response time and error rates remain useful, but they do not explain AI agent behaviour on their own. How do we measure the "success" of an API when its primary users are machines that can adapt to problems and work around them?

Performance optimisation changes as well. A human developer might tolerate occasional latency. An AI agent can make thousands of calls per second, which puts more pressure on caching, edge computing, and response optimisation.

APIs are likely to split into two parallel tracks: human-oriented interfaces that prioritise developer experience, and machine-oriented interfaces optimised for AI consumption. This is not a choice between one audience and the other. It is recognition that they have different needs.

The challenge extends to business models. How do we price APIs when consumers are AI agents that can process information at machine scale? Traditional per-request pricing may not make sense when an AI can make millions of optimised calls that would take a human developer years to replicate.

Residential proxies add another layer of complexity. They allow AI agents to appear as regular users, making it harder to distinguish between human and machine traffic. That pushes API access control beyond IP-based rate limiting.

The ethical questions also matter. As APIs become primarily consumed by AI agents, teams need frameworks for responsible use. That includes asking how an API might be used inside AI systems, and what guardrails should sit around that access.

This is not about replacing human developers. It is about recognising AI agents as a new class of API consumer, with their own needs and capabilities. API design, security, and management all need to account for that.

The APIs we build today will sit under tomorrow's AI-driven systems. They need to be designed for both human and AI consumers, with clear decisions about discovery, access, rate limits, authentication, monitoring, and abuse controls.

The shift to AI-first API design is already under way. The practical question is how quickly API practices can catch up.

Our APIs have to evolve with their users.

Data-Driven Risk Management

2025-02-07T00:00:00+11:00

After our examination of Visa's Security Roadmap, this article looks at how Peakhour's contextual security approach supports Visa's third key focus area: shifting to a data-driven, risk-based approach.

The Evolution of Risk Management

Traditional security controls often rely on static rules and fixed thresholds. Visa's Security Roadmap 2025-2028 emphasises the need for dynamic, data-driven risk management that adapts to emerging threats while keeping operations efficient. That shift is important for attacks like credential stuffing and enumeration attacks, which exploit weak points in static defences.

Understanding Contextual Security

Contextual security moves beyond fixed rules by using real-time data analysis to assess risk and choose a proportionate response. It starts by collecting a broad set of signals for each interaction, including user behaviour patterns, device characteristics, network indicators like TLS fingerprints, geographic patterns, and historical trends.

Those signals feed a dynamic risk assessment engine with continuous monitoring and adaptive thresholds. Using techniques such as behavioural analysis and anomaly detection, the system can identify subtle deviations from normal activity that may signal a threat. The result is a response matched to the risk: triggering risk-based authentication, applying adaptive security measures, or initiating an automated threat response with customised rules.

How Peakhour Aligns with Visa's Vision

Our Contextual Security platform supports Visa's data-driven approach by combining multiple layers of defence. At the core is edge intelligence, which uses a global network to process data in real time, close to the user. This supports rapid identification of emerging threats, sharing threat intelligence across the network, and responding to attacks as they happen.

This is backed by advanced analytics that use machine learning models, behavioural analysis, pattern recognition, and anomaly detection. These tools are essential for identifying sophisticated threats, such as bots using residential proxies or anti-detect browsers. By analysing connection-level data, we can distinguish malicious automation from legitimate user traffic, a task traditional IP-based methods often fail.

This analysis supports risk-based decision-making. Instead of applying one-size-fits-all rules, our platform implements dynamic security measures. This includes adaptive authentication, contextual access controls, risk-based policies, and automated responses like advanced rate limiting, which can help stop distributed attacks.

Key Benefits of a Data-Driven Approach

Adopting a data-driven, contextual security model gives organisations practical advantages. It improves security through earlier threat detection and a reduction in false positives. The broader coverage protects against a wider range of attacks, from automated bots to manual fraud attempts.

At the same time, it can improve the user experience. By assessing risk more accurately, the system can reduce friction for legitimate users, support faster transactions, and make authentication less intrusive. This personalised security approach strengthens trust without sacrificing usability, a necessary balance for modern businesses.

Finally, this strategy improves operational efficiency. Automated responses reduce the need for manual review and intervention, optimising resource allocation. The scalable nature of the platform ensures that security can keep pace with business growth, providing a more sustainable way to manage risk.

Implementing Contextual Security

Organisations can implement contextual security by assessing their current state: reviewing existing controls, identifying data sources, and evaluating current capabilities. A planning phase then defines objectives, selects appropriate solutions, and establishes key performance metrics. Deployment follows, with systems installed, rules configured, staff trained, and performance monitored continuously.

To maximise effectiveness, teams need high-quality, real-time data collection while maintaining user privacy. They also need a robust analysis framework: well-defined risk models, adaptive thresholds, and clear policies for automation. Finally, response mechanisms should be practical to operate, with automated workflows and controls that can be monitored and refined over time.

Real-World Applications and Future Considerations

In practice, contextual security applies across several security workflows. For authentication, it enables risk-based multi-factor authentication and adaptive policies. In transaction monitoring, it allows for real-time analysis and fraud prevention. For access control, it supports dynamic permissions based on context-aware rules.

Looking ahead, organisations should prepare for the increasing role of advanced analytics, including AI and predictive analytics. Integration with other systems through APIs will be important, as will adapting to evolving regulatory requirements and new threat vectors.

Final Thoughts

The shift to data-driven risk management is an important change in security strategy. Peakhour's contextual security solutions help organisations align with Visa's vision while improving security, efficiency, and user experience. Moving beyond static rules to an adaptive defence gives businesses a better way to protect themselves and their customers in a more complex digital environment.

Learn how Peakhour's contextual security solutions can help your organisation implement data-driven risk management aligned with Visa's Security Roadmap 2025-2028. Contact our team to improve your security posture.

Did Residential Proxies enable a $600 Billion loss?

2025-01-31T00:00:00+11:00

The DeepSeek story puts residential proxy networks under scrutiny as a possible factor in AI's latest market disruption. In January 2025, the Chinese startup's emergence erased $600 billion from Nvidia's market value by demonstrating AI capabilities that match industry leaders at a fraction of the cost.

The path to this capability raises a practical security question for AI platforms. Leading platforms protect their APIs with multiple security layers - rate limiting to prevent mass data extraction, bot detection to block automated requests, and geoblocking to restrict access from certain regions. These measures are meant to prevent the systematic collection of training data.

Residential proxy networks create a route around those protections. These networks route traffic through household IP addresses, so requests appear to originate from homes in permitted regions. A request from a restricted location could look like legitimate traffic from Sydney, Melbourne, or Perth.

The circumstances suggest this approach is plausible. By distributing requests across millions of residential IPs worldwide, each IP could maintain human-like patterns while staying below rate limits. The aggregate data could form a substantial training set without triggering security alerts.

Meta's lawsuit against Bright Data strengthens this possibility. The case exposed how proxy providers monetise residential IPs, often without homeowners' knowledge. That model creates a global network capable of bypassing traditional security measures - exactly the type of infrastructure needed for large-scale data collection.

The residential proxy industry threatens $600 billion in business value through data theft and security bypasses. DeepSeek's impact on Nvidia's market capitalisation highlights the real-world impact of residential proxies.

For AI platforms, the question is operational. How can platforms distinguish between legitimate users and well-crafted requests through residential proxies? When geographical restrictions lose meaning, what security measures remain effective? Traditional IP Intelligence based proxy detection based on historical usage is no longer effective; per-connection proxy detection is essential.

DeepSeek's emergence suggests AI security teams need to revisit their assumptions. The potential use of residential proxy networks to dissolve digital borders challenges current approaches to platform protection.

Preventing Enumeration Attacks

2025-01-24T00:00:00+11:00

After our overview of Visa's Security Roadmap 2025-2028, this article looks at the first focus area: preventing enumeration attacks. Visa reports a 40% increase in enumeration attacks in the first six months of 2023 compared with the previous period, and more than US$1.1 billion in global fraud losses from these attacks over the year to 30 September 2023.

Visa defines enumeration and account testing as criminal practices where fraudsters use automation to test and guess payment credentials, which can then be used for fraudulent transactions. In card-testing campaigns, attackers send large numbers of low-value authorisation attempts to validate a primary account number, expiry date, or CVV2. They tend to target online merchants with weaker fraud controls because the merchant site becomes the testing ground while issuers, acquirers, and cardholders absorb the downstream damage.

The volume share can look small. Visa notes that these attacks contribute to less than 1% of global card-not-present volume. That can make the risk easy to underweight until the business sees the operating cost: processor scrutiny, chargeback pressure, support load, infrastructure spikes, blocked genuine customers, and fraud teams trying to reconstruct what happened after the card data has already been validated somewhere else.

The Risk Is Operational Before It Is Regulatory

Enumeration is not only a payment fraud pattern. It is a production traffic problem. The attack arrives as normal-looking checkout or payment API requests, often distributed across many IPs, accounts, devices, cards, and merchants. If the only defence is a fixed IP threshold, the attacker can slow down, rotate infrastructure, or push attempts through residential proxy networks that look closer to consumer traffic.

That is why Visa's roadmap points to authentication controls, anomaly detection, real-time monitoring, velocity thresholds, CVV2 for unsecure transactions, and retries with different values as indicators of account testing behaviour. The common thread is evidence. Teams need to see the pattern across attempts, not just one failed authorisation at a time.

For merchants and acquirers, the first decision is scope. Which routes can submit payment credentials? Which APIs can create checkout sessions, payment intents, or tokenisation requests? Which responses tell an attacker whether the credential is likely valid? Which logs show retries with changed values? Which controls can act before the traffic reaches the processor?

VAMP Raises the Need for Cleaner Evidence

Visa's updated Visa Acquirer Monitoring Program (VAMP) is effective 1 April 2025. In the roadmap, Visa says VAMP brings more aligned fraud thresholds for domestic and cross-border card-not-present transactions and incorporates new enumeration criteria based on the number of enumerated authorisation transactions and the enumeration rate identified by the VAAI Score.

That does not mean every merchant needs the same control design. It does mean acquirers and merchants need better visibility into whether a burst of payment activity is genuine demand, a broken integration, friendly fraud, or enumeration. When traffic is distributed, the evidence needs to include more than source IP. Useful signals include route, account state, card-attempt cadence, response codes, device or browser consistency, proxy likelihood, country and ASN changes, header and TLS patterns, and whether retries are changing only the values an attacker is trying to validate.

Peakhour's role is at the web and API edge. Bot Management, Advanced Rate Limiting, Residential Proxy Detection, WAF, and log forwarding can help teams detect automated payment attempts, slow or block abusive routes, identify proxy-backed traffic, and retain decision evidence. Those controls support a payment security program; they do not determine VAMP standing, replace acquirer guidance, or provide legal advice.

Rate Limits Need to Follow the Attack Shape

Simple rate limits still help, but card testing rarely follows one neat source. A useful rate limit strategy looks at multiple keys: route, payment action, account, session, token, card fingerprint where appropriate, device signal, IP, ASN, country, response result, and time window. The limits should also distinguish between customer actions. A checkout page, card add route, refund path, gift card purchase, and payment authorisation API should not all share one generic threshold.

Teams also need to decide what the control does. Some traffic should be blocked. Some should be slowed. Some should be challenged before payment. Some should be logged and reviewed because false positives would create more harm than the risk being reduced. The right action depends on business context, fraud exposure, customer value, and the confidence of the signals.

Residential proxy abuse is a good example. A residential IP does not prove fraud. Many genuine users sit behind shared or mobile networks. But residential proxy use combined with high-cardinality card attempts, changed CVV2 values, first-seen devices, failed authorisations, and unusual checkout cadence is a stronger signal. The value is correlation, not a single magic indicator.

A Practical Review Path

Teams preparing for enumeration risk should start with the payment routes rather than with a vendor checklist.

Map every route that can create, submit, modify, or retry a payment attempt.
Review response messages and status codes for accidental validation clues.
Check whether logs can show velocity, retries with changed values, and route-level concentration without storing sensitive card data.
Apply route-aware rate limits and bot controls before processor calls where possible.
Add proxy, device, session, and behaviour signals to separate normal checkout friction from testing behaviour.
Keep evidence of policy version, action, route, and signal set so fraud and compliance teams can review outcomes.

The caution is important: do not turn payment logging into a second store of cardholder data. Enumeration defence needs enough evidence to detect and investigate abuse, but PCI DSS and privacy expectations still require careful handling of cardholder data, tokens, logs, and support exports.

What This Means for Peakhour Customers

Enumeration prevention is not a single feature. It is a control path around payment routes: classify the request, evaluate the signals, act proportionately, and keep evidence. Peakhour can help by applying those decisions at the edge before abusive traffic reaches the origin or payment integration.

The business value is not only fewer bad requests. It is cleaner payment telemetry, faster fraud review, fewer avoidable processor calls, and a better basis for conversations with acquirers when suspicious activity appears. Visa's roadmap makes that direction clear: payment security is moving toward data-driven, evidence-backed controls that can recognise automation abuse without blocking genuine customers by default.

Managing Bots For Application Security

2024-09-15T00:00:00+10:00

This guide separates bot management into three maturity levels: basic, intermediate, and advanced. The point is not to rank feature lists. It is to understand what kind of bot decision each level can safely make on the request path.

Bots now target revenue, data, accounts, inventory, APIs, and origin capacity. Some are obvious crawlers. Others run credential stuffing, account creation, scraping, inventory hoarding, click fraud, or Layer 7 pressure through traffic that looks close to normal. A useful bot control has to decide whether to allow, challenge, rate limit, block, log, or review a request without punishing legitimate users who happen to share a network or device pattern.

For more on account impact, read our article on the Business Impact of Credential Stuffing.

Basic Protection

Basic bot management is built around visible signals: user-agent checks, simple IP reputation, known bot signatures, and broad rate limits. These controls still have a job. They can manage well-behaved crawlers, block obvious automation, and stop a single noisy source from hammering a site.

The limitation is that basic controls assume the source or header tells most of the story. That breaks down when automation behaves like a browser, rotates infrastructure, or spreads requests across residential and shared networks. A flat IP limit may slow one scraper and still miss a credential attack distributed across many exits. It may also catch real users behind a busy office, mobile carrier, or public Wi-Fi network.

Basic protection is suitable when the risk is low, the main concern is crawler hygiene, and the business can tolerate coarse controls. It is not enough for account protection, high-value scraping targets, or API workflows where abuse can arrive through valid requests.

Intermediate Protection

Intermediate bot management adds more request and client evidence. JavaScript signals, header consistency, cookie behaviour, basic network fingerprints such as TLS fingerprinting, and route-level observations make the decision less dependent on the IP address alone. This level can catch automation that fails to behave like a normal browser or that exposes inconsistencies across requests.

It is a meaningful step up, but it still has limits. Anti-detect browsers and modern automation can keep browser signals plausible for long enough to run a campaign. Residential proxy networks can make source reputation noisy. API requests may not run browser-side checks at all. If the bot system treats browser, route, credential, and API context as separate problems, operators end up tuning several partial controls rather than one decision.

Intermediate protection works for general scraping, noisy automation, and non-persistent abuse. It starts to struggle when attackers adapt, slow down, distribute requests, or target sensitive routes where a small number of requests can cause business harm.

Advanced Protection

Advanced bot management is combined signal decisioning. The difference is not "more techniques" in a checklist. The difference is that IP intelligence, residential proxy status, network and browser fingerprints, route-specific rates, behaviour, credential risk, API context, WAF/WAAP findings, DDoS pressure, and logs feed the same action model.

That context changes the decision. A high request rate on a public image route is not the same as repeated failed logins. A suspicious proxy signal on a cached page is not the same as the same signal on account recovery. A browser fingerprint mismatch may be logged on a low-risk page but challenged when paired with exposed credentials and rapid account switching.

Advanced protection is designed for persistent abuse: credential stuffing, account takeover attempts, scraping at scale, inventory hoarding, fake account creation, API bot traffic, and bot-driven Layer 7 floods. It should support web, mobile, and API traffic, and it should preserve evidence so security, platform, and support teams can see which signal drove an action.

Choosing the Right Level

The right level depends on what the bot can damage. A brochure site may only need crawler management and basic rate limits. An ecommerce site needs protection for search, product, checkout, promotion, and account routes. A marketplace, bank, gaming platform, ticketing site, or API-heavy business usually needs route-aware decisions that combine proxy, fingerprint, credential, account, and behaviour context.

The false-positive risk matters just as much as the attack risk. Shared networks, carrier-grade NAT, privacy tools, corporate egress, and normal browser drift can all make a simple signal look suspicious. A mature bot programme does not block every unusual request. It uses uncertainty to pick safer actions: log, challenge, rate limit, or review before escalating to a block.

Peakhour's View

Peakhour's Bot Management connects bot decisions to the rest of the application security path. Residential Proxy Detection, IP Intelligence, Advanced Rate Limiting, API Security, WAAP/WAF controls, and Log Forwarding all support the same request outcome: allow, challenge, rate limit, block, log, or review with evidence.

That is the practical maturity model. Basic controls handle obvious bots. Intermediate controls add client and request evidence. Advanced controls combine signals into decisions that match the route, risk, and business impact.

The Challenge of Proxy Detection

2024-07-19T10:00:00+10:00

Our recent survey found that only 15% of Australian organisations use residential proxy detection. That leaves many teams relying on controls that were not built for current proxy traffic, especially where CGNAT and NAT make IP-level decisions unreliable.

The Shortcomings of Traditional Methods

Legacy bot protection providers often combine IP reputation, network characteristics, header analysis, and JavaScript-based checks to identify proxy usage. These methods struggle against well-run residential proxies:

IP and ASN categorisation: Ages quickly as new proxy networks emerge.
Network-level checks: Well-configured proxies can work around them.
Header analysis: Proxies can alter HTTP headers to mimic legitimate traffic.
JavaScript-based detection: Struggles against headless browsers and leaves API endpoints vulnerable.

The CGNAT and NAT Challenge

A practical limit of traditional methods is their inability to distinguish legitimate traffic from proxy traffic when both originate from the same IP address. Carrier-Grade NAT (CGNAT) and Network Address Translation (NAT) make this common:

CGNAT: Used by ISPs to conserve IPv4 addresses, resulting in multiple users sharing a single public IP.
NAT: Commonly used in home and business networks, allowing multiple devices to use one public IP address.

As a result, legitimate users and residential proxy traffic can appear to come from the same IP address. IP reputation and geolocation alone cannot separate these traffic types.

This creates a difficult tradeoff:

Blocking suspicious IPs risks denying service to legitimate users.
Allowing all traffic from these IPs opens the door to potential abuse via residential proxies.

Traditional methods cannot reliably pull apart these different types of traffic, so teams either block too much legitimate traffic or allow too much proxy traffic through.

The Need for Sophisticated Network Fingerprinting

To detect and mitigate residential proxy threats while allowing legitimate traffic from shared IPs, detection needs to move beyond IP identity. Network fingerprinting addresses the limits of traditional methods:

Deep packet inspection: Analyses traffic patterns and characteristics beyond basic IP or header indicators.
Protocol behaviour analysis: Identifies subtle anomalies in how network protocols are implemented across the proxy chain.
TLS fingerprinting: Examines unique characteristics of TLS handshakes to detect proxy usage.
Timing analysis: Measures small differences in network latency that can indicate the presence of a proxy.

Used together, these techniques can detect proxy usage on a per-connection basis for both web traffic and API calls, even when traffic originates from shared IP addresses. This approach provides several advantages:

Improved accuracy: Significantly reduces false positives and negatives compared to traditional methods, including in CGNAT and NAT scenarios.
API protection: Secures API endpoints, which are often overlooked by JavaScript-based solutions.
Real-time detection: Allows for immediate action against detected proxy usage without impacting legitimate users.
Adaptability: Can be updated to detect new proxy technologies as they emerge, regardless of IP sharing.

Implementing Effective Proxy Detection

To implement proxy detection that accounts for modern network complexity, organisations should consider the following:

Deploy solutions that use network fingerprinting techniques capable of distinguishing between different types of traffic from the same IP.
Ensure protection covers both web applications and API endpoints, as both are vulnerable to proxy-based attacks.
Implement real-time mitigation capabilities to respond swiftly to detected threats without impacting legitimate users.
Regularly update and tune detection algorithms to keep pace with evolving proxy technologies and network architectures.

Together, these practices improve an organisation's ability to detect and mitigate residential proxy threats across credential stuffing, account takeover, and related activity, while keeping access available for legitimate users.

Learn more about our proxy detection solution, which uses network fingerprinting to address the challenges posed by CGNAT and NAT.

For more detail, explore our learning resources:

As proxy technologies and network architectures change, detection and mitigation need to change with them. Network fingerprinting gives organisations a more reliable way to identify residential proxy abuse without treating every shared IP as suspicious.

Account Protection and User Experience in Web Applications

2024-07-17T10:00:00+10:00

Web applications face a wide range of security threats, but customer accounts are often the target. Our recent survey of Australian businesses showed a need for stronger account protection measures. Those controls can add friction for users if they are applied too broadly. This article looks at ways to balance security with user experience in web applications.

The Challenge: Compromised Credentials

Our survey found that 21% of organisations cited reputation loss as their main cybersecurity challenge. That result points back to a practical security problem: compromised credentials.

Causes of compromised logins include:

Phishing attacks
Password reuse across multiple sites
Data breaches exposing user credentials
Credential stuffing attacks
Keylogging malware

These risks make password-only authentication a weak control for customer account protection.

Moving Beyond Traditional Multi-Factor Authentication

Multi-Factor Authentication (MFA) adds a useful security layer, but it can also add friction. Our survey found that only 40% of organisations implement bot protection, which leaves a clear gap around automated attacks.

While 77% of surveyed businesses use MFA, that figure can hide other weaknesses. MFA alone doesn't protect accounts from every attack path.

Learn more about the limitations of traditional MFA

Contextual Security: A User-Focused Approach

Contextual security helps reduce that tradeoff between protection and user experience. It assesses the risk of each login attempt using factors including:

Location of the login attempt
Time of day
Device used
User behaviour patterns
IP address reputation
Network characteristics

By analysing these contextual factors, web applications can apply adaptive authentication without asking every user to complete an extra step every time.

Figure 1: Key factors considered in contextual security

Implementing Contextual Security in Web Applications

To improve account protection without adding unnecessary friction, consider these controls:

Real-time monitoring: Track user activity and detect anomalies.
Adaptive authentication: Adjust security requirements based on the risk level of each login attempt.
Behavioural analysis: Use machine learning to understand user behaviour and flag suspicious activity.
Transparent security measures: Apply checks that don't require additional user actions for low-risk scenarios.
Risk-based access controls: Apply stricter security measures for high-risk actions or sensitive data access.
Bot protection: Detect and mitigate automated attacks.
API security: Protect APIs from abuse and unauthorised access.
Residential proxy detection: Identify and mitigate threats from residential proxy networks.

For web applications, the goal is targeted control rather than blanket friction.

The Role of User Education

User education still has a place in a security strategy. Training and awareness programs can help users understand:

The importance of strong, unique passwords
How to identify phishing attempts
The risks of password reuse across multiple sites
The importance of keeping software and devices updated
How to recognise and report suspicious activities

User education works best when it supports technical controls rather than carrying the whole burden.

Addressing Mobile Application Security

Our survey indicates a potential gap in mobile security strategies. As mobile apps take on operations like banking and e-commerce, they become part of the application attack surface.

Only 30% of respondents implement Web Application and API Protection (WAAP), indicating many businesses may not be ready to protect their mobile assets. That gap leaves mobile applications exposed to attacks, including API abuse and data exfiltration.

The Threat of Residential Proxies

Our survey found that only 15% of organisations use residential proxy detection. That low adoption rate leaves a weakness in many businesses' security postures.

Residential proxies can threaten account security by:

Bypassing traditional IP-based rate limiting
Evading geolocation-based restrictions
Facilitating large-scale credential stuffing attacks
Enabling undetected data scraping

Businesses should consider security providers that can detect and mitigate residential proxy threats.

Learn more about residential proxy detection

Finding the Balance

Balancing account protection and user experience in web applications requires more than a single control. By implementing contextual security measures, organisations can:

Improve security without unnecessary impact on user experience
Adapt to threats in real-time
Reduce the risk of compromised credentials and account takeovers
Protect against threats like residential proxies and mobile application vulnerabilities

As threats change, account protection needs to change with them. Contextual security gives organisations a practical way to protect users and their reputation.

2024 Survey Insights

2024-07-16T10:00:00+10:00

Our recent survey of Australian CISOs and CTOs looked at account protection controls, planned security measures, and how teams are responding to credential stuffing and residential proxies. Key findings:

Multi-Factor Authentication (MFA) Adoption: 76.23% of Australian businesses use MFA, showing broad adoption of a baseline account security control.
Bot Protection: Currently implemented by 39.34% of organisations, with an additional 34.65% planning to adopt it.
Bot Management Solutions: Cloudflare is the most common bot management provider in the survey, used by 48.24% of respondents.
Residential Proxy (Resip) Detection: Only 13.11% of organisations currently use this technology, although many plan to implement it to address residential proxy traffic.
Credential Stuffing Concerns: Businesses are planning measures to reduce credential stuffing risk, including bot protection, MFA, and checking credentials against known breaches.
Mobile Security Gap: Low adoption of Web Application and API Protection (WAAP) suggests gaps in mobile application security.
Executive vs. Engineer Priorities: The survey showed different cybersecurity priorities between executives and engineers.

These findings point to the need for account protection strategies that go beyond MFA and address automated traffic, breached credentials, and residential proxies.

2024 Survey Insights

2024-07-16T10:00:00+10:00

Recent customer account takeovers have put account protection back on the agenda for Australian businesses. Our 2024 survey of Australian CISOs and CTOs shows how respondents are using MFA, bot protection, WAAP and residential proxy detection to manage credential stuffing and account takeover risk.

Account Protection: Current State and Future Plans

Our survey found 76.23% of Australian businesses use Multi-Factor Authentication (MFA). MFA is widely adopted, but it is not a complete account protection strategy on its own.

39.34% of organisations currently use bot protection. That matters because credential stuffing is automated by design. Another 34.65% of businesses plan to implement bot protection in the future.

The pattern is clear: many organisations are treating MFA as a baseline and looking at additional controls around it.

Current Bot Management Solutions

The survey also asked which bot management solutions Australian businesses currently use. Cloudflare was the clear leader, with nearly half of respondents using its services.

The breakdown of bot management solutions is as follows:

Cloudflare: 48.24%
AWS WAF Bot Ruleset: 10.59%
Other solutions make up the remaining percentage

This distribution is concentrated around Cloudflare. Outside that, the remaining respondents are spread across other solutions rather than one clear alternative.

Tooling matters here. Residential proxy traffic weakens IP reputation and simple rate limits, so detection capability, request grouping and response controls matter as much as vendor name. If residential proxies continue to feature in credential stuffing tooling, this mix may shift as teams look for more advanced protection measures.

The Rising Threat of Residential Proxies

A key finding from our survey is the low adoption rate of residential proxy (resip) detection, with only 13.11% of organisations currently using this technology. Planned adoption suggests teams are starting to account for the risk, but current coverage is still low.

Resips are difficult for account security teams because malicious traffic can look like normal ISP traffic. They enable attackers to:

Bypass traditional IP-based rate limiting
Evade geolocation-based restrictions
Conduct large-scale credential stuffing attacks
Scrape sensitive data undetected

The planned adoption of resip detection points to a shift in security strategies, away from simple IP-based controls and towards more specific network signals.

Learn more about the threat of residential proxies and how to detect them

Credential Stuffing: A Persistent and Growing Concern

Credential stuffing attacks continue to be a major concern for businesses. These attacks exploit password reuse across multiple sites, allowing attackers to gain unauthorised access to user accounts.

Respondents said they plan to implement several measures to reduce credential stuffing risk:

34.65% plan to implement bot protection
32.67% intend to add multi-factor authentication
31.68% aim to check credentials against known breaches

These plans point to layered account protection rather than reliance on one control.

Mobile Applications: An Emerging Attack Surface

While mobile applications were not directly addressed in our survey, the data suggests a possible gap in mobile security strategies. The low adoption rate of Web Application and API Protection (WAAP) - implemented by only 27.87% of respondents - indicates many businesses may be underprepared to protect their mobile assets.

As mobile apps become primary interfaces for critical operations, this gap leaves businesses exposed to attacks that use the same automation and resip infrastructure seen on web login flows.

Balancing Security and User Experience

The operational problem is familiar: increase assurance without making login unusable. Key considerations for enhancing account protection while preserving usability include:

Expanding beyond MFA
Implementing bot protection
Adopting WAAP solutions
Monitoring credential leaks
Focusing on API security
Implementing residential proxy detection

Explore strategies for balancing security and user experience

Executive vs Engineer Perspectives

Our survey found differences in cybersecurity priorities between executives and engineers:

Figure 3: Comparison of cybersecurity priorities between executives and engineers

The gap matters because budget, architecture, and incident response are often owned by different teams. Account protection plans need to cover both executive risk concerns and engineering realities, including the threat from RESIPs.

Final Thoughts

Our 2024 survey results point to a simple position: MFA is widely used, but it is not the whole account protection strategy. Bot protection, breached credential checks, WAAP and residential proxy detection are still unevenly adopted. That matters because credential stuffing does not depend on one weakness; it combines reused credentials, automation, proxy networks and weak response controls.

Australian businesses do not need every control at once, but they need a layered plan that reflects how account takeover attacks are run now. For teams reviewing their controls, resip detection and mobile/API coverage are worth checking explicitly because both are easy to miss if the programme is still centred on MFA and IP reputation.

Application Security Beyond MFA

2024-07-15T10:00:00+10:00

Multi-factor authentication (MFA) remains a useful defence against account takeovers, but it is not a complete control. Attackers increasingly work around MFA with social engineering, automation, and infrastructure that makes malicious traffic look ordinary.

MFA answers one narrow question: can the user present a second factor at this point in the flow? That is valuable. It does not prove the password was safe, the session will remain safe, the device is trusted, or the person entering the code has not been manipulated. Account protection needs to cover the request path before MFA, around MFA, and after MFA.

OTP Bots Target the Human, Not the Cryptography

A Kaspersky article describes the rise of OTP bots: tools that call or message users and convince them to hand over one-time passwords. The attacker does not need to break the MFA system. They need the victim to read out a fresh code at the same moment the attacker is logging in.

The usual flow is simple. The attacker obtains a working username and password from a breach, phishing kit, or credential stuffing result. They attempt a login, which triggers an OTP. The victim receives a call or message claiming to be from the bank, retailer, courier, or support team. The story is urgent enough to make the code feel like part of protecting the account, not compromising it.

AI phone assistants such as Lucy are built for legitimate business use, but similar conversational technology lowers the effort required to run more convincing criminal call flows. The security issue is not that AI magically defeats MFA. It is that a fluent, responsive call can make social engineering less scripted and harder for a user to dismiss.

This is why "we have MFA" should not end the account protection conversation. MFA can stop many stolen-password logins, but it cannot reliably stop a user from being tricked in real time.

Residential Proxies Weaken the Surrounding Checks

Attackers also work to make the login itself look unremarkable. Residential proxies route traffic through IP addresses assigned to ordinary home or mobile internet connections. That lets malicious traffic borrow the appearance of normal customer traffic.

Traditional controls often lean too heavily on IP address, geolocation, and request volume. Residential proxy networks weaken all three. An attacker can rotate through many IPs, keep each source below a simple rate limit, and choose an exit location that roughly matches the victim's country or city. If the login looks local enough, the MFA challenge may be the only control left.

That is a poor place to put all the risk. A login with a correct password, a plausible IP address, and a successful OTP can still be an account takeover. The system needs to keep evaluating the request: device and browser signals, network fingerprint, known breached credentials, velocity across accounts, and behaviour after login.

Automation Happens Before and After MFA

MFA is usually visible at the point of login, but account takeover campaigns are broader than one prompt. Bots test credential pairs across login forms and APIs. Tools such as OpenBullet and similar automation frameworks can replay login flows at scale. Breached credential lists give attackers a cheap starting point because password reuse remains common.

Once an attacker gets through, the next actions matter. They may change the email address, add a device, disable notifications, alter delivery details, use stored payment methods, transfer value, or test what the account can access. If monitoring treats a successful MFA as the end of risk, those actions can happen inside a trusted session.

The defence needs to be layered around the actual attack path:

Check credential risk before and during login, especially known breached username and password pairs.
Use bot and browser signals to detect automation even when traffic is distributed.
Rate limit on better keys than IP alone, such as TLS or HTTP/2 fingerprints, headers, routes, ASNs, countries, and account behaviour.
Treat residential proxy evidence as a risk input, not just an allow-or-block label.
Monitor session and account changes after MFA, then challenge, hold, revoke, or review when behaviour changes.

This does not mean every login needs more friction. It means the system should have more choices than "ask for MFA" or "allow". A low-risk login from a known device can keep moving. A login using breached credentials through proxy infrastructure can be slowed, challenged, or blocked before the user receives a confusing call. A successful login followed by high-risk account changes can trigger fresh verification or session invalidation.

Controls Around MFA

Peakhour's Advanced Rate Limiting helps reduce reliance on IP address by grouping and limiting requests using signals such as HTTP/2 and TLS fingerprints, ASNs, countries, request headers, and route context. That matters when credential stuffing is spread across residential proxies.

Peakhour's Bot Management adds another layer by looking for automation, browser inconsistency, suspicious device patterns, and residential proxy use. The aim is to identify the machinery behind the attack before it becomes a clean-looking login attempt.

Peakhour's Account Protection brings those signals closer to the account decision. Breached credential checks, bot evidence, rate limits, proxy context, custom rules, and monitoring should all feed the decision to allow, challenge, rate limit, block, log, or review.

User education still has a place, especially around OTP sharing and unexpected calls. It should not be the main control. Users are asked to make security decisions at bad moments, often under pressure, with limited context. Technical controls should reduce the number of times an attacker can create that moment.

MFA Still Belongs in the Stack

The point is not to remove MFA. Strong MFA, especially phishing-resistant methods, raises the cost of account takeover and should remain part of the stack. The mistake is treating MFA as proof that the account is safe.

Account protection works better when MFA is one decision point inside a wider system. The login attempt, credential history, network path, device, session, account changes, and transaction behaviour all carry evidence. MFA is useful evidence. It is not the whole case.

Addressing Key Cloud Security Categories

2024-05-01T10:00:00+10:00

A recent Scale Venture Partners analysis sets out emerging opportunities in cloud security after Wiz. Peakhour is a reverse proxy rather than a cloud control-plane product, but it addresses several of these categories and covers related security needs at the application edge.

Cloud Security Posture Management (CSPM)

The analysis identifies CSPM as a key category in cloud security. Peakhour is not a traditional CSPM, but it contributes to security posture management through:

Traffic Analysis: Peakhour analyses incoming traffic patterns to identify potential security risks.
Configuration Recommendations: Peakhour recommends security configuration improvements based on observed traffic patterns.

Cloud Workload Protection Platform (CWPP)

The article notes that CWPP products provide granular protection for cloud workloads. Peakhour contributes to workload protection through:

Application-Layer Filtering: Peakhour filters traffic at the application layer to protect cloud workloads.
Real-Time Threat Detection: Peakhour detects and blocks threats in real-time.

Cloud Detection & Response (CDR)

CDR focuses on detecting, investigating, and responding to incidents. Peakhour supports CDR work via:

Log Generation: Peakhour generates detailed logs of all traffic for incident investigation.
Anomaly Detection: Peakhour detects anomalous traffic patterns that indicate security incidents.
Automated Response: Peakhour responds to detected threats by blocking malicious traffic.

Cloud-Native Application Protection Platform (CNAPP)

The analysis defines CNAPP as a combination of CSPM, CWPP, and CDR. Peakhour aligns with that model through:

Integrated Security: Peakhour provides a single platform for traffic filtering, threat detection, and response.
Application-Centric Protection: Peakhour's reverse proxy design protects cloud-native applications at the application edge.

Cloud Infrastructure Entitlement Management (CIEM)

Peakhour does not directly manage cloud infrastructure entitlements, but it complements CIEM efforts through:

Access Pattern Analysis: Peakhour analyses access patterns to applications, providing insights that can inform entitlement decisions.

Non-Human Identity (NHI)

The article highlights the growing importance of managing non-human identities. Peakhour contributes to this area by:

Service-to-Service Communication Monitoring: Peakhour monitors and controls service-to-service communication.

Remediation Ops (RemOps)

RemOps focuses on managing the growing volume of security alerts. Peakhour supports RemOps through:

Alert Aggregation: Peakhour aggregates security events from traffic analysis into usable alerts.
Prioritisation: Peakhour prioritises alerts based on threat severity and potential impact.

Additional Peakhour Capabilities

Peakhour also addresses cloud security needs outside the categories covered in the Scale VP analysis:

DDoS Protection

Peakhour provides DDoS protection via:

Layer 7 Rate Limiting: Peakhour protects against application-layer DDoS attacks.
Traffic Anomaly Detection: Peakhour identifies and mitigates DDoS attacks in real-time.

Content Delivery Network (CDN)

Peakhour's delivery and cache functionality reduces cloud load and traffic bills through:

Traffic Optimisation: Peakhour reduces load on origin servers and decreases traffic bills.
Geographic Distribution: Peakhour serves content from geographically distributed nodes.

Bot Management

Peakhour manages bot traffic through:

Bot Detection: Peakhour identifies bot traffic.
Policy Control: Peakhour implements policies for managing different types of bots.
Automated Mitigation: Peakhour applies countermeasures against malicious bot activity.

Cloud Visibility

Peakhour addresses visibility gaps in modern cloud environments:

Traffic Insights: Peakhour provides detailed insights into front-end traffic patterns.
Real-Time Analytics: Peakhour delivers real-time analytics on traffic, threats, and application behaviour.

Final Thoughts

Peakhour addresses several categories identified in the Scale VP analysis of emerging cloud security opportunities. It also covers adjacent needs at the application edge, where traffic, threats, bots, delivery, and visibility meet.

See how Peakhour's Application Security Platform addresses key areas of modern cloud security. Contact our team to strengthen your cloud security posture.

Managing Breached Credential Usage

2024-03-15T00:00:00+11:00

Credential stuffing attacks remain a common way to take over accounts on applications and APIs. For DevOps, SRE, and DevSecOps teams, the problem is not just whether a password is correct. It is whether the login attempt carries signs of automation, credential reuse, or known compromise. Effective account protection needs breached credential checks alongside contextual risk analysis.

Breached Credential Databases and Risk Profiling

Modern Application Security Platforms can use breached credential intelligence containing billions of leaked username and password combinations from historical data breaches. Used at login time, this gives security teams an immediate signal that an account may be at higher risk, even before there is confirmed account takeover activity.

Enterprise Credential Intelligence

Peakhour's Application Security Platform includes Breached Credentials protection designed to work with existing authentication systems. The platform provides:

Real-Time Credential Checking: Validation against breached credential data during login attempts
API-Native Integration: Integration with authentication services and identity providers
Privacy-Preserving Verification: Hashing mechanisms that protect user privacy whilst enabling threat detection
DevSecOps Compatibility: RESTful APIs for security automation and CI/CD workflows

Building Statistical Models

To detect credential stuffing, organisations need a baseline for normal breached credential use. This typically involves:

Collecting data from API and login endpoint attempts
Aggregating data using device fingerprints
Analysing login patterns and credential use frequency
Establishing baselines for typical user behaviour

These models show how often breached credentials appear in normal login traffic, and when the pattern starts to look like automated testing rather than ordinary user behaviour.

Application Security Platform Integration

Breached credential checks are most useful when they feed into the rest of the application security stack:

Multi-Layer Defence Strategy

Edge Processing: Credential validation at the CDN edge
API Protection: Coverage for both web applications and mobile APIs
Bot Management Integration: Correlation with bot detection systems to identify automated credential testing
Rate Limiting Coordination: Rate limits adjusted by credential risk

DevSecOps Operational Excellence

Security Automation: Response workflows for high-risk credential attempts
Compliance Reporting: Audit logging and monitoring for security reviews
Threat Intelligence Feeds: Updates from breach monitoring
Custom Rule Engine: Policy configuration for organisation-specific requirements

Conclusion

Breached credential protection is one part of account takeover defence. On its own, it can show that a password has appeared in a breach. It should sit alongside broader controls such as bot management, rate limiting, API protection, and DDoS mitigation, while still giving teams a clear basis for deciding whether to block, challenge, or monitor a login attempt.

The practical goal is to make credential risk visible at the point of authentication without treating every user as suspicious. That requires breached credential checking to be part of the login flow, not a separate report reviewed after the attack has already run.

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.

HTTP Security Headers

2023-11-28T14:00:00+11:00

Traditionally, web security has focused on the server side: protecting the application itself from attack. That work is necessary, but it often leaves the client side under-specified. Client-side attacks move the exposure point into the user's browser, where the business impact can be serious.

Magecart attacks are a clear example. Attackers inject skimming scripts into websites to steal sensitive customer information, such as credit card details, directly from the user's browser. Session hijacking and Cross-Site Scripting (XSS) attacks also exploit browser vulnerabilities, leading to unauthorised access and data breaches. These attacks don't just risk user data; they can erode trust, damage reputations, and result in significant financial and legal repercussions for businesses.

HTTP security headers are practical controls for these types of attacks. Properly implemented, they instruct browsers on how to handle website content and interactions safely.

Key HTTP Security Headers

Content-Security-Policy (CSP)

Purpose: CSP prevents Cross-Site Scripting (XSS) attacks by specifying which sources browsers should allow when loading scripts, images, and other resources. It can also prevent MageCart-style attacks by restricting the host names that an injected script can communicate with.

Content-Security-Policy: script-src 'self' https://apis.google.com;

This example allows scripts to load only from the site's own domain ('self') and https://apis.google.com.

X-Frame-Options

Purpose: This header protects against clickjacking attacks by controlling whether a browser allows a page to be rendered in a <frame>, <iframe>, <embed>, or <object>.

X-Frame-Options: DENY

This setting prevents any domain from framing the content. Another option is SAMEORIGIN, which only allows framing by the same site.

X-Content-Type-Options

Purpose: This header prevents MIME-sniffing, where a browser might incorrectly interpret the content type of a resource, leading to security vulnerabilities.

X-Content-Type-Options: nosniff

This instructs the browser to follow the content type declared in the HTTP headers.

X-XSS-Protection

Purpose: This enables the browser's inbuilt XSS protection features. However, this header is largely deprecated in favour of CSP.

X-XSS-Protection: 1; mode=block

This configuration enables the protection and tells the browser to block the page if an XSS attack is detected.

Strict-Transport-Security (HSTS)

Purpose: HSTS forces the browser to use HTTPS over HTTP, ensuring encrypted communication and protecting against man-in-the-middle attacks. Alternatively, you can automatically redirect all requests to HTTPS on your web server or at your EDGE provider. For example, Peakhour allows you to set up EDGE redirects to force all traffic to HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains

This example tells the browser to use HTTPS for all subdomains for one year.

Conclusion

Implementing the correct HTTP security headers is a straightforward way to improve web application security. These headers form part of the first line of defence against many common security vulnerabilities. As threats evolve, keeping security headers current and properly configured helps safeguard your users and your brand.

Google Chrome's "IP Protection" vs Apple Private Relay

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

Google Chrome's "IP Protection" vs. Apple's iCloud Private Relay

Google and Apple are both pushing browser-level privacy features that reduce how much a website can infer from a user's IP address. Google's recent announcement of its "IP Protection" feature for Chrome follows Apple's iCloud Private Relay, but the two approaches are not the same.

Apple's iCloud Private Relay: A Closer Look

In 2021, Apple introduced iCloud Private Relay for paid iCloud+ subscribers. The feature encrypts traffic from the user's device and routes internet requests through two separate relays. The intention is to stop any single party, including Apple, from building a comprehensive user profile from IP address, location, and browsing activity.

However, this feature is specific to Apple's Safari browser. It is not a full VPN; it is a browser-centric service that protects Safari traffic on iOS, iPadOS, and macOS. The user's internet requests are routed first through an Apple server, then through a partner network like Akamai, Cloudflare, or Fastly, before reaching the intended destination. This dual-hop design means neither party has a complete view of both the user's IP address and the browsing destination.

Google's "IP Protection": Playing Catch-up?

Google's "IP Protection" for Chrome appears to be an answer to Apple's initiative. By masking users' IP addresses using proxy servers, Google aims to preserve user privacy while keeping essential web functions working. Unlike Apple's solution, which is limited to Safari, Google's feature potentially has wider application within the Chrome ecosystem.

However, Google's solution is still early, with phased implementation and limited domain application. Apple has already integrated and offered iCloud Private Relay to its users; Google is still testing its feature.

Can Apple Allow Google's Feature on Chrome?

Given the competitive nature of the technology industry, it remains uncertain whether Apple will allow Google's IP Protection feature on Chrome for Apple devices. With iCloud Private Relay already in place, Apple may see Google's feature as redundant or conflicting with its privacy objectives.

The Bigger Picture: Ad Tracking and Platform Control

Both companies present these changes as privacy improvements, but the platform context matters. Hiding IP addresses does not remove ad tracking, and privacy features can also reinforce platform control. By making privacy protections part of their own browsers and ecosystems, Google and Apple can reduce some third-party visibility while keeping users inside platforms they operate and measure.

Apple's iCloud Private Relay and Google's "IP Protection" both improve some aspects of user privacy, with different approaches and coverage. As Google plays catch-up to Apple in this area, users should understand what these features do and what they leave in place. The goal should be genuine online privacy, and as we've discussed in our article on TLS fingerprinting, network-based fingerprinting is becoming increasingly important for protecting services in this changing environment.

Google Chrome's "IP Protection" and Online Privacy

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

Google plans to introduce an "IP Protection" feature in Chrome. The feature is intended to improve privacy by masking IP addresses through proxy servers. It may also affect ad tracking and who controls access to online platforms.

Understanding IP Addresses and Google's Strategy

IP addresses can let websites follow user activity across platforms. Over time, that can build detailed profiles and create real privacy concerns. Google's "IP Protection" is designed to reduce that signal by sending third-party traffic through proxies, hiding user IPs. The feature will start as optional, then focus on domains thought to track users.

At first, Google will use a dedicated proxy for its own domains. As testing continues, the system may change. Google is also considering a 2-hop proxy system for better privacy, with an outside CDN handling the second proxy.

Google wants to use proxy connection IPs to give users broad locations, not exact ones. It will test this on platforms like Gmail and AdServices, in Chrome versions 119 to 225.

VPN Growth and Other Browsers

The growth of VPN use points to demand for online privacy. VPNs, like Google's IP Protection, hide user IP addresses. Firefox and Opera have added VPN features to their browsers. Apple, known for user privacy, has worked with CDN companies on similar privacy improvements.

This change has trade-offs. Sending traffic through Google's, or others', servers can make it harder for security teams to handle threats. Google has suggested fixes like checking users with the proxy and rate-limiting to tackle these problems.

What It Means

Traditional safety tools like IP reputation and GeoIP methods are becoming less reliable. This change highlights the role of network-based fingerprinting now. For more on this, read our article on TLS fingerprinting.

While firms talk about hiding IP addresses, ad tracking is still common. These changes might also push users to certain platforms. Even if users think they're safe, big tech's tracking tools can still watch them. That can give users a false sense of safety. Real privacy still needs practical tools and clear public understanding.

ModSecurity’s End-of-Life

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

The end-of-life of ModSecurity on 1 July 2024 marks a practical turning point for application security teams. For DevOps, SRE, and DevSecOps professionals, it reinforces a wider shift towards Application Security Platforms that go beyond traditional Web Application Firewall (WAF) capabilities.

Modern Application Security Platforms use Web Application and API Protection (WAAP) as a core part of edge security. Peakhour's Application Security Platform extends traditional WAF protection with bot management, API security, DDoS mitigation, and account protection, backed by Peakhour Edge delivery infrastructure.

The bedrock of a WAF lies in two main components:

WAF Engine: Inspects and assesses web traffic.
WAF Rules: Guidelines that tell the engine what to inspect and how to respond.

Peakhour's Application Security Platform has used ModSecurity as part of our WAAP solution, integrating it with threat detection, behavioural analysis, and the proven OWASP ModSecurity Core Rule Set (CRS) for application protection.

For two decades, ModSecurity has been a fixture in web security. Its acquisition by Trustwave led to a sunset announcement in 2021, with the EOL set for July 2024.

Deciphering the EOL for ModSecurity

With the EOL, Trustwave will cease commercial support and updates for ModSecurity. That does not make ModSecurity irrelevant. It has been in 'maintenance mode', with Trustwave channelling its efforts towards bug fixes and security patches.

Despite this change, ModSecurity still has active community support. Tutorials and discussions centred around ModSecurity and CRS continue to appear each month. Entities like Atomicorp have pledged to extend their support to ModSecurity beyond its EOL, helping maintain its presence in the market.

Other WAF engines are emerging as potential contenders. The Coraza WAF engine, written in Go, is gaining a place in the market. The public Azure repository hosts Microsoft's ModSecurity fork, while the Edg.IO repository highlights Waflz, showing its role in the WAF ecosystem.

Recent players, such as OpenAppSec by Checkpoint, are also entering the scene. Positioned as an open-source ML-based WAF, OpenAppSec has publicly advised businesses to start their migration strategies and views itself as a viable migration path.

Peakhour's Application Security Platform Evolution

The ModSecurity transition fits with Peakhour's move towards a broader Application Security Platform. Our approach covers:

Immediate Continuity

Operational Continuity: ModSecurity continues to function within our platform, supported by active community development
No Service Interruption: Customers experience no service interruption as we implement next-generation capabilities
Tighter Integration: Existing ModSecurity capabilities are strengthened through integration with our threat detection systems

Advanced Platform Development

Peakhour is implementing security technologies that extend beyond traditional WAF capabilities:

Machine Learning Integration: AI-powered threat detection that adapts to emerging attack patterns
Behavioural Analysis: Algorithms that identify sophisticated threats including residential proxy attacks and anti-detect browser usage
API-Native Security: Protection designed for modern API-first architectures
Real-Time Threat Intelligence: Dynamic rule updates based on global threat landscape analysis

Future-Ready Architecture

Our Application Security Platform roadmap includes:

Multi-Engine Approach: Evaluation of next-generation engines including Coraza, Waflz, and custom ML-based solutions
Request-Path Protection: Security processing at Peakhour Edge locations for performance
DevSecOps Integration: API-first architecture enabling integration with CI/CD pipelines and security automation
Comprehensive WAAP: Integration of WAF, API protection, bot management, and DDoS mitigation in a unified platform

The Future of Application Security

ModSecurity's end-of-life is more than a technical transition. It reflects the move from traditional point solutions to broader Application Security Platforms. For DevOps, SRE, and DevSecOps teams, this shift enables:

Enhanced Security Posture

Unified Threat Protection: Comprehensive WAAP capabilities that protect applications, APIs, and users through a single platform
Advanced Threat Detection: Machine learning and behavioural analysis that identify sophisticated attack vectors
Real-Time Adaptation: Dynamic security policies that evolve with the threat landscape

Operational Excellence

Performance Integration: Security processing at the edge provides protection without compromising application performance
DevSecOps Compatibility: API-first architecture supports security automation and CI/CD integration
Global Scalability: Distributed protection that scales with application growth and user distribution

Strategic Advantages

Long-Term Investment: Platform approach that evolves with emerging threats and technologies
Comprehensive Coverage: Single-pane-of-glass management for application security, performance, and availability
Compliance Alignment: Built-in reporting and monitoring capabilities that support regulatory requirements

The transition from ModSecurity gives organisations a clear point to review and modernise their application security posture. By adopting Application Security Platforms, teams can improve protection whilst maintaining the performance and scalability required for modern applications.

Peakhour's Application Security Platform protects web applications and APIs with WAAP capabilities, delivery performance, bot management, and real-time threat intelligence. Contact our security team to learn how we can support your application security posture whilst maintaining performance.

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.

Headless Commerce Security

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

At Peakhour, we spend a lot of time looking at e-commerce architecture trends. Single Page Applications (SPAs) and headless commerce keep coming up, with tools such as Nuxt.js, Strapi, Hydrogen, and Gatsby leading many builds. These tools can make frontend work faster and more flexible, but they also put more e-commerce data behind APIs that scrapers can target.

Single Page Applications (SPAs) and headless e-commerce have changed how many retailers build their storefronts. Frontend development tools like Nuxt.js and headless CMSs like Strapi are now common parts of that stack.

The trade-off is exposure. Product information is often available as JSON data, which makes it easier for scrapers to collect at scale. That raises a practical question: how do you secure data while still making it available through APIs?

Strategies for Data Protection

Data protection matters, but it is not a single control. These are the usual layers:

Rate Limiting: Controls the number of client requests to your API within a set time frame.
Bot Detection: Distinguishes between humans and bots based on behavioural patterns.
Page Load Authentication: Secures the page load through bot detection and authenticates subsequent API calls.
IP Threat Intelligence: Blocks suspicious IP addresses from accessing your API.
GeoIP Filtering: Regulates requests based on geographical origin.

As bots change, those controls need to change as well.

Facing the Challenge of Headless Scraping

Headless scraping uses browsers without a user interface to imitate normal browsing. It is difficult to detect, but network fingerprinting can help.

Network fingerprinting examines network features like Transport Layer Security (TLS) settings and HTTP/2 (H2) parameters. By analysing these, companies can detect and block bots, adding another security layer.

Client-side Security in SPAs

In SPAs, where much of the processing happens in the user's browser, the security concerns shift:

Data Exposure: Protecting sensitive data from leakage or manipulation is critical.
Injection Attacks: SPAs must guard against attacks like Cross-Site Scripting (XSS).
Authentication and Session Management: Properly handled, these prevent unauthorised access.
Insecure Direct Object References (IDORs): Proper authorisation stops attackers from accessing others' data.

Risks in JavaScript Packages

SPAs usually depend on JavaScript libraries and packages. They are useful, but they also add supply chain risk. Using only essential packages, keeping them updated, and sourcing them from trusted providers reduces that risk. Supply chain audit tools can help automate the work:

Security audits need to be frequent because vulnerabilities can appear quickly. Tools like npm's npm audit or GitHub's Dependabot, along with regular penetration testing, can help uncover potential weaknesses.

Final Thoughts

The move toward SPAs and headless commerce is a trade-off between development flexibility and security exposure. These architectures can improve user experience and speed up delivery, but they also introduce new security issues.

Client-side security in SPAs needs deliberate attention. Data exposure, injection attacks, and insecure direct object references all need to be managed, and the convenience of JavaScript libraries brings its own vulnerabilities.

Peakhour addresses these problems with rate limiting that manages request traffic and helps prevent attacks without harming customer experience. Our Web Application Firewall (WAF) examines all payload data, adding another layer of protection.

Frequent security audits still matter. They help e-commerce managers keep SPAs and headless commerce operations secure without giving up the efficiency these architectures can provide.

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.

Chrome's TLS Extension Randomisation Experiment

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

Transport Layer Security (TLS) fingerprinting is a commonly used technique for identifying client processes. To reduce the risk of server and middlebox fingerprinting of Chrome's current ClientHello and to make the TLS ecosystem more resilient to changes, Google Chrome ran an experiment to randomise a portion of the TLS fingerprint. This experiment was included in Chrome version 108, which was released on December 8, 2022. You can read the status of the current experiment on the chrome status site

The aim of this experiment was to make it more difficult for server implementers to fingerprint Chrome and assume specific implementation behaviour from a fixed extension order. By randomly ordering extensions (subject to the pre_shared_key constraint in the RFC), Chrome hoped to reduce the risk of server and middlebox fixating on details of its current ClientHello.

The above graph correlates to the Chrome experiment and subsequent release of the feature. The number of unique TLS signatures dramatically increased.

From Peakhour data, we can see a large number of unique fingerprints appearing since the date of the experiment, making it very difficult to identify the Chrome network stack by a TLS fingerprint alone. However, an analysis by David McGrew, a Cisco Fellow, cast doubt on the effectiveness of this experiment. In his article, McGrew proposed a lexicographical sorting of TLS extensions and found that 98.8% of signatures were unique after sorting. He argues that the canonical ordering of the TLS extensions in the TLS fingerprint can achieve nearly the same level of entropy as randomising them and still be effective at client identification. Furthermore, he claims that the RFC should be amended to state that extensions SHOULD be sent in an ordered fashion in the ClientHello packet. McGrew also highlights the potential dangers of allowing unordered extension lists, as it could create a \"subliminal channel\" that could be used for tracking or transmitting information. Let's now graph, over the same period, the number of TLS signatures with TLS extension sorting.

The above graph correlates to David's assertion that sorting TLS extensions has minimal impact on TLS fingerprinting.

It appears that David's assertion is correct: sorting TLS extensions has minimal impact on the number of unique TLS fingerprints. Let's now look at in-the-wild Chrome 109 data:

Hashed sorted TLS Fingerprint	Unique unsorted TLS fingerprints	Browser	Version	% of clients	% of hits
3241796329	2	Chrome Mobile WebView	109	6.14	1.01
3313291307	8566	Chrome	109	1.83	1.54
1537819294	26587	Chrome Mobile	109	6.05	4.64
3944870384	1	Chrome Mobile iOS	109	4.31	5.35
3241796329	51594	Chrome Mobile	109	16.9	14.43
1537819294	121346	Chrome	109	15.66	20.7
3241796329	156405	Chrome	109	35.52	37.79

It's interesting that the experiment does not run on WebView.

Final Thoughts

While Chrome's experiment may have reduced the risk of server and middlebox fingerprinting of Chrome's current ClientHello, it seems that randomising TLS extensions alone is not enough to prevent TLS fingerprinting, and may be a useful indicator that it is The Real Chrome.

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.

Why Manage Bots?

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

Modern sophisticated bad bots often work around traditional security controls. They disrupt websites, mobile applications, and APIs. Malicious bot tactics include scraping user and pricing data, creating fake accounts, running advertising click fraud, exhausting online inventories, and taking websites offline with automated DDoS attacks.

About one-quarter of all website traffic in 2019 originated from bad bots, an increase of 18 percent over 2018. Advanced persistent bots (APBs) made up seventy-five percent of that bad bot traffic as they attempted to evade detection by cycling through random IP addresses, using anonymous/residential proxies, and changing their identities (user agent). The industries hit hardest by bad bots in 2019 included financial services, education, ecommerce, and government as well as media and airlines.

“Bot attack campaigns have become big business for threat actors, and major organizations are now fighting to support legitimate users and prospects while keeping attackers out of online applications and services,” says Paula Musich, Research Director, Enterprise Management Associates.

Bots have moved from simple scripts to distributed networks of automated agents that can mimic human interactions with machine learning techniques. They can avoid detection by network security technologies that have not kept pace with the way automated agents now operate.

Reducing the damage from bad bots means using security countermeasures that detect automated traffic and make attacks uneconomic, not just visible.

Bot Countermeasure Best Practices:

The following bad bot countermeasure practices cover network security, machine learning, and behavioural analysis. The aim is to reduce the economic harm that malicious bots inflict on businesses and end-users.

Web Application Firewalls

Web Application Firewalls (WAF) are a common first line of defence that filter out harmful Layer 7 web application (HTTP) traffic using rules or policies that protect organisations against Distributed Denial of Service (DDoS) bot attacks. WAFs also protect against cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection attacks. A WAF is considered a reverse proxy that protects servers and can be deployed as an appliance, server plug‑in, or filter, and customised by application type or use case. WAF rules can be updated or changed based on the type of bot attack.

IP Tracking and Reputation

Sophisticated bots can be detected with network forensics by inspecting web traffic and assessing whether requests come from actual users or bad bots. Requests can be analysed using data sources including Tor/proxy IPs, IP addresses, IP geo-location information, ISP information, and IP owners. Additional sources for real-time and near-time malicious IP threat data can come from network data, CERTs, MITRE and cooperating competitors.

Client/Device Fingerprinting

Fingerprinting attempts to identify devices, including PCs, Internet of Things (IoT) devices, mobile devices and servers, using data attributes that create real-time risk profiles to stop bot attacks. Using web page access data, a bot detection fingerprinting engine generates unique fingerprints for each end-user device and checks them against bad bots that use evasion techniques, including dynamic IP addresses and anonymous web proxies.

Machine Learning

Artificial Intelligence (AI) and machine learning algorithms are increasingly used to analyse malicious bot activity and make mitigation recommendations using data from sources such as user activity history, behavioural patterns and meta-data. Machine learning can use custom-tailored algorithms to target bots and iteratively process user data and identities to discern emerging bot attack patterns from very large amounts of real-time information.

Tarpitting

Tarpitting is a bot countermeasure that delays and slows down incoming malicious traffic from suspect connections. The technique is used to increase the financial and resource costs of bot attacks in an attempt to discourage malicious actors. Bad bot tar pits can delay bot request responses or take the bad bot IP address attack source offline completely. Innovative tarpitting techniques include requiring bad bots to solve computationally complex maths challenges to access resources or websites, thereby slowing down or stopping bot activity.

User Behavior Analysis

User interaction behaviour and identifying characteristics on a web page or mobile app differ from the behaviour of an automated malicious bot. Factors such as number of pages visited per session, time spent on each web page or within a mobile app and repeat visit frequency all help differentiate authentic users from bad bots. Defeating bad bots using Behavior Analysis involves creating a user model for individual sites with historical visitor data, then checking for anomalies that may indicate bad bot activity.

Intent-based Deep Behavior Analysis (IDBA)

Compared with Behavior Analysis, Intent-based Deep Behavior Analysis (IDBA) conducts behavioural analysis at the user intent level rather than the commonly used interaction-based behaviour analysis. IDBA consists of intent encoding, intent analysis, and adaptive learning. It also employs machine learning techniques to detect bad bots emulating on-site human behaviour interactions. Bad bot mitigation techniques include limiting attempts on login pages, web authentication pages and API call authentication pages.

Rate Limiting

Rate Limiting mitigates bad bots and DDoS attacks by restricting the amount of incoming traffic accepted by specific applications and API endpoints using pre-defined bandwidth limitation policies. Web applications, GET versus POST requests, APIs that receive queries, and login credentials can all be blocked if clients, IP addresses or IP and user-agent pairs violate Rate Limiting rules. Intellectual property scraping can also be protected by Rate Limiting policies that restrict repeated image or digital downloads.

Javascript Injection

JavaScript Injection techniques can help mitigate bad bot attacks in several ways. Scripts can be placed into web applications that “fingerprint” a user’s browser to distinguish humans versus bad bots emulating “human-like” mouse movements, keystrokes or clicks. Fingerprinting detection may also involve user agent identification, HTML5 canvas and audio fingerprinting, and protocol-level fingerprinting with TLS and HTTP2. JavaScript combined with browser cookies can also be used to identify anomalous behaviour from unwanted traffic or bad bots trending over time.

ANYCast DDoS Mitigation

Anycast is an IP addressing method that routes incoming traffic requests to the nearest location or “node.” Using ANYCast for selective routing enables network load resilience against DDoS attacks by routing high traffic across multiple servers and data centres. This prevents network resources from becoming overwhelmed with malicious or irrelevant traffic.

Alternative Content Serving

Serving Alternate and Cached Content when a bad bot is detected gives organisations a way to mislead bots without blocking them altogether. For instance, e-commerce sites may fool price scraping bots by serving alternative web pages that look like legitimate pages but with higher prices. Serving Cached Content when a bot is detected also minimises load on servers without affecting site performance.

Challenges

Requests from suspected bots can be redirected to Challenges or puzzles such as a CAPTCHA, also known as a Completely Automated Public Turing test, to help identify a bad bot versus a human. Online puzzles, such as letter matching, are easy for humans to solve but difficult for automated bots. reCAPTCHA, offered free from Google, is an advanced version of CAPTCHA puzzles that require users to identify text from real-world images such as street address signs, printed books or text from paper newspapers.

Final Thoughts

Bad bots hijack user accounts, create fake accounts, scrape websites for data and personal information, flood websites with traffic through automated distributed denial of service attacks and attack public-facing APIs using constantly changing techniques. They hide behind dynamic IP addresses, change their attack signatures, mimic human behaviours, and take over vast networks of hosts and IoT devices, creating zombie machines that distribute malware across the internet. Countermeasures ranging from Web Application Firewalls to sophisticated Machine Learning algorithms form an organisation's primary line of defence against bad bots.

Malicious Bot Threats

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

Bots are software applications that automate repetitive tasks without human interaction. They have become part of the normal infrastructure of the internet. Some bots are useful; others are bad bots. The latter are the concern for application and security teams.

Bad bots keep changing and are increasingly difficult to detect. They can cause significant financial damage to organisations by disrupting online operations, overwhelming websites with traffic, and stealing information such as web content and ecommerce pricing data.

Bad Bot Types

Bad bots span a wide range of attack capabilities and scenarios. The following are the main categories these attacks fall into:

Spam Bots

Spam bots typically target blog comment sections, community portals and lead generation forms with 'garbage' or fake content. They can also insert unwanted ads, malicious phishing links and banners into real-time conversations to disrupt the service and attack users.

Scraping Bots

Price, content and inventory scraping bots steal prices and product listings. This can damage an ecommerce site's revenue stream and harm SEO rankings when duplicate content appears on competitor and bogus sites. These bots also scrape product reviews, news, product catalogues and user-generated content. Scraper bots can harvest email addresses, images and text from victim websites, then repurpose that material to pose as legitimate web pages.

Credential Stuffing Bots

Credential Stuffing Bots attempt to use login details from other sites, or run brute force guessing attacks against customer and admin accounts. If successful, they can make purchases, harvest personal information and purchase histories, make unauthorised cryptocurrency transactions, and transfer reward points and money to gift cards and air miles.

Ad Click Fraud Bots

Ad Click Fraud Bots can sabotage competitors by clicking on their ads to drive costs up and exhaust budget caps. They can also be used to scam advertisers with fake websites and ad clicks that pay the fraudster directly. In both scenarios, bots automatically generate interactions or 'clicks' with ads, promotions and media.

Credit Card Stuffing Bots

Carding bots make repeated attempts to authorise stolen credit card credentials. This can leave merchant payment processors with chargebacks and penalties, and may ultimately result in the victim merchant being prevented from accepting credit cards altogether.

Inventory Denial Bots

Cart Abandonment and Inventory Exhaustion bots automatically add hundreds of products to ecommerce shopping carts, then abandon them. This can block consumers from buying products, reduce sales, manipulate conversion rates and damage a brand’s reputation.

DDoS Bots and Botnets

Distributed Denial of Service (DDoS) attack bots and botnets are made up of thousands of compromised computers or Internet of Things (IoT) devices called "zombies". They can slow down a website or take it offline completely by flooding sites with massive amounts of artificially generated traffic. Researchers have found cybercriminals advertising DDoS services on the dark web with basic fees to attack unprotected sites ranging from $50 to $100, while an attack on a protected site can reach $400 or more.

Ticket Scalping Bots

Ticket scalping bots automatically buy tickets, enabling malicious users to resell them at a higher price. Examples include using a bot to purchase concert tickets for major events the minute they go on sale.

Fake Account Creation Bots

Fake Account Creation bots create fake accounts for criminal activities such as content spam, cryptocurrency laundering and malware distribution. Fake accounts can compromise brands and attack users with malware such as ransomware.

Hacker Bots

Hacker bots can distribute malware, attack websites and compromise entire networks by exploiting security vulnerabilities and injecting code into victim sites. Hacker bots can also perform DDoS attacks across web proxies with browser-like signatures to disrupt business operations.

Impersonator Bots

Impersonator bots copy human computer interactions and behaviours to fool users and bot mitigation defences while they conduct malicious activity. Impersonator bots also include propaganda bots that influence political opinions on platforms such as Facebook and Twitter. According to researchers at the University of Southern California who studied bot use during the 2016 U.S. Presidential election, “the presence of social media bots can indeed negatively affect democratic political discussion rather than improving it, which in turn can potentially alter public opinion.”

The Growing Threat

A report from Imperva found that roughly one-quarter of all website traffic in 2019 originated from bad bots, an increase of 18% over 2018. 75% of that bad bot traffic is made up by Advanced persistent bots (APBs) that attempt to evade detection by cycling through random IP addresses, using anonymous proxies, and changing their identities. The industries hardest hit by bad bots in 2019 included financial services, education, ecommerce and government, as well as media and airlines.

Companies offering "Bad Bots as-a-Service"* are also gaining ground. These data scraping services sell bots as easy-to-use packaged products that provide pricing and competitive intelligence, alternative data for finance, or competitive insights managed by Web Data Extraction Specialists and Data Scraping Specialists.

Malicious bot-for-hire services also offer personal and financial data harvesting, brute-force login services, ad click fraud, spamming services, transaction fraud services, and Distributed Denial of Service (DDoS) attacks.

Final Thoughts

Bad bot activity continues to increase, so websites need security controls that can identify and stop them. Our next article on bots will go over the common countermeasures used to combat bad bots.