API endpoints have become the primary attack surface in application-layer DDoS campaigns. In assessments completed over the past twelve months, DDactic found that 78% of organizations with adequate volumetric DDoS protection had meaningful gaps at the API layer: missing rate limits, absent connection timeout settings, or authentication endpoints with no throttling at all.
The DDactic API Hardening Module is a dedicated scan stage that enumerates your API surface -- REST, GraphQL, gRPC, and WebSocket -- and produces per-endpoint hardening recommendations with the exact configuration commands for your vendor stack. This post describes what the module scans, what it produces, and why we built it as a separate stage rather than folding it into the general L7 reconnaissance pass.
What the Module Scans
The module starts from the subdomain and port inventory built during Stage 1 and Stage 2 of the DDactic pipeline. Any host that responds with a JSON Content-Type, an application/grpc content type, or a GraphQL introspection response is added to the API candidate list. The module then performs the following checks against each candidate endpoint:
- Rate limit presence and effective threshold (by sending calibrated request sequences)
- Authentication requirement on all paths, including documentation and health endpoints
- GraphQL introspection availability and query depth limits
- TLS session resumption behavior and reconnect rate
- Idle connection timeout (default values indicate no explicit configuration)
- Response body size on unbounded list endpoints
- Error verbosity under malformed input (stack traces, internal paths, framework versions)
How Findings Are Reported
Each finding in the API Hardening Module output includes the endpoint URI, the observed behavior, the expected behavior, a severity score, and a vendor-specific remediation block. The remediation block is generated from the vendor detection performed earlier in the pipeline. If your API is behind Cloudflare, the block contains a Cloudflare Ruleset Engine expression. If it is behind AWS WAF, it contains the CLI command to create the matching rule. No generic advice: the output is copy-paste ready for your actual configuration.
Vendor detection drives the remediation output
DDactic identifies your edge vendor from TLS certificate attributes, HTTP response headers, and behavioral fingerprints during Stage 3. The API Hardening Module uses that identification to select the appropriate configuration template for remediation recommendations.
Why a Separate Stage
API hardening assessment requires a different probing strategy than general L7 reconnaissance. Probing for rate limits means sending enough requests to trigger the limit -- which must happen at measured rates, with jitter, over a sufficient window. Doing this as part of a broad passive scan would either miss the limits entirely or trigger false alerts in the customer's existing monitoring. The module is designed to run as an explicit, scoped test with rate-limit thresholds tuned to avoid service disruption while still generating a meaningful signal.
The module also handles multi-region variation. A rate limit configured in Cloudflare via the dashboard may propagate to edge nodes within 30 seconds, but rules applied via API take longer in some configurations. DDactic probes from two geographically separated vantage points and reports if limits are inconsistent between them -- a common operational gap that leaves customers believing they are protected while a subset of edge nodes are still accepting unlimited traffic.
Availability
The API Hardening Module is included in all DDactic scans at the Standard tier and above. Customers on the free scan tier receive a partial API surface enumeration without the active rate-limit probing. The full module output is included in the OPI scorecard under the API sub-score dimension.
Scan Your API Surface
The DDactic API Hardening Module runs as part of every standard assessment. Start with a free scan to see your API exposure summary.
Run a Free Scan