Peakhour.IO - Application Security

Protecting Against a Share Point Zero Day Vulnerability with Network Fingerprinting

2025-07-23T13:00:00+10:00

Why Network Fingerprinting is Your Strongest First Defense

A critical new remote code execution (RCE) vulnerability in on-premises Microsoft SharePoint Server, identified as CVE-2025-53770, is being actively exploited and presents a serious risk to organisations. This flaw allows an unauthenticated attacker to take complete control of a server over the network, so immediate and effective defence is a priority. Microsoft disclosed the flaw on 19 July.

Vendor patches are essential, but zero-day activity often starts before most organisations can patch. That gap is where proactive controls matter.

This post looks at the technical nature of this threat and how a strategy centred on network fingerprinting can block zero-day exploit activity before a formal patch is deployed.

Understanding the Threat: CVE-2025-53770

The SharePoint vulnerability is particularly dangerous as it allows for the deserialization of untrusted data, leading to remote code execution without any need for attacker authentication. This makes any unpatched, internet-facing on-premises SharePoint server a potential target. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has underlined the severity of this threat by adding it to its Known Exploited Vulnerabilities Catalog.

Exploitation can lead to a complete compromise of the SharePoint server, allowing attackers to steal data, execute arbitrary code, and potentially move laterally across the internal network.

The Race Against Scanners

When a zero-day vulnerability like this is discovered, a global, automated race begins. Malicious actors immediately deploy scanners to canvass the internet for vulnerable systems.

Our own analysis shows that the majority of malicious requests targeting our clients came from the DigitalOcean and Scaleway ASNs, with Amazon Web Services (AWS) EC2 and Microsoft Azure also being a prominent source. These networks are well-known for being used by malicious actors to launch scanning and attack campaigns quickly. Notably, scans were happening on 16 and 17 July, before the vulnerability was disclosed by Microsoft.

This initial scanning phase, however, creates an opportunity for defence. Instead of waiting to analyse the specific attack payload, we can identify and block the very tools the attackers are using.

Exploits attempts in the wild. Note attempts days before disclosure.

Why IP Reputation Isn't Enough

For years, a primary method of defence has been IP reputation—blocking traffic from IP addresses known to be malicious. While simple and somewhat effective against basic attacks, this approach is increasingly unreliable in the face of modern threats.

The rise of sophisticated proxy services has changed the model. Attackers now have easy access to vast networks of residential, mobile, and rotating data centre proxies. These services allow them to distribute their attack traffic across thousands or even millions of seemingly legitimate IP addresses, making it impossible to maintain an effective blocklist. An IP that sends a malicious request one moment could be used by a legitimate customer the next.

Furthermore, attackers leveraging cloud infrastructure use ephemeral IPs that exist for only a short time, rendering IP-based blocking a constant and losing game of cat and mouse. This approach also carries a high risk of "collateral damage", where legitimate users are blocked simply because they share an IP address with a bad actor, a common scenario with Carrier-Grade NAT (CGNAT) or public Wi-Fi. Relying solely on where a request comes from is no longer a viable strategy.

Unmasking the Attacker's Tools with Network Fingerprinting

This is where network fingerprinting becomes useful as a zero-day defence. Fingerprinting in cybersecurity refers to methods used to identify the unique characteristics of devices, software, or users. It allows for the identification and categorisation of operating systems and software based on their distinct signatures in network communications.

When attackers rush to exploit a new vulnerability, they don't use standard web browsers. They quickly code scanners using programming languages and libraries like Python, Go, or Java. These tools and libraries create network connections with distinct, non-browser-like fingerprints. By analysing these, we can block the scanner before it ever delivers its malicious payload.

Peakhour uses several passive fingerprinting techniques to do this:

TCP Fingerprinting

This method identifies a device's operating system by analysing how it implements the TCP protocol. By examining nuances in TCP packets—like window size, Time to Live (TTL), and how the device responds to non-standard packets—we can identify the underlying system that created the request.

TLS Fingerprinting

This technique analyses the "ClientHello" message sent by the client during the initial TLS handshake to establish a secure connection. The combination of TLS version, supported cipher suites, and extensions creates a unique fingerprint. This is a highly effective way of identifying the classes of connecting clients, such as those made by Go, Python, or Java libraries, which are commonly used for attack tooling. JA4 and JA3 are popular TLS fingerprint formats.

HTTP/2 Fingerprinting

This involves analysing how clients use the HTTP/2 protocol, including their patterns in sending HTTP/2 frames and negotiating connections. This makes it easier to differentiate between legitimate browsers, bots, and the custom applications used in an attack campaign.

After identifying these fingerprints, Peakhour's bot management service uses machine learning to classify them as either a legitimate browser or a bot. This provides a strong layer of defence against zero-day exploits. The scanners are identified and blocked based on their fundamental network characteristics, irrespective of the specific vulnerability or payload they carry.

Defense in Depth

No single security measure is a silver bullet. While network fingerprinting provides a powerful first line of defence against automated scanners, a multi-layered, defence-in-depth strategy matters.

Any request that manages to bypass the initial fingerprinting checks must face the next layer: our standard Web Application Firewall (WAF) with post-body scanning. A WAF inspects every request before it reaches the application. By enabling the inspection of the full request body, the WAF can identify and block malicious payloads, such as the specific code used in an exploit attempt, that may be hidden within the data sent to the server. Our WAF was updated with a virtual patch on 22 July at 5am AEST to add protection against this vulnerability.

Staying Ahead in a Zero-Day World

The SharePoint CVE-2025-53770 vulnerability shows why a reactive security posture is not enough. While patching is essential, the reality is that attackers move first.

By using proactive techniques like network fingerprinting, organisations can identify and neutralise the automated tools attackers rely on during the critical opening hours of a zero-day exploit's life. This approach, when combined with payload inspection from a WAF, gives critical assets another layer of practical protection.

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.

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.

Visa's Security Roadmap 2025-2028

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

Visa's Security Roadmap 2025-2028 for Australia is not just a payments strategy document. It is a signal about where fraud, application security, authentication, and compliance work are converging for merchants, acquirers, issuers, gateways, and service providers.

The timing matters. Visa's roadmap cites Australian card fraud rising 32% to A$762 million in 2023, with unauthorised card-not-present fraud increasing 33% to A$688 million. Scam losses reached A$2.7 billion in 2023, and reported data breaches increased 19% in the second half of 2023 compared with the first half. The pressure is not coming from one direction. Payment teams are dealing with automation abuse, social engineering, compromised credentials, weak merchant onboarding, third-party exposure, and new payment experiences at the same time.

Visa groups its roadmap into six focus areas: preventing enumeration attacks, continued investment in secure technologies, data-driven risk, resilience against fraud and scams in the era of AI, stronger cyber security posture, and secure digital payment experiences. For Australian businesses, the more useful way to read it is as a set of operational themes.

Automation Abuse Has Become a Payment Control Issue

Enumeration attacks sit first in the roadmap for a reason. Visa defines enumeration and account testing as automation used to test and guess payment credentials that can later be used in fraudulent transactions. The attacks often appear as high-speed card testing against online merchants, with low-value attempts used to validate PAN, expiry, or CVV2 combinations.

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 enumeration attacks over the year to 30 September 2023. The updated Visa Acquirer Monitoring Program (VAMP), effective 1 April 2025, adds enumeration criteria alongside broader fraud and dispute monitoring.

The implication is practical: merchants and acquirers need route-level evidence, anomaly monitoring, velocity controls, and a way to identify distributed automation before it becomes payment fraud. IP-only controls are weak when attacks use residential proxies, first-seen devices, and slow distributed attempts. Peakhour's bot management, residential proxy detection, advanced rate limiting, and edge logging can help support that evidence path, but the business still needs payment-flow ownership and acquirer alignment.

Authentication and Tokenisation Are Moving Together

Visa's secure technology theme is not simply "add more authentication." The roadmap ties tokenisation, EMV 3DS, biometric or in-app authentication, passkeys, and Click to Pay into the same customer and fraud problem: protect credentials while reducing unnecessary friction.

Tokenisation reduces the value of exposed card data by replacing a card number with a token. Visa notes that the Visa Token Service has passed one billion tokens in Asia Pacific and that merchants adopting VTS for digital payments saw payment fraud rates reduced by more than half in the cited Asia Pacific analysis. But the roadmap also flags token provisioning fraud, where bad actors illegitimately provision tokens and then monetise them quickly.

That is why authentication quality matters. Visa says issuers are being mandated to move away from SMS OTP as the sole authentication factor by 2026, toward methods such as biometric, in-app, app-to-app, or passkey-based authentication. For merchants, updated Visa Secure minimum data requirements push more complete authentication data into the decision process.

For application teams, the lesson is that checkout security is not a single login prompt. It includes account creation, saved-card use, card add, token provisioning, checkout, refund, and support paths. A risk-based challenge should appear where the action justifies it, not everywhere by default.

Risk Decisions Need Better Data, Not Just More Data

The roadmap's data-driven risk theme is about using available payment and authentication data to reduce fraud and false positives. Visa points to EMV 3DS data elements, Visa Secure requirements, risk-based authentication, and issuer decisioning as examples of how better data quality can change outcomes.

More data is not automatically better. It has to be accurate, relevant, protected, and available at the moment of decision. A fraud team may need account history, device consistency, proxy likelihood, card-attempt cadence, transaction context, and previous response outcomes. A compliance team may need to know why that data is collected, where it is retained, and who can query it.

This is where contextual security becomes useful. Peakhour's Contextual Security approach combines request, route, account, network, device, and behaviour signals so teams can allow, challenge, rate limit, block, or log based on risk. The control is strongest when the decision record stays attached to the event: signal set, policy version, action, and outcome.

AI Raises Scam and Fraud Pressure, But It Is Also Part of Detection

Visa frames AI in both directions. Generative AI lowers the barrier for phishing, social engineering, deepfakes, and personalised scam content. At the same time, Visa points to its long history using AI and machine learning in payment fraud detection, including around 150 AI and machine learning models in production.

For businesses outside the payment network, the message is not "buy AI." It is to prepare for more scalable deception and faster abuse cycles. Fraud controls need to watch for account creation abuse, credential stuffing, payment testing, suspicious onboarding, transaction anomalies, and customer manipulation signals. Human review still matters because authorised scams can look different from unauthorised account compromise.

Peakhour's role is strongest around the request and account edge: identifying automation, proxy-backed traffic, route abuse, credential risk, and abnormal behaviour before fraud reaches sensitive application paths. Those signals can feed fraud review and incident response, but they should be used with privacy, false-positive, and customer-impact controls.

Cyber Posture Is Now Part of Payment Ecosystem Resilience

Visa's fifth theme connects payment fraud to cyber security posture. PCI DSS remains mandatory for entities storing, processing, or transmitting Visa cardholder data. Visa also highlights third-party agent (TPA) registration, its Account Information Security program, third-party service provider risk, breach trends, and preparation for broader AES support by 2030.

For Australian businesses, this is a reminder that payment risk is not limited to the payment processor. A breach of a CMS account, a third-party script, a weak checkout plugin, a vulnerable API, a compromised support tool, or an unmanaged service provider can affect the payment environment. PCI scope and third-party oversight need to include the systems that can change or observe checkout, not only systems that store card numbers.

Peakhour can help with application-layer controls around WAF, API protection, bot management, rate limiting, DDoS mitigation, and log forwarding. Those controls can support evidence for payment security and cyber posture. They do not replace PCI DSS validation, TPA obligations, acquirer requirements, or legal review.

New Payment Experiences Need Security Built Into the Flow

Visa's final theme covers digital payment experiences such as Click to Pay, passkeys, Flex Credential, and Tap to Everything. These changes are about reducing manual card entry, password dependence, and fragmented checkout experiences while preserving cardholder verification and transaction security.

The security work for merchants is to keep pace with those flows. New payment methods bring new integration paths, data elements, redirects, APIs, support workflows, and customer education needs. The right question is not only "does the new payment method work?" It is "which systems can affect it, what data is passed, how is the customer verified, what fraud signals are available, and what evidence remains after a dispute or incident?"

What Businesses Should Do Next

Read the roadmap as an operating agenda. Map payment and account routes. Identify where automation can test credentials or cards. Review SMS OTP dependence. Check whether tokenisation and 3DS data are being used well. Validate which vendors affect checkout and payment security. Confirm that logs can support fraud review without capturing sensitive card data. Tune rate limits and bot controls by route, not only by IP.

The next few years of payment security will reward teams that can make proportionate, evidence-backed decisions. That is the thread running through Visa's roadmap and through Peakhour's edge security work: see the request in context, choose the right action, and keep enough evidence for fraud, security, and compliance teams to explain what happened.

Anti-Detect Browsers

2025-01-15T10:00:00+11:00

Anti-detect browsers matter to defenders because they attack the assumptions behind browser trust. Many bot and fraud controls look for consistency between the browser, network, session, and behaviour. Anti-detect tooling is designed to make automated or repeated activity look more like separate ordinary browser sessions.

This article is not a guide to using those tools. The defensive question is simpler: when a browser tries to look ordinary, what can still be observed safely, and how should that evidence affect a request decision?

Why They Create Risk

Anti-detect browsers are often discussed as a browser-fingerprinting problem, but the risk is wider than that. The same traffic may also involve residential proxies, credential lists, automation, and API requests that never run browser-side checks. A login attempt, account creation flow, product scrape, checkout request, or mobile API call may look valid at the protocol level while still being part of an automated campaign.

The hard part is that some signals are genuinely ambiguous. A changed browser, a new device, a shared network, or a privacy tool does not prove abuse. A defensive system has to treat those observations as risk inputs, not as standalone verdicts.

Browser Consistency Is Evidence, Not Identity

Anti-detect tooling tries to make browser-reported attributes look internally consistent. That weakens simple checks that only ask whether the browser appears plausible. Defenders need a broader view: does the claimed browser line up with the network stack, TLS and HTTP behaviour, session history, cookie continuity, route sequence, response-code pattern, and recent account behaviour?

That does not mean a fingerprint identifies a person. Fingerprints classify software, client behaviour, and connection characteristics. They can help separate likely automation from ordinary traffic, but they need to be combined with route, account, proxy, and behavioural context. The result should be a risk classification with evidence attached, not an unexplained block.

Residential Proxies Change the Decision

Residential proxies are a common companion signal because they make requests appear to come from consumer networks. That creates a false-positive problem. Real customers also use shared residential, mobile, office, carrier-grade NAT, and public Wi-Fi networks. Blocking every suspicious or shared source would damage legitimate traffic.

The safer approach is to use residential proxy detection as one input in the decision. A proxy signal on a public content page may be logged. The same signal on repeated login failures, account creation, checkout abuse, or sensitive APIs may justify a challenge, rate limit, or block. Context changes the action.

The API Gap

Browser-side checks are weakest where the browser is not present. Mobile apps, partner integrations, token routes, and direct API clients may not expose the same JavaScript or browser evidence that a web page does. Attackers do not need a convincing browser if the target workflow accepts valid-looking API requests.

That is why anti-detect risk belongs in the wider application security model. API routes need method, schema, authentication, token, request cadence, response-code, account, and bot context. If the only signal available is an IP address, the decision will be too blunt.

Observable Signals Defenders Can Use

The useful evidence is usually the mismatch between what the request claims to be and how it behaves over time. A browser may look plausible on one request, but the wider pattern can still show automation: repeated attempts across accounts, route sequences that normal users do not follow, cache-miss pressure on expensive pages, unusual response-code loops, or browser and network characteristics that drift in ways ordinary clients rarely do.

Bot Management works best when it combines these signals rather than chasing a single magic detector. IP intelligence, proxy classification, network and browser fingerprints, route-aware rates, API state, WAF findings, and behaviour should all feed the same action vocabulary: allow, challenge, rate limit, block, log, or review.

Safer Defensive Response

The defensive response should be proportionate. High-confidence exploit traffic can be blocked quickly. Uncertain browser or proxy evidence may be better challenged, rate limited, or logged until the pattern is clearer. Sensitive routes should have tighter policy than public content. Account-impacting actions should preserve enough evidence for review.

This is especially important for support teams. If a real customer is challenged or blocked, operators need to see which signal drove the action and which route was involved. Without that record, anti-bot policy becomes a black box.

Final Thoughts

Anti-detect browsers are a practical problem because they reduce the value of simple browser checks. They do not make traffic invisible. They leave request-path evidence in network behaviour, route sequences, account activity, API usage, proxy signals, and response patterns.

The right goal is not to identify a person from a fingerprint or to block every unusual browser. The goal is to classify risk with enough context to choose a safe action at the edge, then keep the evidence available for tuning and review.

Next-Generation Application Security Defence Strategies

2024-11-15T14:00:00+11:00

As I look at recent cyber threat activity, the pattern is clear enough: AI is no longer only a defensive tool. Attackers are using it to probe, adapt, and automate application-layer attacks.

One recent incident made that plain. Our threat detection systems identified a series of probes against a client's infrastructure. These were not the typical brute-force attempts we are used to blocking. The attack patterns changed in real time, adapted to our defences, and probed for weaknesses in a way that pointed to AI-driven automation.

The individual attempts were not the main concern. What mattered was how the attack system learned and adjusted its approach. When we blocked one vector, it shifted to another. When we implemented rate limiting, it distributed its attempts through residential proxies. The attack showed a common trait of AI systems: rapid iteration and learning from failure.

This change in attack methodology puts real pressure on the traditional security model. Static defences, including controls that looked strong only months ago, are easier to route around. They might stop obvious threats, but more capable AI-powered attacks can keep testing the edges until they find a path.

The threat landscape has shifted in three practical ways. First, AI enables attacks to adapt and evolve in real time. Second, residential proxies give attackers a distributed network of IP addresses that appear legitimate, making traffic origin verification much harder. Third, AI can analyse and mimic legitimate user behaviour patterns closely enough to bypass traditional bot detection.

These changes require a change in defence strategy. Identifying and blocking known attack patterns still matters, but it is no longer enough on its own. We need systems that can anticipate and adapt to new threats as quickly as they emerge.

In our security operations, we've begun implementing what we call "contextual defence dynamics." The approach moves beyond simple pattern matching to analyse the intent and behaviour behind each request. We examine not just what a request does, but how it fits into broader patterns of behaviour and what it might indicate about the attacker's objectives.

That approach has already proved useful. When we implemented contextual defence dynamics for a major e-commerce client, we identified and blocked an AI-powered credential stuffing attack that had evaded traditional detection methods for weeks. The attack used residential proxies to distribute its attempts and mimicked human behaviour patterns, but our system identified subtle anomalies in its timing and response patterns.

That case highlighted a useful point: while AI-powered attacks grow more sophisticated, they still exhibit patterns. Those patterns may not appear in individual actions, but they do appear in broader behaviour and objectives. By shifting our focus from blocking specific actions to understanding and responding to these broader patterns, we can maintain effective defences even against evolving threats.

This approach requires a different way of thinking about security. We must move from a model of static defences to one of dynamic response. Our security systems must learn and adapt as quickly as the threats they face. This means implementing machine learning systems that can identify new attack patterns, updating defence strategies in real time, and maintaining awareness of emerging threat vectors.

The implications extend beyond technical implementation. Organisations need to treat security budgets and strategies as ongoing commitments, not one-off purchases. The era of "set and forget" security solutions has ended. Continuous adaptation and review now sit at the centre of effective defence.

I expect this arms race to keep accelerating. AI will continue to enhance both attack and defence capabilities. The organisations that maintain strong security will be those that accept this dynamic and build their defences around continuous adaptation.

For security professionals, this means developing new skills and approaches. We must understand not just the technical aspects of security, but the patterns of attack and defence that emerge in AI-driven systems. We must build systems that can learn and adapt, and we must be prepared to change strategy as the threat landscape evolves.

The security arms race has entered a new phase. The advantage will not sit with the strongest static defences alone, but with teams that can adapt and evolve their protection strategies in real time. The focus must shift from building walls to creating intelligent, adaptive defence systems that can match the sophistication of AI-powered threats.

This shift in security thinking is practical, not theoretical. The threats we face are becoming more capable, and defensive tooling is improving as well. The important step is recognising the change and adapting how we build, operate, and review application security controls.

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.

Application Security for Financial Services Under CPS 234

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

Recent credential stuffing attacks on prominent Australian retailers like The Iconic and Dan Murphy's have brought this threat into sharper focus. For APRA-regulated entities, these incidents are a reminder that credential stuffing is not only an account takeover issue. It can also trigger assessment and disclosure obligations under Prudential Standard CPS 234 Information Security.

The Rising Tide of Credential Stuffing

Credential stuffing is now common in Australia and globally. These attacks exploit password reuse across multiple sites. Cybercriminals use automated tools to test large volumes of stolen username and password combinations against websites, looking for accounts they can access without authorisation.

The scale is large. According to recent studies, there are over 15 billion stolen credentials circulating on the internet. In 2020 alone, one large content delivery network reported more than 193 billion credential stuffing attacks globally. For Australian businesses, the risk is significant and growing.

The Compounding Threat of Residential Proxies

The use of residential proxies has increased the sophistication and effectiveness of credential stuffing attacks. Residential proxies allow attackers to route their traffic through legitimate residential IP addresses, making automated activity look more like normal user behaviour.

This technique poses several challenges:

Bypassing Traditional Defences: Standard IP-based rate limiting and geo-blocking become ineffective when attacks come from diverse, legitimate-looking IP addresses.
Evading Detection: Traffic from residential proxies is harder to distinguish from genuine user activity, complicating detection efforts.
Scalability: Attackers can distribute their attempts across a large network of proxies, allowing for larger-scale attacks without triggering typical alarm thresholds.
Improved Success Rates: By appearing to come from the same geographic area as legitimate users, these attacks are more likely to bypass location-based security measures.

The Crabby Phenomenon

The emergence of sites like Crabby Cash shows how credential stuffing fits into a broader cybercrime market. These platforms serve as marketplaces for compromised accounts, making it easier for criminals to monetise successful credential stuffing attacks.

Key points about Crabby Cash and similar sites:

Ease of Access: These sites lower the barrier to entry for cybercriminals, providing ready access to compromised accounts.
Rapid Exploitation: Once credentials are verified and listed on these sites, the window for detection and mitigation narrows significantly.
Diverse Targets: The range of compromised accounts often spans multiple industries, including retail, financial services, and entertainment.
Ongoing Threat: The existence of these marketplaces incentivises continuous credential stuffing attempts, creating a persistent threat landscape.

The CPS 234 Disclosure Imperative

The prevalence of credential stuffing attacks, compounded by residential proxies and platforms like Crabby Cash, makes the disclosure requirements in CPS 234 directly relevant.

Paragraph 35 of CPS 234 states:

An APRA-regulated entity must notify APRA as soon as possible and, in any case, no later than 72 hours, after becoming aware of an information security incident that:

(a) materially affected, or had the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers; or

(b) has been notified to other regulators, either in Australia or other jurisdictions.

The existence of sites like Crabby Cash can increase the potential impact of credential stuffing attacks, making them more likely to meet the materiality threshold for disclosure.

A Risk-Based Approach to Disclosure

To manage credential stuffing risk and meet CPS 234 obligations, organisations should take a risk-based approach to detection, mitigation, and disclosure. This involves:

Working with Specialised Providers: Engage with cybersecurity providers who can offer insights into your organisation's exposure and risk levels based on:
- Network fingerprinting
- Levels of breached credential login attempts
- Prevalence of residential proxy traffic as a high-correlating signal of attack
Continuous Risk Assessment: Regularly evaluate the risk posed by credential stuffing attacks, considering factors such as:
- The volume and sophistication of attempts
- The success rate of attacks
- The potential impact on customers and the organisation
Inadequate Defences as a Risk Signal: Recognise that the absence of robust defences against credential stuffing is itself a risk signal. Organisations without advanced bot detection, multi-factor authentication, and behavioural analysis capabilities may face higher risk and should consider this in their disclosure decisions.
Adaptive Disclosure Thresholds: Develop flexible, risk-based thresholds for APRA notification that take into account:
- The current threat landscape
- The organisation's defensive capabilities
- The potential impact of a successful attack

Assessing Materiality in Light of These Threats

When assessing whether a credential stuffing incident meets the materiality threshold for APRA notification, entities should consider:

Scale of the Attack: The number of accounts targeted or compromised.
Success Rate: Whether any accounts were actually breached.
Exposure on Dark Web Markets: If compromised credentials appear on sites like Crabby Cash.
Potential Financial Impact: Both immediate losses and potential future exploitation.
Non-Financial Impacts: Including reputational damage and loss of customer trust.
Broader Systemic Risk: Whether the attack could impact the wider financial system.
Defensive Posture: The adequacy of existing controls and the organisation's ability to detect and mitigate attacks.

Proactive Measures and Controls

To mitigate the risks of credential stuffing attacks, particularly those leveraging residential proxies, APRA-regulated entities should implement robust controls as outlined in CPS 234 and CPG 234:

Contextual Security Approach: Implement a contextual security strategy that considers multiple factors to assess the risk of each login attempt, including device characteristics, user behaviour patterns, and network attributes.
Advanced Bot Detection: Deploy bot management systems capable of identifying automated attempts, even when they come from diverse IP addresses.
Residential Proxy Detection: Utilise specialised residential proxy detection tools to identify and mitigate threats from this increasingly common attack vector.
Multi-Factor Authentication: As suggested in CPG 234, implement MFA for high-risk activities to provide an additional layer of security beyond passwords.
Behavioural Analysis: Use analytics to detect anomalous login patterns that may indicate credential stuffing attempts.
Continuous Monitoring: Implement real-time monitoring systems to quickly identify and respond to potential attacks.
Password Policies: Encourage or enforce the use of unique, strong passwords to mitigate the impact of credential stuffing.
Customer Education: Proactively inform customers about the risks of password reuse and the importance of strong, unique passwords.
Collaboration and Information Sharing: Engage with industry peers and law enforcement to share threat intelligence and effective practices.
Adaptive Authentication: Implement risk-based authentication that adjusts security requirements based on the perceived threat level of each login attempt.

By adopting these measures, particularly a contextual security approach incorporating residential proxy detection, organisations can improve their resilience against credential stuffing attacks and better protect their customers' accounts.

Conclusion

Credential stuffing, residential proxies, and platforms like Crabby Cash make account takeover risk harder to assess and harder to contain. APRA-regulated entities need a proactive, risk-based approach to information security and regulatory compliance.

APRA-regulated entities should treat credential stuffing attacks as more than a technical control problem. They are business risks that may require Board-level attention and, depending on materiality, regulatory disclosure under CPS 234. By implementing preventative measures, maintaining effective incident response capabilities, and keeping clear processes for assessing and reporting incidents, organisations can better protect themselves and their customers from this growing threat.

In this environment, CPS 234 compliance is not only a reporting exercise. It depends on information security controls that protect the organisation, its customers, and the broader financial system before credential stuffing becomes a material incident.

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.

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.

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.

Dive into CVSS Scores

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

Understanding CVSS through Atlassian Confluence Vulnerabilities

The Common Vulnerability Scoring System (CVSS) gives security teams a shared way to rate the severity of software vulnerabilities. It does not predict risk on its own; it describes the characteristics of a specific security flaw. CVSS uses three metric groups: Base, Temporal, and Environmental. The result is a score from 0 to 10, represented by a vector string that records the details behind the score.

Base Metrics describe the inherent aspects of a vulnerability, including how it can be exploited and its potential system impact.
Temporal Metrics change over time, reflecting current exploitability and available mitigations.
Environmental Metrics account for the specific environment where the vulnerability exists, tailoring the score to the affected organisation.

The National Vulnerability Database (NVD) utilises CVSS to assign base scores and provides tools for calculating Temporal and Environmental scores.

Atlassian Confluence Vulnerability Analysis

Two Atlassian Confluence vulnerabilities show why the vector matters as much as the headline score:

CVE-2023-22515 is a critical flaw with a base score of 10.0. It is exploitable remotely, with low complexity, no privilege requirements, and no need for user interaction. The attack vector is network-based, so exposure is not limited to local access. Its broad scope and impact across confidentiality, integrity, and availability make it a vulnerability that needs immediate attention.

CVE-2023-22518 shares many similarities with CVE-2023-22515, including a critical base score of 10.0. It can also be exploited remotely without privileges or user interaction, and with low complexity. Its impact on the system's confidentiality, integrity, and availability is high, allowing attackers to gain complete control and shut down the affected resources.

Both CVE-2023-22515 and CVE-2023-22518 are critical vulnerabilities that demand urgent remediation. Understanding their CVSS vectors helps prioritise the security response and the mitigations needed.

CVE-2023-22515 carries a CVSS score of 10 because it is remotely exploitable, easy to execute, and does not require privileges or user interaction.

CVSS Vector for CVE-2023-22515

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector indicates:

Attack Vector (AV): Network (N) - The vulnerability is remotely exploitable.
Attack Complexity (AC): Low (L) - It is easy to exploit without major obstacles.
Privileges Required (PR): None (N) - No special access is needed.
User Interaction (UI): None (N) - It can be exploited without user involvement.
Scope (S): Changed (C) - The impact extends beyond the initial target.
Confidentiality, Integrity, Availability (C/I/A): High (H) - There is a complete loss of confidentiality, integrity, and availability.

Atlassian's high CVSS score for CVE-2023-22515 reflects its critical nature and the need for immediate action.

CVE-2023-22518 has the same CVSS score of 10, with similar impact across confidentiality, integrity, and availability.

CVSS Vector for CVE-2023-22518

Base Score: 10.0 (Critical)
Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

This vector means:

Attack Vector (AV): Network (N) - Exploitable remotely.
Attack Complexity (AC): Low (L) - Easy to exploit with minimal barriers.
Privileges Required (PR): None (N) - No user privileges required.
User Interaction (UI): None (N) - No need for user action.
Scope (S): Changed (C) - Broad impact beyond the initial system.
Confidentiality, Integrity, Availability (C/I/A): High (H) - Complete compromise of the system's security.

Understanding the CVSS scores for these vulnerabilities helps teams prioritise their security response. For a full breakdown and history of CVSS, see Wikipedia. More detailed information on CVSS can also be found in FIRST's official CVSS documentation.

A Risk Based Approach To Vulnerability Scoring

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

The Exploit Prediction Scoring System (EPSS) estimates the likelihood that a published CVE will be exploited in the wild. Its value is that it brings several signals into one risk score, instead of treating every vulnerability with the same CVSS severity as equally urgent. The main inputs are:

Data Sources of EPSS

MITRE’s CVE List: EPSS scores only vulnerabilities that are "published" on this list.
Text-based “Tags”: Extracted from CVE descriptions and related discussions.
Publication Duration: The time period since the CVE was published.
Reference Count: The number of references in the CVE entry.
Published Exploit Code: Code from platforms such as Metasploit, ExploitDB, or GitHub.
Security Scanners: Data from security tools such as Jaeles and Nuclei.
CVSS v3 Vectors: Based on the base score in the National Vulnerability Database (NVD).
CPE (vendor) Information: Details about the vendors of the products involved, also from NVD.
Ground Truth Data: Real-world exploitation data from sources such as AlienVault.

EPSS Model and Tools

The current EPSS model, version 2022.01.01, uses 1,164 variables and is based on Gradient Boosting, a machine learning technique. For a visual and interactive view of EPSS scores, the EPSScall tool is useful. It provides historical data and graphs that make score movement easier to inspect.

The Drivers of EPSS Scores

To understand EPSS, it helps to look at which inputs carry the most weight. The variable importance graph shows the strongest contributors to the EPSS score.

Vendor data plays an outsized role in the scoring process. The graph shows how much weight each component has when estimating whether a vulnerability is likely to be exploited.

Why Does This Matter?

EPSS uses these data sources to predict exploit likelihood more directly than severity-only methods. By considering factors from the age of the CVE to real-world exploit instances, EPSS gives defenders a clearer view of which vulnerabilities are more likely to matter operationally. That makes patching and mitigation decisions easier to prioritise when resources are limited.

Understanding the components of EPSS also makes the score easier to interpret. It is not a single severity metric; it is a blend of several data points, each with different weight. Tools like EPSScall make those inputs easier to inspect when tuning a vulnerability management process.

Final Thoughts

EPSS is useful because it shifts vulnerability triage away from severity alone and towards exploit likelihood. Its use of multiple data sources and machine learning makes it a practical tool for defenders who need to decide what to fix first. Prioritising vulnerabilities this way does not replace judgement, but it gives teams a stronger starting point than CVSS alone.

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.

APRA Cybersecurity Guidelines

2023-10-12T12:31:00+11:00

Website cybersecurity is a practical requirement, and Australian organisations have a substantial body of guidance to work from. While the Australian Government's "Essential 8" focuses broadly on workplace security, the Australian Prudential Regulation Authority (APRA) offers a more specific Information Security Manual (ISM) with recommendations that apply to business websites.

Why Website Security Matters

When your business operates a website or web application, you are not just managing content; you are responsible for protecting data. Inadequate security controls expose you to risks such as data breaches, malware, DDoS attacks, and reputational damage. Company executives and operational staff need to implement relevant recommendations to minimise risk and liability if a security breach occurs.

APRA’s ISM: Tailored for Websites

APRA's ISM guidelines are practical for website owners. These are the key recommendations for websites and why they matter:

Network Traffic and Anonymity (ISM-1627, ISM-1628)

Blocking anonymity network traffic reduces the ability of malicious actors to hide their identity. This improves accountability when investigating suspicious requests and reduces security threats.

Cloud Service Providers (ISM-1437)

APRA advises the use of cloud service providers for hosting online services. A well-managed cloud platform can provide security controls and operational maturity that are difficult to match on premises.

Content Delivery Network (ISM-1438)

A CDN is not only a performance tool. It can filter malicious traffic before it reaches the origin and provide an additional layer of security.

Origin Exposure and DDoS Mitigation (ISM-1439)

Hiding the origin IP and using cloud providers for DDoS mitigation helps protect your primary server by dispersing traffic across a distributed network.

Data Encryption (ISM-1781, ISM-1139)

Encrypt all data over the network and use only the latest version of TLS to protect data in transit.

Logging and Auditing (ISM-261, ISM-580, ISM-0585, ISM-1661)

Comprehensive audit logging is vital for tracking activity and identifying irregular patterns. Logs should be detailed and reviewed periodically.

Web Application Firewall (WAF) (ISM-1240, ISM-1490, ISM-1509, ISM-1657)

A WAF provides a control point for monitoring and filtering incoming traffic, enabling you to block harmful requests.

Backup and Configuration (ISM-1511)

Back up your data, website, and configurations, and store them securely, preferably in a version-controlled environment such as Git.

HTTPS and SSL (ISM-1277, ISM-1552)

SSL certificates and HTTPS should be standard for all web content. This helps safeguard data integrity and user confidentiality.

Scaling and Monitoring (ISM-1579, ISM-1581)

Ensure your website can scale during demand spikes and that you have real-time monitoring for capacity and availability.

Virtual Patching and Antivirus Scanning (ISM-1690, ISM-1288, ISM-1694)

Virtual patching and antivirus scanning help protect your website against new vulnerabilities and malware.

Content Types (ISM-0649)

Only allow the specific content types your website needs to run. Restricting this reduces the risk of malicious content affecting your website.

Final Thoughts

Incorporating APRA’s ISM recommendations into your cybersecurity strategy makes your website more resilient against cyberattacks. Treat them as essential operating practices for website security, not as guidance to skim once and set aside.

The Rise of OpenBullet

2023-09-01T14:00:00+10:00

At Peakhour, we are seeing more automation tools used to simplify interaction with web platforms. These tools have legitimate uses, including automating repetitive tasks and testing applications, but they can also be misused. OpenBullet is one example: a flexible web testing suite that has become a common tool for web attacks such as credential stuffing. This article explains how OpenBullet works, why it creates risk, which libraries it relies on, and how defenders can detect and block it.

Overview of OpenBullet

OpenBullet is an automation suite for scraping, parsing data, and automated penetration testing. It is commonly used by bot developers for automated attacks, including credential stuffing. Released under the MIT open-source licence on GitHub, it is now in its second version, OpenBullet2, which, as of March 2023, had over 1.1K stars and was forked roughly 370 times.

It is particularly favoured by people with limited programming knowledge because it is easy to use and supports third-party plugins. The tool uses configurations that define the actions to perform on a website, and those configurations are easy to find online.

Types of Actions with OpenBullet

The actions OpenBullet can perform are categorised by the framework and library used. There are three broad types:

Browser Actions: Open or close tabs, maximise or minimise the browser window, and more.
Page Actions: Visit a page, fetch page attributes, set or clear cookies, click on page elements, take screenshots, and so forth.
Element Actions: Set or get element attributes, click on elements, check their status, fill in text forms, and more.

OpenBullet's versatility has made it attractive to users who share configurations freely. Advanced configurations for tasks such as scraping and credential stuffing can be found on forums and even sold.

OpenBullet Versus Other Testing Suites

One of OpenBullet's main advantages over other testing suites or automation frameworks is ease of use. It offers a visual mode, with a simple UI instead of lines of code. It also includes a high-level programming language for fine-tuning operations. It does not offer the same level of control as direct interaction with its underlying frameworks, but it can still cause significant issues for websites.

Why OpenBullet is Dangerous

OpenBullet is a threat because its simple UI lets people without programming skills create automated sequences for web attacks. Its integration with CAPTCHA farms also makes it effective against websites that rely on traditional CAPTCHAs for bot protection.

After installing OpenBullet, an attacker needs to create or import a configuration and manage bot behaviour. They can also configure proxies to distribute attacks, hide their real IP addresses, and sidestep traditional rate limiting.

OpenBullet also supports attacks like credential stuffing through a range of integrations. Attackers can add new credentials, store valid credentials, and set the configuration to run for any duration they choose.

We can, however, counter OpenBullet by detecting and blocking the frameworks on which it relies.

OpenBullet and Its Underlying Libraries

OpenBullet relies on several well-known bot automation libraries and frameworks:

Requests: A Python module for sending HTTP requests with forged attributes. It's highly scalable and can bypass traditional CAPTCHAs using external CAPTCHA farm services. However, it struggles against highly protected sites and mobile applications.
Selenium: This is a browser automation framework initially developed for testing web applications. It can interact with a web service as a human user would, helping attackers mask their bots with human-like behaviours.
Puppeteer: This Node.js library controls Chromium-based browsers. It's faster and lighter than Selenium, making it capable of running more parallel requests.

OpenBullet does not inherently simulate human behaviour; the bot developer has to implement that. Based on an analysis of online configurations, most do not include fake human behaviour features. OpenBullet does, however, support ad hoc JavaScript execution to enable them.

Detecting and Blocking OpenBullet

To detect and block OpenBullet, defenders need to understand where a request is coming from, especially when proxies are used to distribute attacks. OpenBullet can be effective in the wrong hands, but it is not invisible. Several signals can help identify and block its activity.

Identifying Unusual Patterns

Most automated tools, including OpenBullet, generate request patterns that differ from typical human behaviour. The frequency, timing, and sequence of requests can help identify potential OpenBullet attacks. For instance, a high volume of requests from a single IP address, or repeated requests with different login credentials, could indicate automation.

Analysing User Agents

User agents can also provide useful clues. OpenBullet can mimic different user agents to look like a range of browsers, but it may not simulate the broader spread of user agents an actual user base would generate. If an unusual number of requests come from a small set of user agents, it may indicate an automated attack.

Spotting IP Address Anomalies

OpenBullet, like many automated tools, uses proxies to mask its true location and appear to be many different users. Proxies have their own characteristics. Data centre proxies, for instance, do not behave like residential or mobile IP addresses, and they can be flagged as suspicious. Similarly, if many different user identities come from a single IP address, or if the geolocation of an IP address does not match the stated location of the user, it may signal proxy use.

OpenBullet in the Greater Cybersecurity Context

OpenBullet reflects a broader pattern in cybersecurity: tools built for testing can be repurposed for abuse. Its simple UI and automation capabilities show why online security cannot depend on basic controls alone. Although it was created as a web testing tool, its misuse reinforces the need to keep defences current as attack methods change.

The Need for Strong Password Practices

OpenBullet's popularity for credential stuffing attacks underscores the importance of strong password practices. Encouraging users to create unique passwords for each account and change them regularly can help reduce the risks posed by credential stuffing.

Implementing Advanced Bot Protection Measures

To secure online services against tools like OpenBullet, advanced bot protection matters. These measures can provide a multi-layered security strategy that runs in the background, collects detection signals, and challenges users only when necessary. They can help stop bot attacks from the first request, including those carried out through OpenBullet's automation framework.

As web platforms evolve, the tools used to exploit them evolve as well. Understanding threats like OpenBullet is the first step towards stronger online protection.

Peakhour's advanced Bot Management and rate limiting capabilities can help protect your site from automated tools like OpenBullet. Contact our team for a free security analysis.

Advanced Rate Limiting

One practical defensive measure against stuffing attacks, including those made using OpenBullet, is advanced rate limiting. Unlike basic rate limiting, which restricts the number of requests from a particular source within a specified time frame, advanced rate limiting provides a more nuanced and dynamic approach.

A critical feature of advanced rate limiting is its ability to group, or bucket, requests based on factors beyond the source IP address. These factors could include:

Autonomous System Number (ASN): An ASN is a unique number assigned to each network on the Internet. By grouping requests by ASN, it's possible to detect an unusual number of requests from a specific network, even if those requests are spread across many different IP addresses.
Country: Grouping requests by country allows the detection of a sudden surge of traffic from a specific geographic location, which might indicate a coordinated attack.
Device Fingerprint: A device fingerprint can be constructed from a range of attributes, including the device's operating system, browser version, and more. This allows the detection of repeated requests coming from the same device, even if other factors like the IP address or user agent are being manipulated.
Headers: By examining the headers in HTTP requests, it's possible to detect patterns or anomalies that might signify an automated attack. For instance, a high volume of requests with identical headers could indicate the use of an automation tool.

By grouping requests on these and other factors, advanced rate limiting can provide a nuanced and dynamic defence against stuffing attacks. It allows detection of complex attack patterns that might otherwise go unnoticed, adding a useful layer of security for online systems.

Fingerprinting and Behavioral Analysis

Alongside advanced rate limiting, technologies like fingerprinting and behavioural analysis add another layer of protection. By creating a unique identifier for each user based on a combination of factors, such as IP address, device information, and browser settings, and tracking that user's behaviour over time, these technologies can help distinguish genuine users from automated scripts.

These mechanisms can detect anomalies, such as repetitive non-human patterns, sudden changes in behaviour, or usage patterns that do not match the typical profile of a human user. This level of analysis can identify and block even sophisticated bots that are designed to mimic human behaviour, providing an effective defence against OpenBullet and similar tools.

OpenBullet's accessibility and versatility have made it a popular choice for web attacks. Its simple UI, support for CAPTCHA farm services, and ability to run human-like automation allow even users with limited programming skills to execute complex attacks. Despite these challenges, detecting and blocking OpenBullet is achievable by understanding the origin of requests and the nature of its operation. A combination of advanced rate limiting, fingerprinting, and behavioural analysis can provide an effective defence.

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.

Advanced Anomaly Detection

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

Modern Application Security Platforms need reliable anomaly detection to identify and respond to emerging threats in real-time. For DevOps, SRE, and DevSecOps teams, machine learning algorithms such as Robust Random Cut Forest (RRCF) provide the foundation for automated threat detection and response systems that can operate at the scale and speed contemporary applications require.

Strategic Importance of Anomaly Detection in Application Security

Real-time anomaly detection is a core Application Security Platform capability. It helps identify threats before attacks affect application performance or security posture:

Enterprise Threat Landscape

Modern applications face attack vectors that traditional signature-based detection cannot address:

Adaptive Bot Networks: AI-powered bots that modify behaviour based on defensive responses
Zero-Day Exploits: Previously unknown attack patterns that bypass traditional security rules
Volumetric Attacks: DDoS attacks that scale dynamically to evade rate limiting
Insider Threats: Subtle anomalies in user behaviour that indicate account compromise

Application Security Platform Requirements

Effective anomaly detection needs to integrate cleanly with broader security capabilities:

Real-Time Processing: Threat identification within milliseconds of detection
Scalable Architecture: Analysis of millions of requests without performance degradation
Context Awareness: Integration with application metadata and user behaviour profiles
Automated Response: Immediate threat mitigation through dynamic rule deployment

Advanced Machine Learning for Security

Robust Random Cut Forest provides anomaly detection capabilities designed for streaming data environments common in Application Security Platforms:

Algorithmic Advantages for Security Applications

Streaming Data Processing: Real-time analysis without historical data dependencies
Dimensionality Handling: Effective analysis of high-dimensional security feature vectors
Adaptive Learning: Continuous model updates based on evolving traffic patterns
Computational Efficiency: Linear scaling suitable for high-throughput security processing

Implementation in Application Security Platforms

RRCF enables threat detection across multiple security dimensions:

Traffic Pattern Analysis: Identification of unusual request volumes, frequencies, and distributions
Behavioural Anomalies: Detection of user actions that deviate from established profiles
Network Fingerprinting: Recognition of abnormal connection patterns and protocol usage
Content Analysis: Identification of malicious payloads and injection attempts

RRCF Advantages for Application Security Platforms

Traditional batch-processing anomaly detection systems are a poor fit for Application Security Platforms that must respond to threats in real-time. RRCF's streaming approach provides practical advantages:

Real-Time Threat Detection

Immediate Analysis: Process and analyse security events as they occur, without waiting for batch processing
Adaptive Baselines: Continuously update normal behaviour models based on current traffic patterns
Memory Efficiency: Maintain configurable rolling windows of security data for optimal performance
Scalable Processing: Handle millions of security events per second without degradation

Security-Optimised Implementation

RRCF's forest-based approach is useful for security applications:

Multi-Dimensional Analysis: Analyse request patterns, user behaviour, and network characteristics at the same time
Shape-Sensitive Detection: Identify subtle changes in attack patterns that signature-based systems miss
False Positive Reduction: Leverage ensemble methods to reduce noise in security alerting
Contextual Awareness: Understand normal application behaviour patterns for more accurate threat detection

Application Security Platform Integration

Enterprise Deployment Architecture

Peakhour's Application Security Platform implements RRCF through high-performance Rust-based processing:

Edge Processing Capabilities

Global Deployment: RRCF analysis deployed across CDN edge locations for minimal latency
Distributed Learning: Aggregated threat intelligence from multiple geographic regions
Local Response: Immediate threat mitigation at the edge without central processing delays
Bandwidth Optimisation: Process security events locally to reduce data transmission requirements

Platform Integration Benefits

Unified Threat Detection: RRCF analysis integrated with WAF/WAAP, bot management, and DDoS protection
Automated Response: Dynamic security rule generation based on anomaly detection results
DevSecOps Workflow: API-first architecture enabling integration with security automation tools
Compliance Reporting: Detailed anomaly detection logs for security audits and regulatory requirements

Advanced Security Use Cases

Credential Stuffing Detection

Behavioural Analysis: Identify unusual login patterns that indicate automated credential testing
Geographic Anomalies: Detect impossible travel scenarios and location-based attack patterns
Volume Analysis: Recognise subtle increases in authentication attempts that indicate coordinated attacks
Success Rate Monitoring: Identify campaigns through abnormal authentication success/failure ratios

API Threat Detection

Endpoint Anomalies: Detect unusual API usage patterns that indicate reconnaissance or exploitation
Rate Pattern Analysis: Identify sophisticated rate limiting evasion techniques
Response Time Analysis: Detect performance impacts from malicious API usage
Authentication Anomalies: Recognise token abuse and API key misuse patterns

Zero-Day Threat Identification

Traffic Pattern Deviations: Identify new attack vectors through unusual request characteristics
Response Pattern Analysis: Detect exploitation attempts through server response anomalies
Protocol Anomalies: Recognise malformed requests that indicate exploit attempts
Payload Analysis: Identify suspicious content patterns in request bodies and parameters

Operational Excellence Through Advanced Anomaly Detection

Performance and Security Integration

RRCF implementation delivers measurable improvements across security and performance metrics:

Threat Detection Speed: Sub-millisecond anomaly identification for real-time response
False Positive Reduction: Ensemble methods reduce security alert fatigue
System Performance: Efficient processing maintains CDN performance whilst enhancing security
Adaptive Learning: Continuous improvement in threat detection accuracy over time

DevSecOps Enablement

Modern Application Security Platforms provide APIs and automation capabilities:

Security Automation: Programmatic access to anomaly detection results for automated response
CI/CD Integration: Security testing and validation integrated into development workflows
Monitoring Integration: SIEM and SOC platform integration for security operations
Custom Rule Development: Framework for developing application-specific anomaly detection rules

Final Thoughts

Advanced anomaly detection through RRCF is a fundamental capability for modern Application Security Platforms. By implementing machine learning algorithms at the edge, organisations can achieve real-time threat detection that adapts to evolving attack patterns whilst maintaining application performance.

The integration of RRCF with security capabilities including WAAP, bot management, and DDoS protection creates a unified platform that addresses the security requirements of contemporary applications and APIs. For DevSecOps teams, this approach enables automated threat response whilst providing the visibility and control needed for effective security operations.

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.

Application Performance Optimisation

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

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

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

Start With the First Request

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

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

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

Use WebPageTest for the Waterfall

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

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

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

Use Lighthouse for Browser Work

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

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

Connect Metrics to Causes

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

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

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

Diagnose the Common Failures

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

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

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

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

Where Peakhour Evidence Fits

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

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

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

WordPress Performance Optimisation

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

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

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

Start With Public Page Caching

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

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

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

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

Publishing Should Not Clear the Whole Site

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

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

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

Images and Browser Work Still Matter

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

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

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

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

Protect Expensive WordPress Paths

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

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

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

Measure the Outcome

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

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

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