# Resource limits enforced

- **Pattern:** `ab-002087` (`plugin-extension-architecture.isolation-security.resource-limits`)
- **Severity:** medium
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002087
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002087)

## Why it matters

Without execution timeouts or storage quotas, a single misbehaving plugin — whether malicious or accidentally written with an infinite loop — can block the Node.js event loop, starve other request handlers, or fill disk. CWE-400 (Uncontrolled Resource Consumption) and ISO 25010 performance-efficiency.resource-utilization both require that resource consumption be bounded. In a multi-tenant plugin environment this is especially severe: one customer's plugin degrades service for all customers, and the host has no mechanism to identify or interrupt the culprit.

## Severity rationale

Medium because unlimited plugin resource consumption — no timeouts, no storage quotas, no CPU caps — allows a single plugin to monopolize host resources and deny service to all other users.

## Remediation

Start with handler execution timeouts — they are the highest-impact resource limit and require no additional infrastructure. Race each handler invocation against a `setTimeout` reject and surface a clear timeout error attributing it to the specific plugin.

```typescript
async function invokeWithTimeout(
  handler: Function,
  context: HookContext,
  timeoutMs: number = 5000
): Promise<void> {
  const timeout = new Promise<never>((_, reject) =>
    setTimeout(() => reject(new Error(`Handler timed out after ${timeoutMs}ms`)), timeoutMs)
  );
  await Promise.race([handler(context), timeout]);
}
```

## Detection

- **ID:** `resource-limits`
- **Severity:** `medium`
- **What to look for:** Check whether the plugin system enforces any resource limits on plugin execution. Look for:
  1. Timeouts on hook handler execution — does the host abort handlers that take too long?
  2. Memory limits — does the host monitor or limit plugin memory usage?
  3. CPU limits — does the host prevent plugins from blocking the event loop?
  4. Rate limiting — does the host limit how often a plugin can call host APIs?
  5. Storage quotas — does the host limit how much data a plugin can store?
  Real-world examples:
  - Chrome extensions: 5-second service worker timeout, storage quotas per API
  - Figma: 20-second execution timeout for plugin commands
  - VS Code: extension host watchdog restarts the extension host process if unresponsive
  - Cloudflare Workers: 10ms CPU time limit (free), 30s wall clock limit
- **Pass criteria:** Count all enforced resource limits. At least one resource limit is enforced: execution timeouts on hook handlers, storage quotas, or rate limits on API calls. The limits are documented so plugin authors know the constraints. Exceeding a limit produces a clear error, not a silent failure. At least 1 resource limit must be enforced (memory, CPU time, API calls).
- **Fail criteria:** Should not pass when plugins can allocate unlimited resources without any cap or throttle. No resource limits of any kind. A plugin can run indefinitely, allocate unlimited memory, store unlimited data, and call host APIs without throttling. A single plugin can monopolize host resources.
- **Skip (N/A) when:** Plugins run in a controlled environment where the host process lifecycle is short (e.g., a build tool that runs for seconds then exits) AND only trusted plugins are used. Also skip if the runtime environment already enforces limits (e.g., plugins are Cloudflare Workers with built-in CPU/memory limits).
- **Detail on fail:** `"No resource limits exist. Hook handlers can run indefinitely — a plugin with an infinite loop will block the event loop and freeze the entire host. No timeouts, no memory monitoring, no storage quotas. A single misbehaving plugin can take down the entire application."`
- **Remediation:** Resource limits protect the host from both malicious and accidentally resource-hungry plugins. Start with execution timeouts — they're the highest-impact limit and the easiest to implement.

  ```typescript
  // Execution timeout for hook handlers:
  async function invokeWithTimeout(
    handler: Function,
    context: HookContext,
    timeoutMs: number = 5000
  ): Promise<void> {
    const timeout = new Promise<never>((_, reject) =>
      setTimeout(() => reject(new Error(`Handler timed out after ${timeoutMs}ms`)), timeoutMs)
    );
    await Promise.race([handler(context), timeout]);
  }
  ```

---

## External references

- cwe CWE-400
- iso-25010 performance-efficiency.resource-utilization

Taxons: cost-efficiency, injection-and-input-trust

HTML version: https://auditbuffet.com/patterns/ab-002087