What is a Denial-of-Service Attack?

A denial-of-service attack (DoS) attempts to make a service unavailable to legitimate users or degrade its quality substantially. The attacker exhausts bandwidth, connections, processing power, memory or a scarce application resource. Not every overload is an attack: misconfiguration, software faults and legitimate traffic peaks can produce similar symptoms.

How do DoS and DDoS differ?

In a DoS attack, harmful load originates mainly from one source or controlled path. A distributed denial of service (DDoS) spreads it across many systems, such as compromised devices in a botnet. Distributed attacks are harder to stop with individual IP blocks and can generate more bandwidth. A single client can nevertheless overload an application with particularly expensive requests.

Which types of attack exist?

Multi-stage campaigns combine categories or change method when one defense takes effect. Request volume alone therefore does not describe an attack adequately.

What are reflection and amplification?

In a reflection attack, the attacker spoofs the victim's source address and sends requests to third-party public UDP services, which reply to the victim. If a response is much larger than its request, amplification increases the traffic further. Open or misconfigured DNS, NTP and other UDP services have repeatedly been abused this way. Operators prevent participation through secure configuration; providers can impede spoofed source addresses using ingress and egress filtering.

How can a DoS attack be recognized?

Warning signs include unusual bandwidth, rapidly rising connection or request counts, exhausted workers and pools, high latency, timeouts and error responses. Network telemetry and CDN, load balancer, server and application metrics need to be correlated. Origin, target path, headers, response cost and timing help distinguish an attack from a successful campaign or internal fault.

How can services be protected?

• Capacity and architecture: Redundant connectivity, distributed delivery, caching and controlled load balancing.
• Upstream defense: A CDN, Anycast or DDoS scrubbing can absorb traffic before the local circuit is full.
• Limits: Rate limiting, quotas, timeouts, size limits and bounded concurrency for expensive operations.
• Application protection: Optimize costly endpoints, cache results, process asynchronously and separate anonymous from authenticated use.
• Resilience: Prioritize critical functions, protect dependencies and degrade gracefully instead of failing completely.

A web application firewall can filter known application patterns, but it cannot protect an already saturated internet connection or replace resilient architecture.

Code example: bound the work performed per request

Vulnerable: the client can request an arbitrary result size and expensive relationships.

$orders = Order::with($request->input('include', []))
    ->limit($request->integer('limit'))
    ->get();

Safer:

$limit = max(1, min($request->integer('limit', 25), 100));

$orders = $request->user()->orders()
    ->select(['id', 'status', 'total', 'created_at'])
    ->cursorPaginate($limit);

Also apply query timeouts, size limits, bounded concurrency and endpoint rate limiting. No application limit alone stops a volumetric attack, but it prevents unnecessary amplification of backend work.

How should an organization respond?

1. Activate incident handling and investigate both attack and ordinary outage causes.
2. Engage providers, CDN or protection services using prepared contacts and current target information.
3. Apply focused filters, limits or challenges and monitor the effect on legitimate users.
4. Prioritize critical functions and provide status communication through an independent channel.
5. Afterwards, analyze the timeline, cost, bypasses and capacity limits.

Can resilience be tested?

Load and resilience tests are valuable but require explicit authorization, agreed limits, monitoring, stopping conditions and approval from affected hosting or cloud providers. An ordinary penetration test generally excludes destructive DoS testing. Production-oriented exercises should start with controlled load profiles and individual bottlenecks instead of generating indiscriminate maximum load.