Storage Exhaustion DoS: Lessons from Real-World Vulnerability Assessment

Introduction: A Silent Killer

When we think of denial-of-service attacks, we often imagine sophisticated DDoS botnets or carefully crafted protocol exploits. But some of the most devastating attacks come from the simplest vector: unvalidated input combined with persistent storage.

During a recent security audit, I discovered a critical storage-exhaustion vulnerability that allowed an unauthenticated attacker to disable an entire platform for all users in under 5 minutes. What made this especially dangerous was how invisible it was: no complex payload, no zero-days, just basic HTTP requests and application-level misconfiguration.

This article walks through the vulnerability lifecycle, attack mechanics, real-world impact metrics, and a layered remediation strategy that goes beyond simple rate limiting.

---

The Vulnerability: Unvalidated Input + Persistent Storage

The affected application accepted user-generated messages without server-side size validation. The API contract was simple:

POST /api/chat/{chatId}/message
Content-Type: application/json

{
  "content": "..." // No max length enforced
}

While the documentation suggested messages should be “reasonably short,” the server imposed no programmatic limit. The only constraint was the reverse-proxy default (typically Nginx’s 1 MB cap), which still allowed messages 977 KB in size.

Every message was persisted to disk. No cleanup, no quota system, no per-user storage limits.

🔴 CRITICAL: F-DOS-DISK - Storage Exhaustion DoS

Unauthenticated users could POST 977 KB messages to any chat room. After approximately 1,000 messages (totaling ~954 MB), the application’s chat storage directory would fill, causing all subsequent chat creation operations to fail with INTERNAL_SERVER_ERROR: Chat directory could not be created for every user on the platform.

---

Attack Mechanics: Proof-of-Concept Timeline

To validate this vulnerability, I built an automated browser-based attack using Playwright (a headless browser framework). The attack:

1. Opens 50 concurrent browser connections
2. Each connection joins a public chat room (no authentication required)
3. Each sends 977 KB messages repeatedly
4. Monitors server response times and success rates

📊 Attack Timeline (Observed July 7, 2026)

Phase	Duration	Messages Sent	Disk Used	System State
Preparation	0-30s	~100	~97 MB	Normal; response time below 200ms
Escalation	30-150s	~400	~388 MB	Performance degrades; p95 latency above 500ms
Critical Mass	150-261s	~500	~954 MB total	Chat creation begins failing
Blackout	261s+	N/A	Disk full	ALL users unable to create chats

Key insight: The entire platform was disabled in under 4.5 minutes using ~1,000 requests from a single attacker with no special privileges.

---

Why This Matters: Real-World Impact

This vulnerability sits at the intersection of three attack vectors:

• No Authentication: Any visitor can launch the attack
• No Rate Limiting: Requests are never throttled
• Persistent Effect: Disk remains full until manually cleaned

Unlike transient DoS attacks (which end when the attacker stops), this attack leaves the platform in a degraded state that requires manual intervention to recover.

Related Finding: F-RATELIMIT - No Rate Limiting

The application had no rate limiting on message creation endpoints. Combined with the storage exhaustion flaw, this allowed the attack to proceed at maximum speed without hitting any defense mechanism.

---

Layered Remediation: Defense in Depth

A single fix would not be sufficient. The team implemented a multi-layered approach:

1. Input Validation (Immediate)

// Add to message DTO
@MaxLength(50000)  // 50 KB limit
private String content;

This enforces a 50 KB hard limit per message, reducing potential disk consumption by 19x.

2. Rate Limiting (Immediate)

// Redis-backed rate limiter
loginLimit: 10 requests/minute per IP
messageLimit: 50 messages/minute per user
exponentialBackoff: true

Throttles both authentication and message endpoints, making brute-force or spam attacks impractical.

3. Per-User Storage Quotas (Short-term)

// Enforce per-user limits
maxMessagesPerUser: 10,000
maxStoragePerUser: 100 MB
quotaCheck: before_message_save()

Even if a single user violates rate limiting, they cannot exhaust the entire platform.

4. Disk Space Monitoring & Alerts (Short-term)

// Automated alerting
if disk_usage > 80% {
    alert("Admin: Disk approaching capacity");
    consider_archival_or_cleanup();
}

Provides early warning before a DoS scenario reaches criticality.

5. Secure Recovery Procedures (Medium-term)

• Automated backup & restore capability
• Chat archival to separate storage tier
• Graceful degradation (readonly mode if disk > 90%)

---

Broader Lessons: Beyond Storage Exhaustion

This vulnerability revealed a pattern that extends beyond this single application:

• Authentication ≠ Authorization ≠ Validation: Just because a user is authenticated doesn’t mean their input should be trusted. Apply strict input validation at all entry points.

• Resource Limits Are Not Optional: Rate limiting, message size caps, and storage quotas must be enforced at the application level, not delegated to infrastructure defaults.

• Persistence Has Consequences: Every write operation should trigger a quota check. Treat disk I/O as a scarce resource.

• DoS Attacks Can Be Silent: The most dangerous attacks don’t make noise in logs. They gracefully degrade service until recovery becomes impossible.

---

Conclusion

Storage exhaustion attacks are not glamorous, and they don’t make it to security conference talks. But they work, they’re trivial to execute, and they’re remarkably common in real applications.

The remediation is equally unglamorous: boring validation, boring rate limiting, and boring monitoring. Yet these basics, applied systematically, eliminate entire classes of vulnerabilities.

If you’re building a service that accepts user input, ask yourself: what happens if a single user sends 1,000 requests with 1 MB payloads? If the answer is “the system fails,” you’ve found your first fix.

---

This research was conducted as part of a full-stack security audit with explicit authorization. All findings were responsibly disclosed and remediated before publication.