Migrating from Kong to middleBrick
What middleBrick covers
- Black-box scanning with no agents or code access required
- Sub-minute scan times with prioritized risk scoring A–F
- Coverage of 12 OWASP API Top 10 categories including LLM security
- OpenAPI 3.0/3.1 and Swagger 2.0 parsing with spec–runtime cross-check
- Authenticated scan support for Bearer, API key, Basic, and Cookie
- CI/CD integration via GitHub Action with build gating
Compare Kong API Management to middleBrick scanning scope
Kong operates as an API gateway and control plane, enforcing policies, routing, and transformations for runtime traffic. middleBrick is a black-box API security scanner that analyzes design-time posture by submitting read-only requests to an endpoint and reporting risk across 12 categories aligned to OWASP API Top 10. The two tools solve different problems: Kong manages live traffic; middleBrick surfaces misconfigurations and exposures before deployment.
- Kong manages authentication, rate limiting, and request transformation at the edge.
- middleBrick maps findings to compliance frameworks such as PCI-DSS 4.0, SOC 2 Type II, and OWASP API Top 10.
- Kong runtime metrics complement middleBrick design-time risk scores, but findings are not directly comparable.
Export existing Kong configuration and assets
Before migrating, extract declarative configuration and entities from Kong to preserve context for documentation and future audits. Use Kong Admin API calls to capture services, routes, plugins, and certificates. Store responses as version-controlled files to enable reconstruction in the new workflow.
curl -s -X GET http://kong:8001/services --header "Content-Type: application/json" | jq '.' > kong_services.json
curl -s -X GET http://kong:8001/routes --header "Content-Type: application/json" | jq '.' > kong_routes.json
curl -s -X GET http://kong:8001/plugins --header "Content-Type: application/json" | jq '.' > kong_plugins.json
Note that plugin configurations containing sensitive references (e.g., key-auth credentials) will appear in clear text; rotate any exposed keys after export. These artifacts do not include runtime traffic or historical scan data, which middleBrick does not ingest.
Rebuild scan history and CI integration during cutover
middleBrick does not ingest Kong logs or metrics, so historical security findings must be re-established through new scans. Start by inventorying all public and internal endpoints from your exported routes and services, then submit each base URL to the middleBrick scanner using the CLI or dashboard.
To keep CI wired during the transition, retain existing Kong pipelines while adding a middleBrick stage in parallel. Run middlebrick scan <url> in your GitHub Action or CI job; fail the build only when the score drops below your chosen threshold. This approach avoids an all-at-once policy change while you validate the new toolchain.
- Use the same endpoint list from Kong exports to ensure coverage parity.
- Configure email or Slack alerts in the Pro tier to notify owners of new findings.
- Track score trends over time to measure security posture independent of traffic policies.
What you will miss and what changes in posture visibility
After migrating from Kong, you will lose runtime insights such as live request rates, latency distributions, and Kong-specific plugin metrics. middleBrick fills visibility gaps by providing design-time risk scores, prioritized findings, and mapping to compliance frameworks, but it does not replace operational telemetry.
Security coverage shifts from runtime enforcement to early detection of issues like JWT misconfiguration, IDOR, sensitive data exposure, and LLM-specific injection probes. Because the scanner is read-only, it will not block malicious requests; treat its output as a checklist for hardening before deployment.
- No active blocking or request modification in middleBrick.
- No storage of customer payloads or personal data beyond scan reports.
- Continuous monitoring can resurface drifted configurations after code or dependency changes.
Authentication, headers, and data handling considerations
If your Kong setup uses authenticated admin access, replicate the same constraints in middleBrick by leveraging authenticated scanning only for the domain owner. Domain verification via DNS TXT or a well-known HTTP file ensures that credentials are used by the rightful owner. Configure header allowlists to forward only Authorization, X-API-Key, Cookie, and X-Custom-* headers during scans.
middleBrick stores scan results and metadata; customer data is deletable on demand and purged within 30 days of cancellation. It does not use scan data for model training or share findings externally. For high-stakes audits, supplement scanner output with human-led penetration testing to address business logic risks not covered by automated checks.