Pre-launch API security check

Before you promote an API to production, validate the surface that will be publicly reachable. A concise checklist that aligns with the OWASP API Top 10 (2023) helps you focus on what matters at pre-launch.

• Confirm that authentication is required for all non‑public endpoints and that tokens are validated with strict algorithms.
• Verify that object level authorization checks are enforced for each resource that the API exposes.
• Ensure that responses do not leak internal fields, stack traces, or verbose error identifiers.
• Check that security headers, HSTS, and secure cookie attributes are present and consistent across routes.
• Review OpenAPI definitions for deprecated operations, missing pagination, and undefined security schemes.

These controls map findings to compliance requirements for PCI-DSS 4.0, SOC 2 Type II, and OWASP API Top 10 (2023). Completing this checklist reduces common misconfigurations before traffic arrives.

middleBrick is a self‑service API security scanner that operates without agents, SDKs, or code access. You submit a URL and receive a risk score from A to F with prioritized findings within under a minute.

The scanner uses read‑only methods (GET and HEAD) and text‑only POST for LLM probes. This design ensures broad compatibility with any language, framework, or cloud target while avoiding invasive testing.

Because no authentication is required for the baseline scan, you can quickly validate publicly exposed behavior. For deeper verification, authenticated scanning requires domain ownership proof via DNS TXT record or an HTTP well‑known file, ensuring only the domain owner can submit credentials.

When authenticated, the scanner forwards only a strict allowlist of headers, including Authorization, X‑API‑Key, Cookie, and X‑Custom‑* headers. This approach limits side effects and keeps the scan predictable.

The scanner evaluates 12 security categories aligned to the OWASP API Top 10 (2023) and exposes findings that help you prepare for audits tied to PCI-DSS 4.0 and SOC 2 Type II.

• Authentication issues such as JWT alg=none, missing claims, and security header misconfigurations.
• Broken object level authorization and IDOR, including sequential ID enumeration and active adjacent probing.
• Property authorization problems like over‑exposed fields and mass‑assignment surfaces.
• Input validation gaps, including wildcard CORS with credentials and dangerous HTTP methods.
• Data exposure patterns such as emails, Luhn‑validated card numbers, API key formats, and error leakage.
• LLM / AI security probes that test for system prompt extraction, jailbreaks, and token smuggling across three scan tiers.

These findings supports audit evidence for the referenced frameworks and provide concrete guidance to adjust configurations or code. The scanner does not claim certification or compliance, but it supplies the data needed for your own assessment.

middleBrick parses OpenAPI 3.0, 3.1, and Swagger 2.0 documents with recursive $ref resolution. By cross‑referencing the spec against runtime behavior, it highlights mismatches that often lead to security issues.

Detected spec concerns include undefined security schemes, sensitive fields described without protection, deprecated operations, and missing pagination that can lead to unbounded data exposure. These observations align with security controls described in the OWASP API Top 10 and help you refine the contract before deployment.

When combined with runtime findings, the OpenAPI analysis gives a more complete picture of surface area and hidden risks that black‑box probes alone might miss.

For teams that require continuous assurance, the Pro tier offers scheduled rescans every 6 hours, daily, weekly, or monthly. It detects diffs between scans, including new findings, resolved items, and score drift.

Email alerts are rate‑limited to one per hour per API, and webhooks use HMAC‑SHA256 signatures. After five consecutive failures, webhooks are automatically disabled to prevent noisy failure loops.

Customer scan data is deletable on demand and purged within 30 days of cancellation. Data is never sold and is not used for model training. The tool does not remediate issues; it surfaces findings with guidance so your team can apply fixes.