Making required service unavailable
A denial-of-service attack reduces or removes availability. Distributed denial of service uses many sources, but one client can also exhaust expensive work, state, locks, connections, queues, storage, identities, or external dependencies.
The attack can use malformed input or valid requests that trigger authentication, cryptography, policy, database, logging, or recovery work.
Resource and dependency model
Trace bandwidth, packets, connections, TLS, parsers, sessions, identity lookups, policy evaluation, upstream pools, CPU, memory, files, queues, logs, billing, and operator attention. Record capacity, cost ratio, state lifetime, backpressure, priority, and shared failure domains.
Separate anonymous, authenticated, tenant, administrator, and recovery demand. A valid account can still generate harmful load.
Prevention and degraded operation
Filter before expensive work. Bound sizes, times, connections, state, concurrency, retries, and queues. Apply rate and quota by source, identity, tenant, resource, and action where each is meaningful. Cache safe work, isolate critical routes, shed low-priority demand, and use upstream DDoS protection for volumetric threats.
Design a narrow recovery and administration path outside the overloaded failure domain. Define when to deny, degrade, or serve stale data.
Failure and residual risk
Rate limits can block shared legitimate users and can be bypassed across sources. Challenges add client and accessibility cost. Fail-closed identity dependencies can deny all access. Fail-open modes can grant unauthorized access. Retrying a slow dependency can amplify load.
Capacity cannot absorb every attack. External providers and DNS can fail first.
Pomerium boundary
Pomerium can enforce identity-aware policy and sits in the request path, so its TLS, session, identity, policy, logging, and upstream work are part of the DoS model. Operators own capacity, limits, provider protection, upstream isolation, dependency behavior, and recovery access. Pomerium authorization does not replace volumetric mitigation.
Evaluation checklist
- Which byte, request, connection, identity, state, queue, lock, log, dependency, or operator resource is cheapest for the attacker to exhaust?
- Is untrusted work bounded before authentication, cryptography, policy, storage, and external calls?
- Do limits cover source, identity, tenant, resource, action, concurrency, and retry without unsafe shared-user denial?
- Which critical and recovery functions remain isolated during overload?
- Does degraded behavior preserve authorization and evidence rather than silently fail open?
