During SOC 2 audit API security check

Run the During SOC 2 audit API security check check

What middleBrick covers

  • Maps findings to OWASP API Top 10 and SOC 2 control themes
  • Authenticated scanning with header allowlist and domain verification
  • Read-only methods to ensure safe, non-destructive testing
  • Continuous monitoring with diff detection and scheduled rescans
  • Signed webhooks and evidence-ready scan reports

Purpose during a SOC 2 audit

During a SOC 2 Type II audit, the focus is on the design and operating effectiveness of security controls related to system security and availability. middleBrick supports this phase by providing an objective, repeatable assessment of your public API surface. The scanner maps findings to SOC 2 controls, helping you validate that appropriate safeguards are in place and that evidence can be produced for the audit. It does not replace an audit, but it supplies reliable scan artifacts that auditors can review as part of their control evaluation.

Mapping findings to security frameworks

middleBrick directly maps findings to OWASP API Top 10 (2023), which is commonly referenced in SOC 2 technology control discussions. Each finding includes a reference to the relevant control theme, such as authentication weaknesses or data exposure risks. The tool also aligns findings with PCI-DSS 4.0 requirements where applicable, supporting evidence collection for related control objectives. For any other frameworks, middleBrick helps you prepare for audits by aligning with security controls described in the relevant regulatory context, without asserting compliance.

Authenticated scanning for realistic assessment

To effectively test areas protected by authentication, use authenticated scanning with the Starter tier or higher. Provide Bearer tokens, API keys, Basic auth credentials, or cookies through the dashboard or CLI. Domain verification is enforced via DNS TXT records or an HTTP well-known file, ensuring only the domain owner can submit credentials. The scanner forwards a restricted set of headers and uses read-only methods, preserving the safety posture while increasing coverage of protected endpoints.

Continuous monitoring and audit evidence

With Pro tier, enable continuous monitoring to maintain ongoing visibility across scheduled rescans. The system tracks diffs between scans, highlighting new findings, resolved items, and score drift. Email alerts are rate-limited to reduce noise, and HMAC-SHA256 signed webhooks notify external systems of material changes. These features generate time-stamped evidence that can be referenced during audit testing cycles, showing how API security posture is monitored and maintained over time.

Limitations and realistic expectations

middleBrick is a scanning tool and does not perform intrusive exploit testing, such as active SQL or command injection. It does not detect business logic flaws, blind SSRF, or nuanced authorization issues that require domain knowledge. The scanner also does not replace a human pentester for high-stakes audits. Use its findings as a starting point for deeper investigation and remediation, and pair automated results with manual review to address context-specific risks.

Run this check on your API See all use cases

Frequently Asked Questions

Can middleBrick certify SOC 2 compliance?
No. The tool detects and reports findings; it does not certify compliance. Use its output as evidence, but rely on auditors to evaluate the full control environment.
What is the recommended scan frequency for SOC 2 audits?
Enable continuous monitoring with monthly rescans for most environments. Increase frequency for rapidly changing APIs or after major deployments to keep evidence current.
Does authenticated scanning store my credentials?
Credentials are used only during the scan to access protected endpoints. They are not stored in a retrievable format and are handled in memory as part of the authenticated testing workflow.
How are false positives handled in audit evidence?
Each finding includes details such as endpoint, parameter, and observed behavior. Reviewers should validate findings in the context of your application logic before treating them as definitive issues.

Related Pages

Tool abuse audit — API securityTool abuse audit: what to check, how to automate it, and how middleBrick covers it.Vendor risk assessment — API securityVendor risk assessment: what to check, how to automate it, and how middleBrick covers it.Webhook receiver hardening — API securityWebhook receiver hardening: what to check, how to automate it, and how middleBrick covers it.