NIS2 directive readiness

NIS2 expands obligations for entities handling critical services and digital infrastructure. APIs that support these services become a boundary that must be understood and controlled. Teams often underestimate the attack surface of internal APIs, legacy integrations, and third party endpoints, assuming network segregation is sufficient. In practice, misconfigured CORS, verbose error messages, and weak authentication on API paths enable unauthorized access and data leakage that affect the broader service ecosystem.

Without a repeatable assessment workflow, organizations rely on ad hoc checks or informal code reviews, which miss runtime behaviors and configuration drift. Common gaps include overly permissive CORS rules, unversioned or deprecated endpoints, missing rate limiting, and accidental exposure of internal fields. These issues remain latent until an incident reveals data exfiltration, privilege escalation, or service disruption. A consistent scan cadence aligned to the API lifecycle surfaces these findings before they impact availability or confidentiality.

Establish a baseline by inventorying public and authenticated API endpoints, including OpenAPI specifications when available. Run a black-box scan against each entry point to detect authentication weaknesses, IDOR, data exposure patterns, and input validation issues. Incorporate authenticated scans where credentials are available, ensuring scope is limited to domains verified through DNS TXT or HTTP well-known files. Track findings in a dashboard, tie each finding to relevant control objectives, and integrate checks into CI/CD to prevent regressions between release cycles.

Example CLI usage

middlebrick scan https://api.example.com --output json

Authenticated scan example with header allowlist

curl -H "Authorization: Bearer <token>" https://api.example.com/openapi.json | middlebrick scan --spec - --auth bearer

middleBrick maps findings to controls referenced in PCI-DSS 4.0, SOC 2 Type II, and OWASP API Top 10 (2023). Detection of authentication bypass, broken object level authorization, excessive data exposure, and injection risks supports audit evidence for these frameworks. For other regulations, the scanner helps you prepare for security controls described in relevant guidelines, enabling you to build defensible audit artifacts using objective scan data. It is a scanning tool and does not replace formal assessment or certification processes.

Continuous monitoring reduces noise while keeping risk visible across changes. Scheduled rescans every six hours, daily, weekly, or monthly keep findings current. Diff detection highlights new issues and resolved items, while score drift indicates systemic improvements or regressions. Email alerts are rate limited to one per hour per API, and signed webhooks with auto-disable after five consecutive failures integrate findings into ticketing or orchestration platforms without overwhelming responders.

The scanner operates as a read-only black-box solution that submits GET and HEAD requests, with optional text-only POST for LLM probes. It analyzes OpenAPI 3.0, 3.1, and Swagger 2.0 specs with recursive reference resolution and compares runtime behavior against declared definitions. Out of the box it detects issues in authentication schemes, IDOR, privilege escalation paths, data exposure including PII and API key patterns, CORS misconfigurations, rate limiting, SSRF indicators, and inventory shortcomings. For LLM-facing APIs, it runs adversarial probes across quick, standard, and deep tiers to identify prompt injection, jailbreak, and data exfiltration risks. Findings include prioritized risk scores and contextual remediation guidance, without attempting to patch or block systems.