What Is an HTTP Flood Attack?

An HTTP flood is a type of distributed denial-of-service (DDoS) attack that overwhelms a website, application, or API with large numbers of HTTP requests. Because these requests can resemble legitimate user traffic, HTTP floods can be difficult to identify and block without also disrupting real users.

Unlike network-layer attacks that consume bandwidth, HTTP floods target the application layer. Their goal is to exhaust the servers, databases, APIs, or other resources responsible for processing web requests.

What is an HTTP flood?

An HTTP flood is an application-layer, or Layer 7, DDoS attack in which an attacker sends excessive HTTP GET, POST, or other web requests to a target.

Each request asks the application to perform work, like loading a page, querying a database, authenticating a user, processing a search, or adding an item to a shopping cart. At sufficient volume, these requests can consume the target’s computing resources and prevent legitimate users from accessing the service.

HTTP floods are often launched through botnets consisting of compromised computers, servers, mobile devices, and Internet of Things devices. By distributing requests across many sources, attackers can generate significant traffic while making the attack harder to distinguish from normal activity.

How does an HTTP flood attack work?

An HTTP flood generally follows four stages:

The attacker assembles a botnet. The attacker compromises or rents access to a network of devices capable of sending requests.
The attacker selects resource-intensive targets. These may include login pages, search functions, APIs, checkout workflows, database-driven pages, or uncached content.
The botnet sends large volumes of requests. Requests may come from thousands of IP addresses and imitate normal browser behavior.
Application resources become exhausted. Servers, databases, connection pools, or third-party services struggle to keep up, causing slow responses, errors, or a complete outage.

Sophisticated attacks may vary request paths, parameters, headers, cookies, and IP addresses. Some also operate at a relatively low request rate while repeatedly targeting resource-intensive functions. This makes request volume alone an unreliable indicator of an attack.

What is the difference between an HTTP GET flood and a POST flood?

An HTTP GET flood sends large numbers of requests for pages, images, files, API responses, or other resources. Attackers often target dynamic or uncached pages that require the origin server to generate a response for every request.

An HTTP POST flood sends requests containing data to the application. These attacks may target login forms, account creation workflows, search fields, file uploads, checkout processes, or API endpoints. Because POST requests can trigger database queries and other backend operations, relatively modest traffic volumes may consume considerable resources.

Both methods can be combined in the same attack.

How is an HTTP flood different from other DDoS attacks?

HTTP floods target the application layer and are typically measured in requests per second. Network- and transport-layer DDoS attacks instead attempt to saturate bandwidth or overwhelm protocols and networking infrastructure.

Attack type	Primary target	Common measurement	Example
Volumetric attack	Network bandwidth	Bits per second	UDP flood
Protocol attack	Network infrastructure	Packets per second	SYN flood
Application-layer attack	Websites, applications and APIs	Requests per second	HTTP flood

Application-layer attacks may require less traffic than volumetric attacks because each malicious request can trigger significant work inside the application.

Why are HTTP floods difficult to detect?

HTTP is the same protocol legitimate visitors use to interact with websites and APIs. A malicious request may therefore look valid when evaluated in isolation.

Attackers can make detection even harder by:

Distributing requests among many IP addresses
Rotating user agents, headers and cookies
Requesting different URLs and resources
Maintaining valid-looking sessions
Sending traffic at irregular rates
Using residential proxies or compromised consumer devices
Mimicking typical browser navigation
Targeting expensive application functions instead of generating extreme volume

Effective detection must consider behavior, traffic patterns, request attributes and application context, not simply block every user who exceeds a fixed threshold.

What resources do HTTP flood DDoS attacks commonly target?

Attackers often focus on endpoints that require significant processing or access to backend systems, including:

Login and authentication pages
Search and filtering tools
Product detail and inventory pages
Shopping carts and checkout workflows
APIs and GraphQL endpoints
Password-reset functions
Report-generation tools
File-upload or download services
Pages that cannot be cached
Endpoints that trigger database queries
Requests that call third-party services

By targeting these resources, an attacker may cause disruption without producing an unusually large amount of bandwidth.

What are the risks of an HTTP flood?

A successful HTTP flood can affect more than website availability. Potential consequences include:

Service outages: Customers may be unable to access websites, applications, or APIs.
Performance degradation: Slow page loads and API responses can harm the user experience.
Lost revenue: Disrupted shopping, advertising, subscriptions, and transactions can create immediate financial losses.
Higher infrastructure costs: Autoscaling, bandwidth consumption, database usage, and cloud egress can increase operating expenses.
Operational strain: Engineering and security teams may be pulled away from other priorities to investigate and mitigate the attack.
Reputational damage: Repeated outages can reduce customer confidence and affect business relationships.
Security concealment: Attackers may use a visible DDoS event to distract defenders from fraud, account takeover, or another intrusion.

What are the signs of an HTTP flood DDoS attack?

Possible warning signs include:

An unexpected increase in requests per second
Traffic spikes concentrated on one or several endpoints
Higher CPU, memory, database, or connection-pool utilization
More cache misses and origin requests
Increased latency, timeouts, or HTTP 5xx errors
Repeated requests with similar behavioral patterns
Unusual traffic from particular regions, networks, or device types
Large numbers of new or incomplete sessions
Increased cloud infrastructure or egress costs
Traffic volumes that do not align with campaigns or business events

These symptoms can also result from legitimate demand. Teams should evaluate them in context and compare them with established traffic baselines.

How can organizations mitigate HTTP flood attacks?

A layered defense is usually more effective than relying on a single control.

Detect anomalous behavior

Monitor normal traffic patterns by endpoint, method, geography, client type, response status and other attributes. Behavioral detection can help distinguish an attack from a legitimate traffic spike.

Filter traffic at the edge

A distributed edge platform can inspect and block malicious requests before they reach the origin. This helps preserve application capacity and reduces the infrastructure costs associated with processing attack traffic.

Apply intelligent rate limits

Rate limiting can restrict excessive requests based on characteristics such as IP address, client identity, endpoint, session, or API token. Limits should reflect the behavior of each resource rather than use one threshold for the entire application.

Use a web application firewall

A WAF can inspect requests and block traffic matching malicious patterns. It can also protect the application against vulnerabilities that attackers may target alongside a DDoS campaign.

Deploy bot management

Bot management tools examine behavioral and client signals to distinguish automated traffic from human users. This is especially important when attack requests rotate IP addresses or imitate browsers.

Cache content wherever possible

Serving cacheable content from the edge reduces the number of requests reaching origin infrastructure. Teams should also identify dynamic endpoints that can safely use short-lived or selective caching.

Protect expensive endpoints

Authentication, search, GraphQL, checkout, and other computationally intensive functions may need specific rate limits, request validation, query restrictions, or access controls.

Maintain origin protections

Restrict direct access to origin servers so attackers cannot bypass edge security. Capacity planning, load balancing, timeouts, connection limits and autoscaling can provide additional resilience.

What are the best practices for preventing HTTP floods?

Organizations should:

Establish normal traffic baselines before an incident occurs
Monitor request and origin metrics in real time
Create endpoint-specific security policies
Combine DDoS protection, WAF, bot management and rate limiting
Block direct-to-origin traffic wherever possible
Cache frequently requested content at the edge
Test protections under realistic traffic conditions
Document escalation paths and incident-response responsibilities
Regularly review logs for changes in attacker behavior
Ensure controls can adapt without blocking legitimate traffic surges

It is especially important to account for flash crowds caused by product launches, ticket sales, breaking news, livestreams, and seasonal shopping. These events can resemble attacks, but blocking them may be just as damaging to the business.

Can a CDN stop an HTTP flood?

A content delivery network (CDN) can help by distributing traffic, absorbing request volume, serving cached content, and reducing pressure on origin systems. However, caching alone may not stop HTTP floods that target dynamic pages, APIs, or unique URLs.

For stronger protection, CDN capabilities should be combined with application-layer DDoS detection, adaptive mitigation, rate limiting, WAF protection, bot management, and origin shielding.

Can rate limiting prevent every HTTP flood?

No. Rate limiting is valuable, but fixed thresholds have limitations. Attackers may distribute traffic among thousands of sources so that no individual IP exceeds the limit. Poorly configured thresholds can also block legitimate users during high-demand events.

More effective protection combines rate limits with behavioral analysis and signals such as endpoint, session, client identity, request attributes, historical activity, and traffic anomalies.

How does Fastly help protect against HTTP floods?

Fastly DDoS Protection is designed to detect and mitigate application and network-layer attacks at the edge before malicious traffic reaches origin infrastructure. Its Adaptive Threat Engine continuously evaluates traffic for anomalous changes and creates tailored mitigation rules based on the characteristics of an attack, even when attackers rotate IP addresses. Fastly states that mitigation can begin within seconds and requires no manual tuning. Learn more about Fastly DDoS Protection.

Organizations can complement DDoS protection with additional Fastly capabilities:

Fastly Next-Gen WAF helps protect web applications and APIs by inspecting requests and identifying malicious behavior.
Bot Management helps detect and mitigate unwanted automated traffic.
Rate limiting allows teams to control excessive requests and establish policies for sensitive or resource-intensive endpoints.
Fastly CDN serves content from the edge, reducing the number of requests that reach origin infrastructure.
Real-time observability helps teams investigate traffic changes and understand how mitigation rules are responding.

Together, these capabilities provide layered protection that helps maintain application performance and availability while minimizing the impact on legitimate users.