Auditor-requested API inventory
What middleBrick covers
- Black-box scanning with no agents or code access required
- Covers 12 OWASP API Top 10 categories with LLM adversarial probes
- OpenAPI 3.0/3.1 and Swagger 2.0 parsing with $ref resolution
- Authenticated scanning with ownership verification
- Read-only methods and strict safety blocks
- Continuous monitoring and CI/CD integration options
The need for an auditor-requested API inventory
An auditor often asks for a complete inventory of APIs in scope, including how they are accessed and what data they expose. Without an authoritative list, teams miss shadow endpoints, legacy integrations, and undocumented data flows that can materially affect risk posture.
What a team gets wrong when skipping this work is reliance on informal documentation, memory, or partial network scans that miss non-standard paths, unsupported frameworks, or deprecated operations. This increases the likelihood of control failures around authentication, authorization, and data exposure when evidence is requested.
A good workflow starts with an initial discovery pass using read-only methods, followed by cross-referencing discovered endpoints against source definitions such as OpenAPI specifications. Findings are normalized, prioritized, and linked back to business owners so that the inventory stays current as the API surface evolves.
middleBrick supports this workflow by parsing OpenAPI 3.0, 3.1, and Swagger 2.0 with recursive $ref resolution and comparing spec definitions to runtime behavior. The scanner identifies undefined security schemes, deprecated operations, missing pagination, and sensitive field exposure, producing an inventory that maps findings to OWASP API Top 10 (2023) and supports audit evidence for SOC 2 Type II and PCI-DSS 4.0.
Discovery methods and read-only constraints
Discovery is performed using read-only HTTP methods (GET and HEAD) plus text-only POST for LLM probes. No agents, SDKs, or code access are required, and the scanner works with any language, framework, or cloud environment.
Authenticated scanning allows the use of Bearer tokens, API keys, Basic auth, and cookies. Before credentials are accepted, a domain verification gate confirms ownership through a DNS TXT record or an HTTP well-known file, ensuring only the domain owner can scan with credentials. The scanner forwards only a header allowlist consisting of Authorization, X-API-Key, Cookie, and X-Custom-* headers.
middleBrick does not perform active SQL injection or command injection, as those tests require intrusive payloads outside the stated scope. It also does not detect business logic vulnerabilities, blind SSRF, or guarantee compliance with HIPAA, GDPR, ISO 27001, NIST, CCPA, or similar regulations; these require human review and organizational processes.
The scan completes in under a minute, and scan data is deletable on demand, purged within 30 days of cancellation, and never sold or used for model training.
Detection coverage across OWASP API Top 10 and common exposures
The scanner covers 12 categories aligned to OWASP API Top 10, including authentication bypass and JWT misconfigurations such as alg=none, HS256, expired or missing claims, and sensitive data in claims. It also flags missing security headers, WWW-Authenticate compliance issues, BOLA and IDOR via sequential ID enumeration and adjacent-ID probing, and BFLA through admin endpoint probing and role/permission field leakage.
Additional categories include property authorization with over-exposure and internal field leakage, input validation issues such as CORS wildcards (with and without credentials) and dangerous HTTP methods, and rate limiting detection through header analysis and oversized response or unpaginated array identification.
Data exposure findings cover PII patterns such as email addresses, Luhn-validated card numbers, context-aware SSNs, and API key formats for AWS, Stripe, GitHub, and Slack, along with error and stack-trace leakage. Encryption checks validate HTTPS redirects, HSTS, cookie flags, and mixed content, while SSRF probes target URL-accepting parameters, internal IP detection, and IP-bypass attempts.
For LLM and AI Security, the scanner runs 18 adversarial probes across Quick, Standard, and Deep tiers, including system prompt extraction, instruction override, DAN and roleplay jailbreaks, data exfiltration, cost exploitation, encoding bypasses, translation-embedded injection, few-shot poisoning, markdown injection, multi-turn manipulation, indirect prompt injection, token smuggling, tool-abuse, nested instruction injection, and PII extraction.
OpenAPI spec cross-validation and continuous monitoring
By parsing OpenAPI definitions, middleBrick cross-references spec definitions against runtime findings to highlight undefined security schemes, sensitive fields, deprecated operations, and missing pagination. This helps teams align implementation with declared contracts and surface inconsistencies that often lead to security gaps.
With Pro tier, continuous monitoring schedules rescans every 6 hours, daily, weekly, or monthly, and detects diffs between scans to track new findings, resolved findings, and score drift. Email alerts are rate-limited to one per hour per API, and HMAC-SHA256 signed webhooks can be configured with auto-disable after 5 consecutive failures.
Teams can track score trends in the Web Dashboard, download branded compliance PDFs, and integrate scanning into CI/CD via the GitHub Action, which fails the build when the score drops below a configurable threshold. The CLI provides JSON or text output for scripting, and the MCP Server enables scanning from AI coding assistants such as Claude and Cursor.
What middleBrick does not do and safety posture
middleBrick is a scanner that detects and reports with remediation guidance; it does not fix, patch, block, or remediate issues. It does not perform active SQL injection or command injection tests, and it does not replace a human pentester for high-stakes audits.
Destructive payloads are never sent. Private IPs, localhost, and cloud metadata endpoints are blocked at three layers. Customer scan data is deletable on demand and is never used for model training.
For any other regulation or framework, the tool aligns with security controls described in documents such as SOC 2 Type II and PCI-DSS 4.0, using language of support and evidence rather than certification or guarantees. It helps you prepare for audits but does not ensure compliance with HIPAA, GDPR, ISO 27001, NIST, CCPA, or other regulatory regimes.