Skip to main content
Version: v1

Denial of Service (DoS)

DoS

What is it?​

Denial of Service (DoS) occurs when an API is overwhelmed with excessive or resource-intensive requests, causing degradation or complete unavailability of the service.

Unlike traditional network-layer DoS attacks, API-level DoS focuses on exploiting application logic, expensive operations, and resource consumption patterns to exhaust backend systems such as CPU, memory, database connections, or third-party dependencies.

APIs are especially vulnerable due to their exposure to untrusted clients and their reliance on backend processing for each request.

What are specific examples?​

  • High-frequency request flooding without throttling
  • Expensive database queries triggered repeatedly
  • Large payload submissions consuming memory
  • Deeply nested JSON causing parsing overhead
  • Repeated invocation of resource-heavy endpoints (e.g., search, analytics)
  • Lack of timeouts leading to connection exhaustion
  • Chained requests amplifying backend load

Test case FAQs​

When is this test case applicable?​

  • Public-facing APIs or endpoints exposed to untrusted users
  • Endpoints performing resource-intensive operations
  • APIs interacting with databases, search engines, or external services
  • Critical business flows where availability is essential

How does it work?​

Prerequisites​

  • Identification of high-cost or critical endpoints
  • Baseline performance metrics (latency, throughput)
  • Ability to generate controlled request load

Test sequence​

  1. Establish baseline response metrics under normal conditions
  2. Gradually increase request volume to simulate load
  3. Send payloads designed to increase processing cost:
    • Large request bodies
    • Complex query parameters
    • Deeply nested structures
  4. Trigger repeated execution of expensive operations
  5. Monitor system behavior:
    • Response time degradation
    • Error rates (5xx, timeouts)
    • Resource utilization (CPU, memory)
  6. Identify thresholds where service degradation begins

Success/Failure indications​

  • Failure (vulnerable):

    • Significant latency increase under moderate load
    • API becomes unresponsive or returns 5xx errors
    • Resource exhaustion (CPU spikes, memory leaks)
    • Lack of protective mechanisms (throttling, timeouts)

  • Success (secure):

    • Graceful degradation under load
    • Requests are throttled or limited appropriately
    • Stable response times within defined thresholds
    • No uncontrolled resource exhaustion

What is the solution?​

  • Implement rate limiting and throttling mechanisms
  • Enforce request size and complexity limits
  • Optimize expensive operations (queries, processing logic)
  • Use timeouts and circuit breakers for backend services
  • Apply caching for frequently accessed data
  • Isolate critical services and apply resource quotas
  • Continuously monitor and test API performance under load

References​

Was this page helpful?