42Crunch for Restify

The scanner operates as a black-box solution with no agents, no SDKs, and no code access. It submits requests against a target API and observes responses. For Restify, you submit the URL of your running service or its OpenAPI definition; the scanner parses OpenAPI 3.0, 3.1, and Swagger 2.0 with recursive $ref resolution and cross-references spec definitions against runtime behavior.

For Restify, this means the tool maps declared security schemes and endpoints against observed behavior, highlighting undefined security schemes, deprecated operations, and missing pagination. The scanner limits itself to read-only methods (GET and HEAD) plus text-only POST for LLM probes, ensuring no changes to your Restify state during assessment.

OpenAPI analysis exposes gaps such as missing operation IDs, ambiguous parameter definitions, and security misalignment with your Restify middleware stack. You can validate that documented authentication expectations match runtime requirements without requiring source code or build integrations.

Authentication findings map directly to OWASP API Top 10 and cover multi-method bypasses, JWT misconfigurations such as alg=none, HS256 usage, expired tokens, missing claims, and sensitive data in claims. The scanner also evaluates security headers and WWW-Authenticate compliance relevant to any framework, including Restify.

For Restify deployments, the tool checks whether authentication middleware is consistently applied and whether tokens are exposed through logs or error messages. It inspects how authorization is enforced across routes and flags paths where role or permission fields leak, which can enable BFLA or privilege escalation scenarios.

Authenticated scanning (Starter tier and above) supports Bearer, API key, Basic auth, and Cookie methods. Domain verification is required, and the scanner only forwards a strict allowlist of headers, ensuring your Restify auth middleware is tested under controlled conditions.

When you use authenticated scans, the tool correlates route-level definitions with observed responses to surface authorization issues such as IDOR and BOLA, aligned with the principle of least privilege as interpreted in API security contexts.

The scanner checks input validation issues such as CORS wildcard configurations (with and without credentials), dangerous HTTP methods, and debug endpoints that may remain in production Restify services. These findings align with security controls described in OWASP API Top 10 and help you prepare for secure API gateway configurations.

Rate limiting and resource consumption detection include rate-limit header identification, oversized responses, and unpaginated arrays that can lead to denial of service. For Restify, this is relevant when middleware is not consistently enforcing limits across routes or when responses expose excessive data.

Data exposure checks identify PII patterns, including email addresses, Luhn-validated card numbers, context-aware SSN formats, and API key formats such as AWS, Stripe, GitHub, and Slack. Error and stack-trace leakage is flagged, helping reduce noise in logs produced by Restify error handlers.

Encryption checks verify HTTPS redirects, HSTS presence, cookie flags, and mixed content issues. These findings support audit evidence for security controls and help ensure transport protections are consistently applied across your API surface.

Server-side request forgery detection covers URL-accepting parameters and body fields, internal IP detection, and active IP-bypass probes. For Restify, this is important when endpoints construct upstream calls or integrate with internal services, as SSRF risks often depend on framework-specific URL handling logic.

Inventory management findings highlight missing versioning, legacy path patterns, and server fingerprinting that may reveal implementation details. These results can help you refine your Restify routing strategy and reduce information leakage in error responses.

Unsafe consumption detection surfaces excessive third-party URLs, webhook, and callback surfaces that could introduce supply chain or outbound trust risks. The scanner does not perform intrusive payloads or active SQL injection testing, as those fall outside its read-only scope.

LLM and AI security probes are included in deeper scan tiers, with adversarial checks across system prompt extraction, instruction override, jailbreak attempts, and token smuggling. These tests are designed to surface prompt-injection risks without executing destructive actions against your service.

middleBrick is a scanner and does not fix, patch, block, or remediate. It provides prioritized findings with remediation guidance, but business logic vulnerabilities require domain expertise and manual review. The tool does not perform active SQL injection or command injection testing, nor does it detect blind SSRF that requires out-of-band infrastructure.

For ongoing assurance, Pro tier features include scheduled rescans every six hours, daily, weekly, or monthly, with diff detection across scans to highlight new findings, resolved findings, and score drift. Email alerts are rate-limited to one per hour per API, and HMAC-SHA256 signed webhooks can notify external systems, auto-disabling after five consecutive failures.

Compliance framing is limited to mappings that help you prepare for or align with security controls described in frameworks such as PCI-DSS 4.0, SOC 2 Type II, and OWASP API Top 10 (2023). The tool does not certify compliance, meet requirements, or guarantee alignment with HIPAA, GDPR, ISO 27001, NIST, CCPA, or other regulations.

Data handling follows a strict privacy posture: customer scan data is deletable on demand and purged within 30 days of cancellation. It is never sold and never used for model training, ensuring that your API security assessments remain under your control.