New endpoint auto-discovery scan

Endpoint auto-discovery scanning identifies API surface that may be undocumented or unintentionally exposed. Teams often skip this step when they rely on internal documentation or assume a fixed list of routes. Without automated discovery, new routes added during rapid development remain visible to external consumers and scanners, increasing exposure of deprecated methods, verbose error messages, and data over‑exposure.

A robust workflow combines automated discovery with continuous validation. Begin with passive reconnaissance using the application’s public entry points, then follow links and forms to expand the inventory. Validate each discovered method against expected behavior and authorization requirements. Integrate scanning into CI/CD so changes are evaluated before deployment, and schedule recurring scans to catch regressions introduced by feature branches or third‑party updates.

Example CLI usage to initiate a scan and receive structured output:

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

Use the JSON output to feed dashboards or gate checks, and to track changes over time.

middleBrick performs black‑box scanning that requires no agents or SDK integration. It follows links, tests read‑only methods (GET and HEAD), and exercises selected POST bodies limited to text‑only LLM probes. The scanner evaluates results against the OWASP API Top 10 (2023) and maps findings to PCI‑DSS 4.0 and SOC 2 Type II control references. Detection focuses on observable behavior rather than internal implementation details, which keeps the approach applicable to any language, framework, or cloud environment.

During discovery, the scanner evaluates endpoints across these categories:

• Authentication bypass and JWT misconfigurations such as alg=none, HS256 usage, expired tokens, missing claims, and sensitive data in claims.
• BOLA and IDOR via sequential ID enumeration and active adjacent‑ID probing.
• BFLA and privilege escalation through admin endpoint probing and role/permission field leakage.
• Property authorization issues including over‑exposure, internal field leakage, and mass‑assignment surface.
• Input validation gaps like CORS wildcard with credentials, dangerous HTTP methods, and debug endpoints.
• Rate limiting and resource consumption indicators including missing rate‑limit headers and oversized responses.
• Data exposure patterns such as emails, Luhn‑validated card numbers, context‑aware SSNs, API key formats, and stack‑trace leakage.
• Encryption and transport issues including missing HTTPS redirects, HSTS, and cookie flags.
• SSRF indicators involving URL‑accepting parameters, internal IP detection, and active bypass probes.
• Inventory management concerns like missing versioning, legacy path patterns, and server fingerprinting.
• Unsafe consumption surface from excessive third‑party URLs and webhook/callback endpoints.
• LLM / AI Security probes covering prompt extraction, instruction override, jailbreaks, data exfiltration, and token smuggling.

For endpoints that require authentication, middleBrick supports Bearer tokens, API keys, Basic auth, and cookies. Domain verification is enforced so only the domain owner can submit credentials for scanning. The scanner forwards a restricted allowlist of headers, including Authorization, X‑API‑Key, Cookie, and X‑Custom‑*. Scan data is deletable on demand and purged within 30 days of cancellation. No customer data is used for model training, and findings are not sold to third parties.