DEV Community: Alvin

Video Streaming Protocols: HLS vs DASH vs WebRTC vs SRT, RTMP, and RTSP

Alvin — Wed, 02 Sep 2026 02:27:00 +0000

Article Categories

Video Streaming Basics
Protocol Comparison
- HLS
- MPEG-DASH
- WebRTC
- SRT
- RTMP
- RTSP
How to Choose a Video Streaming Protocol
CDNetworks Streaming Solutions
Common Mistakes
FAQs
Conclusion

What are video streaming protocols?

Video streaming protocols define how video data is prepared, transmitted, and delivered from a source to a viewer or application.

Different protocols are designed for different requirements. Some use segmented media files for scalable CDN delivery, while others transmit real-time media packets for applications where latency matters more than scale.

A typical streaming workflow looks like this:

Camera / Video File
        ↓
Encoder
        ↓
H.264 / HEVC
        ↓
Packaging
        ↓
Streaming Protocol
        ↓
Media Server / CDN
        ↓
Player / Application
        ↓
Viewer

Live video usually starts with a camera or encoder, while video-on-demand (VoD) starts with a stored media file.

The video is commonly compressed using codecs such as H.264 or HEVC before being packaged into formats such as MP4 or CMAF.

Which video streaming protocols are most common?

The six protocols you'll encounter most often are HLS, MPEG-DASH, WebRTC, SRT, RTMP, and RTSP.

Protocol	Main use case	Typical latency	Transport
HLS	Large-scale live and VoD delivery	~6–30s; lower with LL-HLS	HTTP/TCP
MPEG-DASH	OTT and adaptive video delivery	~6–30s; lower with LL-DASH	HTTP/TCP
WebRTC	Real-time communication	Typically <500ms	RTP/SRTP, usually UDP
SRT	Live contribution	Sub-second to a few seconds	UDP
RTMP	Encoder ingest	~2–5s	TCP
RTSP	IP cameras and surveillance	Implementation-dependent	RTP over TCP/UDP

These latency figures are typical rather than guaranteed. Encoding, buffering, segment duration, network conditions, and player configuration can significantly affect end-to-end latency.

What is HLS?

HLS (HTTP Live Streaming) is an HTTP-based adaptive streaming protocol developed by Apple. HLS is widely used for large-scale live streaming and video-on-demand delivery.

HLS divides video into smaller media segments and uses playlists to tell the player which segments to request.

Encoder
   ↓
HLS Segments + Playlist
   ↓
HTTP Server / CDN
   ↓
HLS Player

How does HLS compare with other video streaming protocols?

HLS is primarily designed for scalable viewer delivery rather than real-time communication.

Compared with WebRTC, HLS generally has higher latency but is easier to distribute through HTTP infrastructure and CDNs. Compared with RTMP and SRT, HLS is more suitable for viewer playback than live contribution or ingest.

What are the advantages of HLS?

Broad compatibility across mobile devices, smart TVs, and streaming platforms.
Works with standard HTTP infrastructure and CDNs.
Supports adaptive bitrate streaming.
Scales well for large audiences.

What are the limitations of HLS?

Traditional HLS introduces several seconds of latency because the player downloads and buffers media segments.

For interactive applications such as video calls, traditional HLS is usually not appropriate. LL-HLS can reduce latency while retaining HTTP and CDN-based delivery.

What is MPEG-DASH?

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is an open international adaptive streaming standard developed by MPEG.

Like HLS, MPEG-DASH uses HTTP delivery, media segments, and adaptive bitrate streaming. MPEG-DASH is vendor-neutral and supports multiple codecs and media formats.

How does MPEG-DASH compare with HLS?

HLS and MPEG-DASH use similar HTTP-based delivery models and are both suitable for scalable video distribution.

The main difference is that MPEG-DASH is an open, vendor-neutral international standard, while HLS originated from Apple.

Feature	HLS	MPEG-DASH
Standard	Apple-developed	MPEG international standard
HTTP delivery	Yes	Yes
Adaptive bitrate	Yes	Yes
CDN-friendly	Yes	Yes
Vendor-neutral	No	Yes
Low-latency option	LL-HLS	LL-DASH
Common uses	Live, VoD, OTT	OTT, VoD, multi-device delivery

What are the advantages of MPEG-DASH?

Open, vendor-neutral streaming standard.
Supports multiple codecs and media formats.
Works with HTTP infrastructure and CDNs.
Suitable for OTT, VoD, and multi-device delivery.

What are the limitations of MPEG-DASH?

MPEG-DASH can require additional player support in environments where native browser compatibility is limited.

Its flexibility can also increase implementation complexity across different playback environments.

What is WebRTC?

WebRTC (Web Real-Time Communication) is an open-source framework for real-time audio, video, and data communication between browsers and applications.

WebRTC is designed for applications where low latency and real-time interaction are more important than CDN-oriented one-to-many distribution.

Common use cases include:

Video conferencing.
Online meetings.
Interactive live streaming.
Gaming.
Real-time collaboration.
Browser-based communication.

How does WebRTC compare with HLS and MPEG-DASH?

WebRTC typically provides much lower latency than HLS and MPEG-DASH, making WebRTC better suited to interactive applications.

HLS and MPEG-DASH are generally easier to distribute at large scale through CDNs. WebRTC deployments can require additional media infrastructure such as relay servers or media servers.

What are the advantages of WebRTC?

Typically sub-second latency.
Native support in modern browsers.
Real-time audio, video, and data communication.
Encrypted media transport.
Strong fit for interactive applications.

What are the limitations of WebRTC?

WebRTC can require significantly more media infrastructure as concurrent users increase.

WebRTC is therefore not automatically the best choice for large-scale one-to-many video distribution. HLS or MPEG-DASH may be more practical when scalability is the primary requirement.

What is SRT?

SRT (Secure Reliable Transport) is a low-latency transport protocol designed for reliable video transmission over unpredictable networks.

SRT is commonly used for live contribution and remote production.

Remote Encoder
      ↓
     SRT
      ↓
Production / Media Server
      ↓
HLS / DASH / WebRTC
      ↓
Viewers

How does SRT compare with other video streaming protocols?

SRT is primarily a contribution and transport protocol rather than a viewer playback protocol.

Compared with WebRTC, SRT is more commonly used to transport professional video between production systems. Compared with HLS and MPEG-DASH, SRT is not designed primarily for large-scale viewer distribution.

What are the advantages of SRT?

Reliable transmission over unstable networks.
Packet-loss protection and recovery.
Low-latency transport.
Encryption capabilities.
Suitable for professional contribution workflows.

What are the limitations of SRT?

SRT requires compatible encoders, decoders, gateways, or media servers.

SRT is generally used inside the streaming workflow rather than directly in a viewer's browser.

What is RTMP?

RTMP (Real-Time Messaging Protocol) is a mature streaming protocol that remains widely used for live stream ingest.

RTMP was originally developed for audio, video, and data delivery to Flash-based players. Although Flash playback is obsolete, RTMP remains common for sending live video from encoders to streaming platforms.

Encoder
   ↓
  RTMP
   ↓
Streaming Platform
   ↓
Processing
   ↓
HLS / DASH / WebRTC
   ↓
Viewers

How does RTMP compare with other video streaming protocols?

RTMP is primarily used for ingest, while HLS, MPEG-DASH, and WebRTC are more commonly used for viewer delivery.

RTMP is simpler for encoder-to-platform workflows but lacks the modern browser playback compatibility of HTTP-based streaming protocols.

What are the advantages of RTMP?

Broad compatibility with live encoders.
Supported by many streaming platforms.
Simple encoder-to-server workflow.
Mature and widely adopted ecosystem.

What are the limitations of RTMP?

RTMP is not well suited to direct browser playback because modern browsers no longer support the Flash environment for which RTMP playback was originally designed.

For viewer delivery, HLS, MPEG-DASH, or WebRTC are generally more appropriate.

What is RTSP?

RTSP (Real-Time Streaming Protocol) is a network control protocol used to establish, manage, and control real-time media sessions.

RTSP is widely used with IP cameras, surveillance systems, network video recorders, and professional video equipment.

RTSP typically works with RTP (Real-time Transport Protocol) for actual media transmission.

How does RTSP compare with other video streaming protocols?

RTSP is commonly used for device-level streaming, particularly with IP cameras.

Unlike HLS and MPEG-DASH, RTSP is not designed for large-scale CDN delivery. Unlike WebRTC, RTSP does not provide direct modern browser playback.

A media server can ingest RTSP and convert the stream into HLS or WebRTC for web-based applications.

What are the advantages of RTSP?

Strong compatibility with IP cameras.
Supports real-time media session control.
Widely used in surveillance systems.
Suitable for dedicated streaming environments.

What are the limitations of RTSP?

Modern web browsers generally do not support direct RTSP playback.

Web applications therefore often require a media server or gateway to convert RTSP into a browser-compatible protocol such as HLS or WebRTC.

How do you choose the right video streaming protocol?

The right protocol depends on latency, audience size, compatibility, security, network conditions, and where the protocol is used in the streaming workflow.

Requirement	Recommended protocol
Large-scale live streaming	HLS
Large-scale VoD	HLS / MPEG-DASH
OTT delivery	HLS / MPEG-DASH
Interactive streaming	WebRTC
Video conferencing	WebRTC
Remote production	SRT
Encoder ingest	RTMP
IP cameras	RTSP

Which protocol provides the best compatibility?

Choose HLS when broad device and platform compatibility is important.

Choose WebRTC for modern browser-based real-time applications. MPEG-DASH provides an open adaptive streaming standard but may require a compatible player.

Which protocol provides the lowest latency?

WebRTC is commonly used for the lowest-latency interactive streaming.

SRT is commonly used for reliable low-latency contribution, while HLS and MPEG-DASH prioritize scalable delivery and playback stability.

Which protocol is best for adaptive bitrate streaming?

HLS and MPEG-DASH are the most common choices for adaptive bitrate streaming.

Both protocols can provide multiple video representations and allow the player to switch between bitrates based on bandwidth and device conditions.

How do security requirements affect protocol selection?

SRT provides encryption capabilities for contribution workflows, while WebRTC uses encrypted media transport.

HLS and MPEG-DASH can use HTTPS, access controls, tokenized URLs, and DRM to protect video delivery.

How does CDNetworks support different video streaming protocols?

Choosing a streaming protocol is only part of the architecture. The underlying infrastructure also needs to support different delivery models, from large-scale video distribution to low-latency and contribution workflows.

CDNetworks supports HLS, MPEG-DASH, WebRTC, RTMP, and SRT, allowing streaming workflows to use different protocols at different stages. CDN-based delivery, optimized routing, and scalable infrastructure help support high-concurrency streaming while maintaining stable playback.

Whether you need large-scale live streaming, low-latency streaming, or video-on-demand (VoD) delivery, CDNetworks provides infrastructure for different streaming requirements without forcing every use case into a single protocol.

Large-scale live streaming — scalable delivery for high-concurrency audiences
Low-Latency Streaming — real-time and interactive video delivery
Video-on-Demand (VoD) Delivery — scalable delivery for on-demand content

Need help choosing the right streaming protocol? Contact CDNetworks to explore a streaming solution for your use case.

What are common mistakes when choosing a streaming protocol?

Using WebRTC for every streaming application

WebRTC provides excellent latency, but low latency does not automatically make WebRTC the best choice for large-scale one-to-many delivery.

HLS or MPEG-DASH can provide a more CDN-friendly distribution model for large audiences.

Using RTMP for browser playback

RTMP remains useful for ingest, but modern browsers are not designed for Flash-era RTMP playback.

Use RTMP primarily to move live video from an encoder into a streaming platform.

Expecting HLS to provide real-time interaction

Traditional HLS uses segment-based delivery and buffering.

If viewers need to interact with live video with sub-second latency, WebRTC is generally a better starting point.

Treating RTSP as browser-compatible

RTSP works well with IP cameras but usually requires protocol conversion before browser playback.

A media server can ingest RTSP and convert the stream into HLS or WebRTC.

Choosing only one protocol

Production streaming systems often use multiple protocols.

For example:

IP Camera → RTSP
Remote Encoder → SRT
Live Encoder → RTMP
              ↓
        Media Platform
              ↓
     ┌────────┼────────┐
     ↓        ↓        ↓
    HLS     DASH    WebRTC
     ↓        ↓        ↓
   CDN      CDN   Real-time Users

Using different protocols at different stages is often more practical than forcing one protocol to handle the entire workflow.

Video Streaming Protocols FAQs

What are the most common video streaming protocols?

The most common video streaming protocols are HLS, MPEG-DASH, WebRTC, SRT, RTMP, and RTSP.

HLS and MPEG-DASH are widely used for scalable delivery, WebRTC is designed for real-time communication, SRT is commonly used for contribution, RTMP is widely used for ingest, and RTSP is common with IP cameras.

Which video streaming protocol is best for low-latency streaming?

WebRTC is commonly used for the lowest-latency interactive streaming. SRT is commonly used for reliable low-latency contribution.

Is HLS or WebRTC better for live streaming?

HLS is generally better for large-scale live streaming, while WebRTC is better for interactive live streaming.

Should I use TCP or UDP for video streaming?

HLS and MPEG-DASH commonly use HTTP over TCP. WebRTC and SRT commonly use UDP-based transport because their architectures prioritize low-latency media delivery.

Which protocol should I use for an IP camera?

RTSP is commonly used for IP cameras. A media server can convert RTSP into HLS or WebRTC when the video needs to be displayed in a web browser.

Is SRT a playback protocol?

No. SRT is primarily a secure, reliable contribution and transport protocol. A streaming platform can receive SRT and distribute the processed video through HLS, MPEG-DASH, or WebRTC.

Is RTMP still relevant?

Yes. RTMP remains relevant primarily for live stream ingest.

RTMP is widely supported by encoders and streaming platforms, while HLS, MPEG-DASH, and WebRTC are generally more appropriate for viewer playback.

Conclusion

There is no single best video streaming protocol.

Use HLS or MPEG-DASH for scalable HTTP-based delivery and adaptive bitrate streaming. Use WebRTC for interactive, sub-second video. Use SRT for reliable low-latency contribution, RTMP for encoder ingest, and RTSP for IP cameras and dedicated media systems.

The most practical streaming architecture often combines several protocols:

RTSP, RTMP, or SRT for ingest and contribution → HLS, MPEG-DASH, or WebRTC for viewer delivery.

Choose the protocol based on the requirements of each stage: latency, scale, compatibility, network conditions, security, and infrastructure.

What does your streaming stack use today? Have you had to combine multiple protocols to solve a production streaming problem?

DDoS Attacks Explained for Developers: How They Work and What They Break

Alvin — Thu, 27 Aug 2026 02:38:05 +0000

Your application can be healthy and still become unreachable.

The latest deployment may be fine. Your database may still be running. Your application processes may not have crashed.

Yet users suddenly start seeing timeouts, connection failures, unusually high latency, or 5xx errors.

One possible explanation is that a distributed denial-of-service attack is crowding out legitimate requests.

For developers, SREs, DevOps teams, and anyone responsible for an internet-facing application, it helps to understand DDoS attacks in terms of one simple question:

Which finite resource is the attacker trying to exhaust?

That resource could be bandwidth. It could be TCP connection state. It could be CPU, memory, database connections, or application-processing capacity.

Once you look at DDoS this way, the different attack types become much easier to understand.

TL;DR

A Distributed Denial of Service (DDoS) attack sends traffic or requests from multiple distributed sources toward the same website, server, API, network, or application.

The objective is usually not to break into the system. It is to consume enough available capacity that legitimate users can no longer use the service normally.

There are three broad categories:

Attack type	What it tries to exhaust	Examples
Volumetric	Network bandwidth	UDP floods, DNS amplification
Protocol	Connection and network-device resources	SYN floods, ACK floods
Application layer	Application and backend resources	HTTP floods, Slowloris

A real campaign can use more than one of these at the same time.

What actually happens during a DDoS attack?

Imagine an API that normally handles 10,000 requests per second comfortably.

Under legitimate load, the requests are distributed across endpoints, users, sessions, and normal usage patterns.

Now imagine hundreds of thousands of machines—or reflected third-party services—begin sending traffic toward that API or the infrastructure in front of it.

The attack generally follows a pattern like this:

1. Distributed traffic sources are assembled

Attackers can use compromised computers, routers, IoT devices, cloud systems, or other internet-connected machines.

A collection of compromised devices under remote control is commonly called a botnet.

Attackers can also use reflection attacks. Instead of sending all traffic directly, they cause third-party services to send responses toward the victim.

2. A target is selected

The target could be:

a domain
an IP address
a web application
an API endpoint
a DNS service
a game service
a TCP or UDP service

Attackers may also change targets during a campaign.

3. Traffic arrives at scale

The distributed systems begin generating packets, connections, or application requests.

At this point, the question becomes:

Where does the bottleneck appear first?

4. A finite resource is exhausted

Depending on the attack, the target may run short of:

network bandwidth
connection-table capacity
CPU
memory
worker processes
database connections
application threads
upstream service capacity

Legitimate traffic now competes with malicious traffic for the same resources.

The result can be increased latency, connection failures, application errors, or complete service unavailability.

The three DDoS categories developers should know

1. Volumetric attacks: overwhelm the pipe

A volumetric DDoS attack aims to consume available network capacity.

Think of this as filling the road before legitimate traffic can even reach your application.

Typical examples include:

UDP floods
ICMP floods
DNS amplification
NTP amplification

From an application perspective, this can be frustrating because your origin may technically still be healthy.

It simply becomes difficult or impossible to reach.

These attacks are commonly discussed in bits per second (bps) because the amount of network traffic itself is central to the attack.

2. Protocol attacks: exhaust connection-handling resources

Protocol attacks focus more on how networking systems maintain connections or process packets.

A classic example is the SYN flood.

Normally, establishing a TCP connection involves a handshake. A SYN flood creates large numbers of connection attempts without allowing the normal process to complete.

Enough unfinished connections can consume finite connection-handling resources.

Other examples include:

ACK floods
TCP floods
fragmentation attacks

These attacks are often measured in packets per second (pps).

3. Application-layer attacks: make the application work

This is often the most interesting category from a developer perspective.

An application-layer, or Layer 7, attack can send HTTP requests that look technically valid.

Instead of simply throwing enormous amounts of bandwidth at the target, the attacker may repeatedly request operations that are expensive for the application.

Consider endpoints such as:

POST /login
GET /search?q=...
POST /checkout
GET /api/reports

A single request might be harmless.

But what if each request triggers several downstream operations?

HTTP request
    ↓
Authentication check
    ↓
Application logic
    ↓
Database query
    ↓
Cache lookup
    ↓
Third-party/API call
    ↓
Response

Now multiply that work across a large number of malicious requests.

An attacker can create significant backend pressure without generating the same raw bandwidth as a volumetric attack.

Typical application-layer examples include:

HTTP GET floods
HTTP POST floods
Slowloris-style attacks
attacks targeting login or search functions
attacks targeting expensive API endpoints

These attacks are commonly discussed in requests per second (rps).

Why Layer 7 attacks can be difficult to spot

Blocking obviously malformed traffic is one thing.

Blocking requests that look similar to real users is much harder.

An HTTP request can be syntactically correct and still be malicious in context.

Consider a sudden increase in searches.

Is it:

a successful marketing campaign?
a crawler?
a newly released integration?
an aggressive bot?
a DDoS attack?

This is why application-layer DDoS detection often depends on behavior, not simply individual IP addresses.

Useful signals can include:

request-rate changes
repeated access to particular endpoints
unusual user-agent patterns
session behavior
geographic distribution
request parameters
client reputation
deviation from normal traffic baselines

There is rarely one magic threshold that identifies every DDoS attack.

What might developers see in production?

One reason DDoS incidents can initially be confusing is that they can resemble ordinary reliability problems.

Unexpected request or traffic spikes

Traffic increases quickly without a corresponding campaign, event, release, or other business explanation.

Rising latency

Requests that normally complete quickly begin taking significantly longer.

5xx errors and timeouts

Backend resources become constrained and legitimate requests fail.

Connection exhaustion

Load balancers, proxies, firewalls, or application infrastructure begin approaching connection limits.

One endpoint suddenly becomes very expensive

Highly distributed traffic

Similar behavior appears across many IP addresses, networks, or geographic locations.

Resource pressure

CPU, memory, bandwidth, connection tables, or database connection pools remain unusually high.

The important point is that none of these signals should be evaluated in isolation.

A useful baseline of normal traffic makes abnormal behavior much easier to recognize.

DoS vs. DDoS: what's the practical difference?

Both denial-of-service and distributed denial-of-service attacks are intended to affect availability.

The biggest difference is distribution.

Characteristic	DoS	DDoS
Traffic sources	Usually one or relatively few	Many distributed sources
Scale	Generally more limited	Can become extremely large
Blocking sources	Often more straightforward	Much more difficult
Resilience	Easier to interrupt at source	Distributed infrastructure makes this harder
Mitigation	Usually simpler	Often requires distributed filtering

With a DDoS campaign, blocking one attacking IP address may accomplish almost nothing.

Another thousand—or hundred thousand—sources can continue sending traffic.

What a 1.01 Tbps attack looked like in the real world

The scale stops being abstract when you look at an actual incident.

In a customer case documented by CDNetworks, a major software download platform was targeted by a ransom DDoS campaign.

During the campaign, the largest observed attack reached 1.01 Tbps and primarily combined SYN flood and ACK flood traffic.

The broader campaign lasted for more than a month.

There are several useful engineering lessons in that incident:

DDoS campaigns can be multi-vector.
You may not be defending against one fixed attack pattern.
Attack intensity can change.
A campaign can move between lower-volume and extremely high-volume periods.
Origin infrastructure should not be your only line of defense.
Very large attacks may need to be filtered before they consume the network path to the origin.
Availability means preserving legitimate traffic, not simply blocking traffic.
Dropping everything would technically stop the attack—but it would also accomplish the attacker's goal.

So how does DDoS mitigation work?

There isn't a single universal mitigation rule.

The response depends heavily on the attack layer.

At the network edge

Large volumetric attacks may need distributed capacity and upstream traffic scrubbing so malicious traffic is removed before reaching origin infrastructure.

At the protocol layer

Mitigation may involve connection validation, packet filtering, rate controls, and other mechanisms designed to prevent protocol-resource exhaustion.

At the application layer

Defenses can include:

behavioral analysis
rate controls
WAF policies
bot management
endpoint-specific rules
client reputation signals
adaptive thresholds

The objective is not simply:

Block more traffic.

It is:

Identify and remove malicious traffic while allowing legitimate users to continue reaching the application.

That distinction matters.

A practical DDoS-readiness checklist for engineering teams

Before the incident happens, ask:

Do we know what normal traffic looks like?
Do we monitor bandwidth, packets, connections, and application requests separately?
Which application endpoints are computationally expensive?
Which endpoints can trigger large numbers of database operations?
Are origin IP addresses exposed unnecessarily?
Do we understand our load balancer and connection limits?
What happens when a dependency becomes saturated?
Who makes the decision to activate mitigation?
Can high-volume malicious traffic be filtered before reaching the origin?
Have engineering, networking, security, and incident-response teams agreed on an escalation process?

DDoS resilience is partly a security problem.

It is also an architecture, observability, networking, and incident-response problem.

Quick FAQ

Does DDoS mean the attacker has breached the application?

Not necessarily.

DDoS primarily targets availability rather than confidentiality. A service can be overwhelmed without the attacker gaining access to protected data.

However, security teams should still investigate other activity occurring during the incident. A disruptive attack can coexist with other malicious behavior.

How long can a DDoS attack last?

There is no standard duration.

An attack might last minutes or hours, or repeatedly return over a much longer campaign.

Can autoscaling solve DDoS?

Autoscaling can help applications absorb some legitimate demand and certain resource pressures, but it should not be treated as complete DDoS protection.

If an attacker can simply force you to provision more infrastructure—or saturate capacity upstream of that infrastructure—the fundamental problem remains.

Can small applications be targeted?

Yes.

Any public application, website, API, network service, or online platform can potentially be targeted.

Final thought

The most useful mental model for developers is not simply:

“DDoS means lots of traffic.”

Instead ask:

What resource is being exhausted, where is that resource located, and can malicious traffic be separated from legitimate traffic before it reaches that bottleneck?

Those three questions explain a surprising amount about both DDoS attacks and DDoS defense.

Scaling AI Aggregators: Solving Performance and API Security Challenges

Alvin — Wed, 19 Aug 2026 01:38:00 +0000

AI aggregators, also known as multi-model AI platforms, give users access to multiple AI models such as ChatGPT, Claude, and Gemini through a single interface.

The product experience is simple. The infrastructure behind it isn't.

As these platforms scale, requests may pass through different model providers, regions, and network paths before reaching the user. At the same time, public APIs become targets for unauthorized access, automated scraping, malicious requests, and DDoS attacks.

Two infrastructure challenges become increasingly important:

Maintaining consistent performance across a complex model-routing layer
Protecting public APIs without allowing abuse to consume model resources and increase costs

This is where traffic management becomes part of the scaling strategy.

Why AI Aggregators Become Harder to Scale

Scaling an AI aggregator introduces complexity on both the performance and security sides.

1. Performance Variability Across Providers and Regions

A user request doesn't necessarily travel to a single model in a single location. Depending on model selection, availability, pricing, or workload, traffic may pass through different providers, regions, and network paths.

Each additional network boundary introduces potential latency, congestion, and routing variability.

Adding more compute capacity doesn't necessarily solve this problem. If the request spends too much time crossing inefficient network paths, faster model infrastructure alone won't improve the user experience.

2. API Abuse and Security Exposure

The security surface grows at the same time.

Public AI APIs can be targeted by stolen credentials, automated scripts, scraping, credential stuffing, and other malicious traffic. For usage-based AI platforms, the impact goes beyond availability.

Every abusive request can consume model capacity and generate token costs.

A compromised API key can therefore become both a security problem and an infrastructure cost problem.

Solving the Performance Challenge

Performance problems in AI aggregators don't originate from model inference alone.

A unified API may route requests to different providers depending on the selected model and current availability. This makes network efficiency an important part of overall response performance.

1. Shorten the Request Path

Latency accumulates at every boundary a request crosses.

Public internet routes can expose traffic to congestion, inefficient routing, and jitter. Placing network entry points closer to users can reduce the distance before traffic enters the delivery infrastructure.

Edge PoPs can terminate requests closer to users and select routes based on current network conditions. For longer-distance transmission, private backbone connectivity can provide more predictable paths than the public internet.

The goal isn't simply to reduce network latency. For AI applications, it is also about improving time to first token and keeping response times consistent.

2. Keep Streaming Connections Stable

AI responses are often delivered incrementally rather than as a single payload.

A streaming response may remain open while tokens are generated and transmitted. If the connection becomes unstable halfway through the response, the user experience can degrade even when the underlying model is operating normally.

For this reason, AI traffic optimization needs to consider both:

How quickly the first token arrives
Whether the connection remains stable until the response is complete

3. Managing Traffic Spikes Before They Reach the Origin

Performance is only part of the scaling problem. AI traffic can also change dramatically in a short period of time.

A new model release or sudden increase in user activity can push request volumes from normal to extreme within minutes.

High concurrency puts direct pressure on origin infrastructure. Streaming responses make this harder because connections remain open for the duration of the response.

Instead of allowing every request to reach the origin directly, traffic can be absorbed and controlled before it reaches model-serving infrastructure.

A virtual waiting room, for example, can regulate inbound requests during extreme demand. Real-time monitoring and failover mechanisms can also help maintain service continuity when network conditions change.

The goal is not simply to add more capacity. It is to prevent unpredictable traffic from turning directly into origin overload.

Solving the API Security Challenge

AI API security has an additional dimension that traditional web applications don't always face: the cost of every successful request.

A stolen API key can generate thousands of requests before abnormal usage becomes visible. If those requests are distributed across multiple model providers, the financial impact can accumulate quickly.

This makes early enforcement particularly important.

1. Stop API Abuse Before It Consumes Model Resources

Useful controls include:

Behavioral analysis to identify abnormal request patterns that static rules may miss
API rate limiting to cap usage per credential
Access controls to restrict endpoint exposure
Bot management to identify automated abuse
Origin shielding to prevent direct attacks against backend infrastructure
DDoS mitigation to filter volumetric attacks before they reach the application

The basic principle is simple: stop unnecessary traffic before it consumes expensive model resources.

This is particularly important for AI aggregators because security controls can directly affect infrastructure costs. Preventing abusive requests before they reach model providers means protecting both the application and the model budget.

2. Address Bots and Direct-to-Origin Attacks

API abuse doesn't always look like a large-scale attack.

Modern bots can mimic legitimate activity, rotate identities, and distribute requests across large IP ranges. Static rules and IP-based filtering may therefore be insufficient on their own.

At the same time, exposed origin infrastructure creates another attack path. Attackers that discover the origin IP may bypass controls implemented at the application or edge layer.

This requires multiple layers of protection:

Behavioral bot detection for automated traffic
Origin shielding to reduce direct exposure
DDoS mitigation at the network edge

The objective is to keep legitimate API traffic available while filtering malicious traffic before it reaches backend infrastructure.

Combining Acceleration and API Security at the Edge

For a global AI aggregator, acceleration and API security can be handled together at the edge, where traffic can be optimized and filtered before reaching upstream AI services.

CDNetworks is one example of how this can be implemented. Its Dynamic Web Acceleration infrastructure includes 3,000+ Points of Presence (PoPs) across 90+ countries and more than 200 Tbps of network capacity, supported by Anycast, GSLB, and private backbone connectivity for traffic routing.

For API protection, CDNetworks provides capabilities including API rate limiting, bot management, DDoS mitigation, WAF, and origin shielding through Cloud Security 2.0 and Security Services.

In a reported deployment for a global multi-model AI platform, these capabilities helped reduce latency by more than 70% and lower origin bandwidth consumption by more than 66%. These results are specific to that deployment rather than a general performance guarantee.

For platforms serving users in Mainland China, CDNetworks also provides a China delivery capability with latency below 50ms, regulatory compliance, and no ICP filing requirement.

Final Thoughts

Scaling an AI aggregator isn't only about adding more models or compute. As traffic grows, network paths become more complex, streaming connections become more demanding, and public APIs become more attractive targets for abuse. At the same time, every unnecessary request can translate into additional model and infrastructure costs.

Performance and security therefore need to be considered together. Efficient routing can reduce latency and improve response consistency, while edge-based controls can prevent abusive traffic from consuming model resources.

For AI aggregators, scaling is ultimately about controlling the traffic path—from the first request to the final model response.

What Actually Happens When You Put a CDN in Front of Your Website?

Alvin — Wed, 12 Aug 2026 03:26:53 +0000

If you've worked on web performance for any amount of time, you've probably heard the advice:

“Put it behind a CDN.”

But what does a CDN actually do between the browser and your server?

The simplest way I think about it is this:

A CDN, or Content Delivery Network, is a distributed network of edge servers that delivers content from locations closer to users instead of sending every request back to one origin server.

That shorter path can reduce latency, speed up content delivery, reduce load on the origin, and make an application more resilient when traffic increases.

But the interesting part is what happens after a user hits your URL.

A request without a CDN

Imagine your application is hosted on an origin server in the United States.

A user in Singapore opens your website.

Without a CDN, requests for HTML, JavaScript, CSS, images, downloads, or other resources may have to travel all the way to your origin infrastructure and back.

Conceptually:

User in Singapore
       ↓
Internet
       ↓
Origin server in the US
       ↓
Internet
       ↓
User

That physical and network distance matters.

More distance generally means more network hops and more round trips, which can translate into additional latency.

Now put a CDN in between.

User
  ↓
Nearby CDN edge server
  ↓
Origin server (only when needed)

The CDN becomes a delivery layer between users and your origin.

So how does a CDN decide where requests go?

CDNs operate distributed edge servers across multiple geographic locations.

When a request comes in, technologies such as DNS-based routing, Anycast, and global traffic management can help direct that request toward an appropriate edge location.

Then the edge checks whether it can serve the content itself.

This is where caching becomes important.

Cache hit vs. cache miss

Two terms explain a large part of basic CDN behavior.

Cache hit

A cache hit means the requested resource is already stored on the edge server.

For example:

GET /images/product.png

If that image is already cached at a nearby edge location, the CDN can send it directly to the user.

The origin doesn't need to handle that request.

Cache miss

A cache miss means the requested content isn't currently available in that edge cache.

The CDN requests the resource from the origin, returns it to the user, and—depending on your cache rules—may store a copy for future requests.

So the flow becomes:

First request:
User → Edge → Origin → Edge → User

Later request:
User → Edge → User

This is one of the main reasons CDNs can reduce origin traffic as well as latency.

What controls how long something stays cached?

One important setting is TTL, or Time to Live.

TTL determines how long a cached resource can remain at the edge before it expires.

Assets that rarely change—such as logos, versioned JavaScript bundles, CSS, fonts, or software files—can often use longer cache durations.

Frequently changing resources may need shorter TTLs.

And if something needs to disappear from cache immediately, CDNs typically provide a cache purge mechanism.

This sounds simple, but cache policy can have a huge impact on CDN performance.

A CDN isn't just “cache everything forever.”

The real goal is deciding:

what can be cached;
where it should be cached;
how long it should stay cached;
and when it needs to be refreshed.

What about dynamic content?

This is where the idea that “CDNs are just caches” starts to break down.

Not everything can be cached.

API responses, authenticated pages, personalized content, shopping carts, and other dynamic requests may need to reach the origin.

A modern CDN can still help.

Even when a response isn't served from cache, CDN infrastructure can optimize the network path through techniques such as persistent connections, TCP/TLS optimization, dynamic acceleration, and newer protocols such as HTTP/2, HTTP/3, and QUIC.

So there are really two related ideas:

Caching reduces how often the origin is needed.

Network acceleration makes requests faster when the origin is needed.

Does a CDN replace web hosting?

No.

This is a distinction that sometimes gets lost.

Web hosting stores and runs your website or application. A CDN sits between users and that origin infrastructure to improve how content is delivered.

You still need an origin.

Think of it roughly like this:

	Web Hosting	CDN
Main job	Host the application/content	Deliver and accelerate content
Location	Origin infrastructure	Distributed edge locations
Handles	Original application and files	Cached and accelerated requests
Goal	Run the site	Get content to users efficiently

A CDN complements your hosting architecture rather than replacing it.

Do you actually need a CDN?

Not every side project needs an enterprise CDN setup.

But I'd start seriously considering one when:

users are distributed across multiple countries or regions;
performance varies significantly by geography;
your application serves lots of images, video, JavaScript, downloads, or other large assets;
your origin is handling a high volume of repeat requests;
traffic spikes are becoming difficult to manage;
availability and DDoS protection matter to the application.

The more geographically distributed your audience becomes, the more useful the edge model tends to become.

A CDN is also part of your reliability and security architecture

Performance gets most of the attention, but CDNs can do more than make pages load faster.

Because traffic passes through the CDN before reaching the origin, that network layer can also help with traffic distribution, origin protection, DDoS mitigation, web application security, and handling sudden spikes.

That makes the CDN an important infrastructure decision—not just a frontend optimization.

The short version

If I had to summarize CDN architecture in a few lines:

A CDN puts distributed edge infrastructure between users and your origin.

It can:

route users toward an appropriate edge location;
serve cached content without contacting the origin;
retrieve and cache content when there's a cache miss;
accelerate dynamic traffic that still needs the origin;
reduce origin load;
improve performance, scalability, reliability, and security.

Once you see the request flow, “use a CDN” stops feeling like a magic performance trick.

It's really a question of moving content and network processing closer to the people requesting it.

If you want a deeper breakdown of CDN caching, edge servers, common use cases, and how to evaluate a CDN provider, I found this more comprehensive guide useful:

What Is a CDN? — CDNetworks

Quick FAQ

What does CDN stand for?
CDN stands for Content Delivery Network.

What is a CDN in simple terms?
It's a distributed network of servers that helps deliver web content from locations closer to users.

Does a CDN host my website?
Not usually. Your hosting infrastructure remains the origin; the CDN works in front of it.

Can a CDN accelerate APIs?
Yes. Even when API responses aren't cached, CDNs can improve delivery through optimized routing and connection acceleration.

Is CDN caching the same as browser caching?
No. Browser caching stores content on an individual user's device, while CDN caching stores content at shared edge servers that can serve many users.

What 2025 Attack Traffic Means for Developers and Security Teams

Alvin — Thu, 06 Aug 2026 03:37:56 +0000

Security reports often lead with large numbers.

Billions of malicious requests. Terabit-scale DDoS attacks. Millions of automated bot requests every day.

The numbers matter, but the more useful question for developers is this:

What do these traffic patterns reveal about how applications are being attacked?

Based on traffic observed and mitigated by CDNetworks during 2025, one pattern stands out. Many attacks are designed to resemble legitimate activity.

They use standard protocols, expected application paths, authenticated sessions, and technically valid API requests. Detecting them requires more than matching signatures or blocking unusual IP addresses.

Here are four signals engineering and security teams should pay attention to.

1. DDoS Protection Must Cover More Than Bandwidth

CDNetworks blocked more than 227 million network-layer DDoS attack requests in 2025.

Among them:

329 attacks exceeded 1 Tbps
The largest attack reached 1.55 Tbps
Software and IT Services was the most targeted sector for network-layer DDoS attacks

Terabit-scale attacks are becoming a repeatable operational scenario.

However, network capacity represents only part of the problem.

Application-layer DDoS attacks can target expensive operations such as:

Login and authentication
Search
Checkout
Dynamic content generation
API requests
Database-intensive queries

A relatively small HTTP request can trigger several backend operations. Enough requests to a resource-intensive endpoint may degrade an application without saturating the network.

For engineering teams, DDoS testing should therefore examine application dependencies, worker pools, database capacity, caching behavior, and third-party services, alongside bandwidth.

2. Web Attacks Require End-to-End Request Visibility

CDNetworks blocked more than 21.51 billion web application attack requests during 2025.

Almost 60% occurred during the second half of the year, while HTTP protocol anomalies accounted for 45% of the total.

Modern application requests often travel through several components:

Client
  ↓
CDN or security edge
  ↓
Load balancer
  ↓
Reverse proxy or API gateway
  ↓
Application server
  ↓
Database and internal services

Each component may interpret malformed headers, encodings, request lengths, or protocol behavior differently.

This creates opportunities for attackers to test inconsistencies between systems.

Edge logs alone may not provide enough context. Teams should be able to connect a suspicious request with:

The targeted endpoint
Authentication status
Session history
Application response
Upstream latency
Backend errors
Related requests from the same identity or device

Consistent request IDs across the delivery path make this investigation significantly easier.

3. Bot Management Is a Policy Problem

In 2025, 74% of classified bot traffic came from bad bots.

CDNetworks also observed an average of 1.64 million AI bot requests per day, with data scrapers accounting for more than 72% of recorded AI bot activity.

The technical challenge is that automated traffic can serve very different purposes.

A bot may be:

A search crawler
A monitoring service
An AI agent
A commercial scraper
A credential-stuffing tool
An inventory-hoarding bot
An account-abuse system

Blocking all automation would disrupt legitimate services. Allowing all automation would expose applications, data, accounts, and infrastructure resources.

Bot policies should therefore reflect the purpose of each endpoint.

For example:

routes:
  /public-docs:
    verified-crawlers: allow
    unknown-bots: rate-limit

  /account:
    crawlers: block
    suspicious-automation: challenge

  /api/inventory:
    authentication: required
    behavioral-monitoring: enabled

The exact syntax depends on the security platform, but the underlying principle remains the same. Public content, account systems, APIs, and transactional workflows should not share one universal bot policy.

4. API Abuse Can Look Technically Valid

CDNetworks blocked an average of more than 15 billion malicious API requests per month during 2025.

API attacks can be difficult to identify because individual requests may appear legitimate.

A malicious request may:

Use valid JSON
Match the expected schema
Include a valid token
Target a documented endpoint
Stay below an IP rate limit
Receive a successful response

The risk appears when the request is connected to behavior over time.

Consider an authenticated user querying an inventory API. One request may be expected. Thousands of queries distributed across several accounts, devices, and IP addresses may indicate scraping or automated purchasing activity.

Traditional IP-based rate limiting may miss this pattern.

Sensitive APIs should also evaluate:

account_id
api_key
session_id
device_id
organization_id
endpoint
resource_id
action_frequency
historical_behavior

Security controls need to measure both request volume and business impact.

Examples include the number of accounts created, coupons redeemed, items reserved, records accessed, or payment methods tested.

The Shared Engineering Challenge

DDoS attacks, web attacks, bots, and API abuse affect different parts of the technology stack, but they reveal the same challenge:

Attack traffic often uses legitimate-looking behavior.

This makes context essential.

Security teams need infrastructure data, while developers understand application workflows. Platform teams understand dependencies, while identity teams understand users, sessions, and permissions.

These signals become more valuable when they are connected.

What Teams Should Review

Based on the 2025 traffic patterns, engineering and security teams should review five areas:

Expensive endpoints
Identify requests that consume substantial compute, database, or third-party resources.
Cross-layer observability
Connect edge, application, API, identity, and backend telemetry.
Identity-aware limits
Apply controls across accounts, tokens, sessions, devices, and organizations, rather than relying solely on IP addresses.
Endpoint-specific bot policies
Define which automated agents can access each application workflow.
Long-term behavioral analysis
Look for attack activity developing over days or weeks, as well as sudden traffic spikes.

Final Thought

Blocking malicious requests remains necessary, but request-level inspection alone cannot explain every attack.

Developers and security teams also need to understand who is performing an action, how the behavior changes over time, which resources are affected, and whether the outcome aligns with expected business use.

That context is becoming a core part of application resilience.

The figures in this article are drawn from the 2025 CDNetworks State of Web Application and API Protection Report and reflect traffic observed and mitigated by the CDNetworks security platform during 2025.

Best CDN for Live Streaming in 2026: A Developer’s Guide to Choosing the Right Provider

Alvin — Fri, 31 Jul 2026 02:33:03 +0000

TL;DR

A live streaming CDN improves video delivery by serving content from edge servers closer to viewers.
The best CDN depends on your audience location, latency requirements, streaming protocols, and operational needs.
CDNetworks is a strong choice for global live streaming, especially when Asia-Pacific performance and ultra-low latency matter.
Akamai excels at large-scale enterprise broadcasting with a mature global network.
Cloudflare, Fastly, and AWS each offer advantages for specific deployment models and development workflows.

What you'll learn

What a live streaming CDN does and why it matters
How a CDN improves streaming performance
How I evaluated the top CDN providers
A side-by-side comparison of five leading live streaming CDNs
A practical framework for choosing the right CDN for your streaming platform

What is a live streaming CDN?

A live streaming CDN (Content Delivery Network) is a distributed network of edge servers that delivers live video from locations closer to viewers instead of relying on a single origin server.

Instead of sending every request back to the origin, the CDN replicates and distributes the live stream across multiple edge locations. Viewers connect to the nearest edge server, reducing network distance and improving playback quality.

Live streaming CDNs are commonly used for:

Sports broadcasts
OTT streaming platforms
Live commerce
Online education
Enterprise events
Gaming and esports

Why Live Streaming Needs a CDN

A live streaming CDN improves video delivery by distributing content through geographically distributed edge servers instead of forcing every viewer to connect directly to a centralized origin server.

When thousands or even millions of viewers join a live event, sending every request to a single origin server can quickly become a bottleneck. A CDN solves this problem by spreading traffic across multiple edge locations (also known as Points of Presence or PoPs), allowing viewers to receive video content from a server closer to their location.

                     Broadcaster
                         |
                         |
                    Origin Server
                         |
                         |
                 CDN Edge Network
                         |
        ┌────────────────┼────────────────┐
      US PoP           EU PoP          Asia PoP
        |                |                |
     Viewer A         Viewer B         Viewer C

This distributed architecture helps reduce delivery latency, minimize buffering, improve stream reliability, and support large-scale audiences across different regions.

Common use cases

Live streaming CDNs are widely used for scenarios that require high-quality video delivery, global reach, and the ability to handle sudden spikes in audience traffic.

Sports and esports broadcasting
OTT and media streaming platforms
Live commerce
Virtual classrooms
Enterprise live events
Gaming livestreams

How I evaluated the best live streaming CDNs

No CDN is the best choice for every streaming platform.

Instead of focusing on marketing claims, I evaluated providers using the technical characteristics that have the greatest impact on production live streaming.

The evaluation focused on six areas.

Evaluation Criteria	Why It Matters
Global edge network	Reduces latency by serving viewers from nearby locations
Live streaming performance	Improves playback quality, startup time, and latency
Scalability	Handles sudden traffic spikes during live events
Origin offload	Reduces origin bandwidth costs and improves reliability
Security & availability	Protects against DDoS attacks and service disruptions
Integration	Simplifies deployment with modern streaming protocols and APIs

I also considered compatibility with common streaming technologies, including:

RTMP
FLV
HLS
DASH
WebRTC
SRT
CMAF
QUIC

5 best CDN providers for live streaming

Many CDN providers support live video delivery, but only a handful consistently provide the combination of low latency, scalability, and operational reliability required for production streaming.

Here's how the 5 leading CDN providers compare.

Quick recommendations

Choose the provider that best matches your priorities.

CDNetworks — Best for global streaming with strong Asia-Pacific performance and ultra-low latency.
Akamai — Best for enterprise broadcasters operating at global scale.
Cloudflare — Best for developer-focused streaming platforms.
Fastly — Best for programmable edge delivery and low-latency HTTP streaming.
AWS — Best for teams already building on AWS services.

Comparison of best CDN for live streaming

Provider	Global Coverage	Best For	Streaming Protocols	Indicative Latency*	Security	Scalability
CDNetworks	3,000+ PoPs in 90+ countries	OTT, gaming, media, live commerce	RTMP, FLV, HLS, DASH, SRT, CMAF, WebRTC, QUIC	<500 ms (WebRTC)	DDoS, WAF, Bot Management, API Security	200+ Tbps
Akamai	Extensive global network	Enterprise media delivery	HLS, DASH, CMAF	2–5 s	DDoS, WAF, API Security, Zero Trust	Enterprise scale
Cloudflare	Large global edge network	Interactive streaming and developer platforms	HLS, LL-HLS, WebRTC	<1 s (WebRTC Beta)	DDoS, WAF, Zero Trust	Highly scalable
Fastly	Global edge network	Real-time streaming	HLS, DASH, CMAF	2–4 s	DDoS, WAF	High-performance edge
AWS	AWS global infrastructure	AWS-native streaming	HLS, DASH, CMAF	3–6 s	AWS Shield, AWS WAF	Elastic AWS scaling

Latency figures are indicative and depend on protocol selection, encoder settings, player buffering, network conditions, and overall streaming architecture. WebRTC deployments typically achieve sub-second latency, while LL-HLS workflows generally operate in the multi-second range.

Why choose CDNetworks for live streaming?

CDNetworks is a strong option for organizations that need reliable global delivery while maintaining excellent performance in Asia-Pacific.

Its combination of network coverage, protocol support, media services, and integrated security makes it suitable for:

OTT platforms
Live commerce
Sports broadcasting
Gaming
Online education
Enterprise streaming

Pros

3,000+ PoPs across 90+ countries
200+ Tbps network capacity
Strong Asia-Pacific and Mainland China optimization
Supports RTMP, FLV, HLS, DASH, SRT, CMAF, WebRTC, and QUIC
WebRTC streaming with glass-to-glass latency below 500 ms
Flexible ingest and Player SDKs
4K-ready cloud transcoding
Live recording and real-time screenshot services
Built-in DDoS protection, WAF, and access control

Considerations

Advanced media capabilities are primarily designed for enterprise deployments.
Smaller streaming projects may not need the full breadth of the platform.

Why choose Akamai for enterprise streaming?

Akamai is best suited for organizations running large-scale broadcasts where reliability is more important than minimizing operational complexity.

Pros

Extensive global edge infrastructure
Supports HLS, DASH, CMAF, and Low-Latency HLS
Mature enterprise security stack
Proven performance during high-profile live events

Considerations

Premium pricing
More operational overhead than lightweight CDN platforms

Why choose Cloudflare for developer-focused streaming?

Cloudflare combines CDN delivery, networking, and security into a unified platform, making it attractive for engineering teams building modern applications.

Pros

Large global network
Supports HLS, LL-HLS, and WebRTC
Built-in DDoS protection, WAF, bot management, and Zero Trust
Developer-friendly APIs

Considerations

Video delivery is not as specialized as providers focused primarily on streaming.
Some advanced streaming capabilities require additional Cloudflare services.

Why choose Fastly for low-latency HTTP streaming?

Fastly focuses on real-time content delivery with a programmable edge platform.

If your application requires fast cache updates and customizable request handling, Fastly is worth considering.

Pros

Low-latency delivery
Supports HLS, DASH, and CMAF
Programmable edge platform
Fast cache invalidation

Considerations

Smaller network footprint than some competitors
Edge programming features are most valuable for teams with in-house engineering expertise

Why choose AWS for AWS-native streaming?

AWS is a natural fit for organizations already running their infrastructure on AWS.

It integrates closely with Amazon S3, AWS Elemental Media Services, AWS Shield, and AWS WAF.

Pros

Global AWS infrastructure
Supports HLS, DASH, and CMAF
Tight integration with AWS media services
Elastic scaling

Considerations

Building a complete streaming workflow usually involves multiple AWS services.
Pricing and architecture can become complex at scale.

How do you choose the right live streaming CDN?

The right CDN depends on your workload rather than the longest feature list.

Here's the evaluation process I'd recommend.

1. Define your latency requirements

Start by identifying your application.

Interactive applications such as gaming, live commerce, auctions, and video calls typically require sub-second latency, making WebRTC a strong candidate.

Traditional OTT streaming usually prioritizes scalability and playback quality over the lowest possible latency.

2. Know where your viewers are

Audience location directly affects CDN performance.

If most viewers are concentrated in a particular region, prioritize providers with strong regional coverage.

For global audiences, choose a provider with broad geographic reach.

For Asia-Pacific users, evaluate regional routing performance in addition to overall network size.

3. Verify protocol compatibility

Your CDN should support the protocols used throughout your streaming workflow.

Common protocols include:

HLS
DASH
RTMP
WebRTC
LL-HLS
CMAF
SRT

Protocol compatibility can simplify deployment while improving playback across different devices.

4. Consider long-term operations

Streaming reliability depends on more than video delivery.

Evaluate additional capabilities such as:

DDoS protection
WAF
Analytics
Monitoring
APIs
Technical support
Media workflow services

These features become increasingly important as audience size grows.

5. Validate with production-like traffic

Specifications are useful, but real-world testing is more valuable.

Before committing to a provider, benchmark performance using traffic that resembles your production workload.

Measure metrics such as:

Startup time
Time to First Byte (TTFB)
End-to-end latency
Rebuffering rate
Playback stability
Regional performance

Real traffic often reveals differences that product documentation cannot.

What Is RTMP? Understanding RTMP Streaming and Live Ingest

Alvin — Thu, 30 Jul 2026 03:29:45 +0000

Live streaming looks simple from the viewer side: click play and watch.

Behind that experience is a complex pipeline involving encoding, media transport, processing, packaging, and delivery. Among the many protocols involved, RTMP (Real-Time Messaging Protocol) remains one of the most widely supported technologies for live streaming ingest.

Although RTMP is no longer used for browser playback, it continues to play an important role in connecting encoders with streaming platforms.

What Is RTMP?

RTMP is an application-layer protocol designed to transmit audio, video, metadata, and control messages between connected systems.

Originally associated with Adobe Flash streaming, RTMP was historically used for both media transport and playback. However, after Adobe ended Flash Player support on December 31, 2020, modern browsers stopped supporting native RTMP playback.

Today, RTMP is mainly used for live ingest.

A typical streaming workflow looks like this:
Camera or video source → Encoder → RTMP or RTMPS ingest → Media server → Transcoding and packaging → CDN → Viewer

In this architecture, RTMP handles the contribution side of streaming, while protocols such as HLS, DASH, or WebRTC are commonly used for viewer delivery.

This separation explains why RTMP remains relevant in modern streaming systems.

How RTMP Streaming Works

RTMP streaming starts when an encoder establishes a connection with a media server and continuously sends encoded media data.

1. Capture and Encode the Source

The process begins with a video source such as cameras, screen capture systems, gaming devices, and broadcast production systems

The encoder compresses raw audio and video into a stream suitable for transmission.

Important encoding parameters include:

Video codec
Audio codec
Resolution
Frame rate
Bitrate
Keyframe interval

Incorrect encoder settings can cause unstable ingest, processing failures, or playback problems.

2. Establish an RTMP Connection

The encoder connects to an RTMP or RTMPS endpoint provided by the streaming platform.

The workflow typically includes:

RTMP handshake
Connection request
Stream creation
Publishing the live feed

RTMP uses commands such as connect, createStream, and publish to establish and manage the streaming session.

3. Transfer Media Through Messages and Chunks

RTMP transports different types of information through the same connection:

Video data
Audio data
Metadata
Timing information
Control messages

Large messages can be divided into smaller chunks, allowing different data types to be transmitted efficiently over a persistent connection.This design is one reason RTMP became widely adopted in broadcast workflows.

4. Process and Deliver the Stream

After receiving the RTMP stream, the media platform can:

Authenticate the publisher
Transcode into multiple qualities
Generate adaptive bitrate streams
Package content into HLS, DASH, or WebRTC
Apply access controls
Deliver content through a CDN

RTMP handles the upstream contribution workflow, while other technologies handle scalable delivery.

What Is RTMP Ingest?

RTMP ingest is the process of sending a live stream from an encoder to a media platform.

It is the connection point between content production and streaming infrastructure. A typical RTMP ingest workflow:
Encoder → RTMP Ingest Server → Media Processing → Streaming Distribution

RTMP ingest remains popular because of its broad compatibility with:

OBS and other software encoders
Hardware encoders
Broadcast systems
Enterprise streaming platforms

For many organizations, replacing existing RTMP workflows would require significant changes to production infrastructure.

RTMPS: Secure RTMP Streaming

RTMPS is RTMP transmitted over a TLS-encrypted connection.

Unlike standard RTMP, RTMPS protects data while it travels between the encoder and ingest server.

For production environments, RTMPS is generally preferred when supported.

However, transport encryption is only one part of streaming security. A complete security strategy should also include:

Stream key protection
Publisher authentication
Viewer authorization
Digital rights management
Access-control policies

RTMPS improves connection security but does not replace broader content protection strategies.

RTMP vs HLS vs SRT vs WebRTC

Different streaming protocols solve different problems.

Protocol	Primary Role	Typical Connection	Main Strength	Main Consideration
RTMP or RTMPS	Live ingest	Encoder to media server	Broad publishing compatibility	Plain RTMP is unencrypted
HLS	Viewer playback and distribution	Server to player	HTTP-based delivery at scale	Segmenting and buffering affect latency
SRT	Contribution and transport	Source to media infrastructure	Recovery across unpredictable networks	Both endpoints must support SRT
RTSP	Session setup and control	Client and media server	Controls media sessions	Commonly works with separate transport mechanisms
WebRTC	Interactive real-time communication	Browser, application, or peer communication	Real-time browser and application interaction	Scaling and architecture can be more complex

A common modern architecture is:
RTMP → Media Processing → HLS → Viewer

RTMP provides compatibility at ingest, while HLS provides scalable playback.

For interactive applications such as video conferencing or real-time collaboration, WebRTC may be a better choice.

Advantages and Limitations of RTMP

Advantages of RTMP

Mature Ecosystem
RTMP is supported by many existing encoders, production tools, and streaming platforms.

Simple Ingest Workflow
Many organizations already have established RTMP publishing workflows, monitoring systems, and operational processes.

Flexible Media Processing
Platforms can receive RTMP streams and convert them into multiple delivery formats.

Limitations of RTMP

No Encryption Without RTMPS
Standard RTMP does not encrypt traffic.

Not Suitable for Browser Playback
Modern browsers generally require protocols such as HLS, DASH, or WebRTC.

Latency Depends on the Entire Pipeline
RTMP itself does not determine final viewer latency.

Latency depends on:

Encoding configuration
Network conditions
Transcoding
Packaging
CDN delivery
Player buffering

How to Improve RTMP Streaming Reliability

Reliable RTMP streaming depends on the entire workflow, not only the protocol itself.

Key practices include:

Choose a suitable ingest endpoint: Evaluate network stability, routing quality, packet loss, and available upload capacity before production streaming.
Follow encoding requirements: Match the platform’s supported codec settings, bitrate, resolution, frame rate, and keyframe interval to avoid ingest instability.
Use RTMPS when available: Encrypted ingest helps protect media data and connection information during transmission.
Protect publishing credentials: Stream keys should be treated as sensitive credentials. Avoid public exposure, unnecessary sharing, and unused long-lived keys.
Prepare redundancy for critical events: Important broadcasts should consider backup encoders, network connections, power sources, or ingest endpoints.
Monitor the complete delivery pipeline: A successful encoder connection does not guarantee a good viewer experience. Monitor ingest health, processing status, CDN delivery, and playback quality.

How CDNetworks Supports RTMP Ingest and Live Streaming

RTMP remains a widely used ingest protocol because it integrates with established encoders and live streaming workflows.

CDNetworks Media Delivery services support RTMP ingest workflows by connecting RTMP-based publishing with distributed media delivery.

CDNetworks’ Enhanced RTMP/FLV support is designed to:

Maintain compatibility with popular streaming software such as OBS and VLC.
Support a broader range of media formats.
Reduce the need for additional protocol replacement or adaptation.
Support low-latency streaming experiences.
Help providers balance audience experience with streaming costs.

These capabilities allow organizations to continue using existing RTMP workflows while integrating with modern media delivery infrastructure.

Final Thoughts

RTMP is not the newest streaming protocol, but it remains an important part of modern live streaming workflows because of its compatibility and ecosystem maturity.

Modern streaming architectures are not built around one protocol. RTMP, HLS, SRT, and WebRTC each solve different problems across ingest, delivery, contribution, and interaction.

Understanding where RTMP fits is still essential for building reliable and scalable streaming systems.

Cybersecurity in 2026: The Trends Reshaping Modern Applications

Alvin — Fri, 24 Jul 2026 07:13:26 +0000

Cybersecurity in 2026 feels different.

It’s not simply because attacks are becoming more sophisticated or more frequent. What’s changing is where security problems begin. They’re no longer confined to isolated vulnerabilities or network boundaries—they’re increasingly emerging from the applications we build, the APIs we expose, the identities we manage, and the automated systems we rely on every day.

Modern applications have become highly distributed. AI is accelerating development cycles, APIs are powering nearly every digital experience, and machine identities are beginning to outnumber human users. At the same time, attackers are becoming faster, more automated, and increasingly capable of blending malicious behaviors into legitimate traffic patterns.

According to Statista, cybercrime cost businesses approximately $10.5 trillion in 2025 and is projected to reach $15.63 trillion by 2029. Ignoring these changes is becoming significantly more expensive than preparing for them.

Looking ahead to 2026, five cybersecurity trends stand out—not because they’re entirely new, but because they’re fundamentally changing how modern applications need to think about security.

AI Is Industrializing Cyberattacks

AI has become one of the most significant accelerators of cyberattacks. What makes AI particularly interesting isn’t simply its ability to automate existing attack techniques—it’s dramatically changing attacker economics by reducing both the cost and expertise required to launch sophisticated campaigns at scale.

The numbers are beginning to reflect this shift:

FBI IC3 recorded more than 22,000 AI-related complaints and over $893 million in adjusted losses during 2025.
The World Economic Forum reported that 87% of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk throughout 2025.
Deepfakes contributed to nearly 10% of cyberattacks during 2024, with fraud losses ranging from $250,000 to $20 million per incident.

Technical Insight

We’re moving beyond scripted automation into adaptive attack operations. Large language models, agentic AI systems, browser automation frameworks, and proxy networks are enabling attackers to generate increasingly convincing phishing campaigns, automate vulnerability discovery, and launch context-aware social engineering attacks at unprecedented scale.

What’s changing isn’t simply attack volume—it’s attack velocity. AI is significantly shortening the time between discovering vulnerabilities and exploiting them while lowering the technical barriers required to execute sophisticated attacks.

Security Implications

Modern applications will increasingly need to prioritize:

Behavioral-based threat detection over static rule matching.
AI-assisted anomaly analysis and automated response capabilities.
Continuous authentication mechanisms across user and machine identities.
Adaptive security models capable of responding to evolving attack behaviors.

The question is no longer whether attackers will leverage AI—it’s how quickly defenders can adapt to AI-driven threats.

API Security Is Becoming Application Security

Modern applications are increasingly API-first, which also means they’re increasingly API-dependent.

Rapid AI adoption, microservices architectures, and multi-cloud deployments are continuously expanding the application attack surface. APIs that once existed only between internal services are increasingly exposed across partners, platforms, and AI integrations.

According to CybersecAsia, the speed of AI deployment is already exceeding the pace of API security adoption, creating growing concerns around shadow and unmanaged APIs.

According to API security observations published by CDNetworks throughout 2025, authentication bypass accounted for 18.8% of observed API attacks, while privilege escalation represented 12.5% of attack patterns. Low-frequency API attacks persisted for an average of 21.7 days, highlighting how difficult these attacks can be to detect using traditional security controls.

Technical Insight

What’s changing about API attacks is their behavior. Attackers aren’t necessarily generating massive traffic spikes or exploiting well-known vulnerabilities. Increasingly, they’re targeting authorization logic, session management mechanisms, and business workflows themselves.

Low-frequency attacks are particularly challenging because they often resemble legitimate user behaviors, allowing them to remain undetected for extended periods of time.

This is one of the reasons Web Application and API Protection (WAAP) is becoming increasingly strategic in 2026. Traditional WAF capabilities alone are no longer sufficient for protecting modern applications that depend heavily on APIs, automation, and distributed services.

Security Implications

API security is gradually becoming application security. Building secure applications increasingly means understanding:

Who is accessing an API.
Why they’re accessing it.
Whether their behavior aligns with expected business logic.
How APIs interact across distributed services and machine identities.

Continuous API discovery, behavioral baselining, and context-aware authorization will become increasingly important as API ecosystems continue expanding.

Availability Has Become an Architectural Concern

We often discuss cybersecurity through the lens of confidentiality and data protection. Increasingly, however, availability deserves equal attention.

Modern DDoS attacks aren’t necessarily becoming larger—they’re becoming more persistent.

According to technical traffic observations published by CDNetworks, more than 227.37 million network-layer DDoS attack requests were mitigated throughout 2025, with attack volumes remaining elevated for much of the year. CDNetworks also reported that 86% of terabit-scale DDoS incidents observed during 2024 lasted longer than ten minutes, highlighting the growing prevalence of sustained, high-capacity attacks.

Application-layer attacks continue presenting significant challenges as well. During 2025, 67.45% of Layer 7 DDoS attacks observed by CDNetworks were concentrated within the APAC region, reinforcing the importance of regional traffic visibility and application-layer protections.

At the same time, CDNetworks observed that 74% of bot traffic throughout 2025 originated from malicious bots, underscoring the growing need for adaptive bot management capabilities.

Technical Insight

What’s interesting here isn’t simply attack volume—it’s what the data suggests about attacker behavior. We’re increasingly seeing attackers optimize for sustained resource exhaustion rather than short-lived traffic bursts.

Modern attacks frequently combine automated bot traffic, application-layer abuse, and prolonged attack durations to maximize operational impact. Availability challenges are gradually moving beyond networking concerns and becoming application-level challenges.

Why This Matters

Building resilient applications in 2026 increasingly means assuming malicious traffic will coexist alongside legitimate users from day one.
Engineering teams should increasingly consider:
Multi-layer DDoS mitigation strategies.
Regional traffic visibility across globally distributed infrastructures.
Adaptive bot management capabilities.
Edge-based traffic filtering mechanisms.
Application-layer protections designed for modern workloads.

Availability is becoming an architectural concern rather than simply an operational one.

Content Is Becoming a Security Asset

AI crawlers represent one of the more interesting developments emerging across modern applications.

Unlike traditional malicious bots, AI crawlers exist within a much larger gray area. Some provide legitimate value through indexing and retrieval capabilities, while others create significant concerns around content ownership, licensing, attribution, and proprietary data reuse.

According to traffic intelligence published by CDNetworks throughout 2025, AI bot activity accounted for approximately 0.42% of total observed internet traffic, translating to roughly 1.64 million requests per day.
More significantly, 72.67% of observed AI bot activity was associated with content retrieval and data scraping operations.

CDNetworks also observed that OTT platforms accounted for 24% of application-layer DDoS attacks during 2025, followed by Broadcasting and Television at 23% and News and Publishing at 9%. Additionally, CDNetworks helped a licensed video and music content platform mitigate more than 10 million malicious crawler requests per day throughout 2025, highlighting how AI-driven scraping activities can directly affect copyrighted media assets.

Technical Insight

Applications can no longer assume that every visitor is either a human user or a malicious bot. Increasingly, they’ll need to distinguish between search crawlers, AI assistants, retrieval systems, legitimate automation, and malicious scraping activities.

The engineering challenge is no longer simply blocking malicious traffic—it’s making intelligent decisions about automated access.

Security Implications

Content protection is gradually becoming part of modern application security strategies.

Engineering teams should increasingly evaluate:

Bot identity and access intent.
Content sensitivity and business impact.
Usage patterns across automated traffic.
Granular access policies for AI crawlers and legitimate automation.

Modern applications will need to move beyond simple allow-or-block policies toward more intelligent approaches to automated access governance.

Identity Is Replacing the Traditional Perimeter

Perhaps the most significant shift happening across cybersecurity is the growing importance of identity security.

Traditional network perimeters are becoming increasingly difficult to define. Modern applications operate across cloud environments, remote workforces, APIs, and machine identities that extend far beyond conventional boundaries.

Identity is gradually replacing the perimeter itself.

According to Verizon’s 2025 findings, credential abuse accounted for approximately 22% of initial access vectors throughout the year. Meanwhile, APWG recorded 971,181 phishing attacks during Q1 2026, representing a 13.8% increase compared with Q4 2025, while the number of known Phishing-as-a-Service kits doubled throughout 2025.

Google has also highlighted the growing adoption of advanced MFA bypass techniques and increasingly sophisticated social engineering attacks, while deepfake technologies continue challenging traditional assumptions around identity verification.

Technical Insight

Attackers are no longer attempting only to compromise systems—they’re increasingly attempting to impersonate trust itself.

The implications extend far beyond user authentication. Machine identities are expanding rapidly across modern infrastructures, while compromised credentials can trigger automated actions across distributed environments with minimal friction.

Zero Trust Network Access (ZTNA) adoption is accelerating partly because of these changes. As legacy VPN technologies continue reaching end-of-life, organizations are increasingly shifting toward identity-aware access models that provide users with access only to the resources they require while limiting opportunities for lateral movement.

Security Implications

Identity protection in 2026 is becoming less about protecting credentials and more about continuously validating trust.

Modern security architectures should increasingly prioritize:

Zero Trust principles.
Adaptive authentication mechanisms.
Identity threat detection capabilities.
Machine identity governance.
Risk-based access controls across distributed environments.

Identity is becoming as strategic as cloud and network security in modern application architectures.

What Modern Applications Are Teaching Us

Looking across industries, several patterns are beginning to emerge.

E-commerce and retail platforms accounted for 24% of observed bot attacks during 2025, according to CDNetworks’ technical observations. API attacks represented 32% of attacks targeting the industry during 2024, while approximately 22% of major DDoS incidents in late 2025 targeted online retail infrastructures.
Gaming platforms remain particularly vulnerable to availability-related attacks. CDNetworks reported that gaming services experienced 57.38% of observed Layer 3 and Layer 4 attacks alongside 31.32% of Layer 7 attacks during 2024.
Healthcare organizations continue facing substantial ransomware risks, with approximately 40% anticipated to experience attacks during 2026. The average cost of healthcare data breaches is projected to reach $12.6 million.
Financial services remain heavily targeted by both API abuse and identity-related threats. According to CDNetworks, financial services accounted for 23.8% of observed API attacks throughout 2025, while Statista projects average breach costs within the sector will exceed $6.08 million during 2026. Deepfake attacks are accelerating as well, with Axios reporting that 55% of financial organizations experienced incidents during 2025, compared with 43% across other industries.

Although these industries face different challenges, they’re ultimately reinforcing similar lessons—security is moving closer to application architecture itself.

Final Thoughts

Cybersecurity in 2026 isn’t simply about defending against the next vulnerability.

Modern applications are changing faster than traditional security assumptions can keep pace. AI is reshaping attacker capabilities. APIs are continuously expanding application boundaries. Identity is replacing traditional perimeters, while availability and content protection are becoming architectural concerns rather than operational ones.

Perhaps the biggest change isn’t happening within cybersecurity itself—it’s happening within the applications we’re building.

Security is gradually moving closer to product architecture.

Building secure applications in 2026 increasingly means assuming that automation, malicious traffic, machine identities, and adaptive threats are part of the environment from day one. The question is no longer whether modern applications will face these challenges, but whether they’re designed to continuously adapt when they do.

5 Cybersecurity Trends Developers and Tech Leaders Should Watch in 2026

Alvin — Thu, 16 Jul 2026 09:57:40 +0000

Web applications and APIs sit at the center of modern digital services. They handle authentication, payments, search, content delivery, account management, and many of the workflows that developers build and maintain every day.

That also makes them persistent targets.

Each year, CDNetworks analyzes activity observed across our security platform to understand how threats involving web applications, APIs, bots, and digital services are changing.

This article translates five findings from the CDNetworks 2025 State of WAAP Report into practical considerations for developers, application security teams, platform engineers, and SREs.

Methodology note: The figures in this article reflect activity observed across the CDNetworks security platform during 2025. They describe activity within the scope of that platform telemetry and should not be interpreted as measurements of all global internet traffic.

TL;DR

AI is industrializing automated attacks. AI-assisted tools are making attack campaigns more adaptive, scalable, and accessible.
API abuse is becoming a primary path for business logic attacks. Technically valid requests can still produce malicious business outcomes.
AI bot traffic is creating a new governance challenge. Teams need granular policies based on bot identity, purpose, access frequency, and content sensitivity.
Multi-layer DDoS attacks are raising the bar for resilience. Campaigns can shift across network, transport, and application layers within the same attack.
APAC is facing concentrated application-layer attack pressure. APAC businesses are under greater pressure from attacks targeting their business-critical digital services.

Let’s take a closer look at each trend.

1. AI is industrializing automated attacks.

Our latest research shows that AI is changing the economics of cyberattacks.

Large language models, agentic AI tools, browser automation frameworks, and proxy networks are reducing the cost, time, and expertise required to run sophisticated campaigns.

As a result, automated threats are moving beyond rigid scripts toward more adaptive, context-aware, and human-like attack patterns.

This makes AI-driven automation a persistent and expanding threat to digital businesses.

2. API abuse is becoming a primary path for business logic attacks.

APIs have become a primary route to business impact.

In 2025, the CDNetworks security platform blocked more than 15 billion malicious API requests per month on average.

Many attackers are now abusing legitimate functions such as login, registration, search, ordering, and payments, often through valid identities, sessions, and normal request paths.

Because the activity can appear technically valid, business logic attacks are especially difficult to distinguish from genuine customer behavior.

3. AI bot traffic is creating a new governance challenge.

AI bots are automated agents that crawl, retrieve, summarize, or act on online content for AI systems.

In 2025, the CDNetworks security platform observed approximately 1.64 million AI bot requests per day on average.

Data scraping accounted for 72.67% of the observed AI bot activity.

This volume shows that AI bots have become a meaningful part of enterprise internet traffic.

But not all AI bots are harmful. Some support AI search, user-requested retrieval, or model improvement.

Because similar technical behavior can serve very different purposes, simple allow-or-block decisions are often insufficient. Businesses need more granular governance based on bot identity, intent, context, access frequency, content sensitivity, and potential business impact.

4. Multi-layer DDoS attacks are raising the bar for resilience.

Our research shows that DDoS campaigns are becoming more dynamic, with attackers shifting between Layers 3, 4, and 7 within the same campaign and adapting tactics in real time.

A customer case from 2025 illustrates how this trend can play out in practice.

The organization experienced a sustained, multi-day attack that targeted both its network and application layers.

The campaign peaked at:

1.4 Tbps across Layers 3 and 4
770,000 requests per second at Layer 7

CDNetworks mitigated the attack without business disruption.

For business leaders, the implication is clear.

DDoS risk now includes prolonged, multi-layered campaigns that can change tactics over time and pressure several parts of the digital environment at once.

Maintaining availability under these conditions requires adaptive protection and expert mitigation across both network and application layers.

5. APAC is facing concentrated application-layer attack pressure.

APAC accounted for 67.45% of the Layer 7 DDoS activity observed on the CDNetworks security platform in 2025.

The region’s e-commerce, fintech, gaming, SaaS, mobile, entertainment, and digital content sectors depend on high-frequency paths such as login, search, checkout, verification, payments, content access, and API calls.

Those revenue-critical workflows also make APAC businesses attractive targets for disruption, fraud, and abuse.

What Teams Should Prioritize in 2026

Taken together, these trends show how attackers are combining legitimate identities, valid API traffic, automated tools, and business-critical workflows to create operational and security risks.

For development, security, and platform teams, seven priorities stand out:

Protect revenue-critical API workflows, including login, checkout, payments, verification, and account recovery.
Strengthen business continuity and API resilience in APAC markets, where application-layer attack pressure is particularly concentrated.
Prepare for sudden spikes in automated traffic before they affect application availability, backend services, and downstream dependencies.
Reduce exposure from compromised trusted identities, including valid accounts, sessions, API keys, and service credentials.
Control the operational costs of AI-driven attacks, especially when automated requests trigger expensive application or infrastructure processes.
Govern AI bot interactions based on business impact, considering bot identity, purpose, access frequency, and content sensitivity.
Safeguard AI-enabled applications and agentic workflows with scoped permissions, controlled tool access, and stronger oversight of high-impact actions.

These priorities share a common goal: protecting critical digital services without creating unnecessary friction for legitimate users.

Final Thoughts

The emerging security challenge is not limited to blocking requests that look obviously malicious. Teams also need to identify legitimate functionality being used with malicious intent.

The CDNetworks 2025 State of WAAP Report provides the supporting research and additional analysis behind these trends.

👉 Read the full Report

If your team is assessing these risks and needs support from a specialist security provider, visit our website to learn how we help protect web applications, APIs, and digital services.

Disclosure: This article is based on security research and platform data from CDNetworks.