The 12 Security Checks

middleBrick runs 12 security checks in parallel, covering the OWASP API Security Top 10 and beyond. Each category contributes a weighted portion to your overall score.

Every check produces findings with severity levels (critical, high, medium, low, info) and remediation guidance. Categories are listed below in approximate order of risk weight.

1. Authentication

Verifies that authentication is properly enforced across all HTTP methods and endpoints.

What it detects:

Endpoints responding with data when no credentials are provided
Auth bypass scenarios where some HTTP methods (e.g., POST) succeed without credentials while others (e.g., GET) require auth
JWT issues: insecure algorithm configurations, expired tokens still accepted, sensitive data embedded in token claims
Missing security headers (HSTS, X-Content-Type-Options, X-Frame-Options)
Security schemes defined in your OpenAPI spec but not enforced at runtime

Why it matters: Authentication is the first line of defense. If an attacker can access your API without credentials, every other security measure is irrelevant. Auth bypass is the single most common critical finding in middleBrick scans.

How to fix: Enforce authentication on all endpoints and HTTP methods. Use a middleware or gateway-level auth check so individual routes can’t accidentally skip it. Validate JWTs properly on every request — check algorithm, expiration, and issuer.

2. BOLA / IDOR

Detects Broken Object Level Authorization, where an attacker can access other users’ resources by manipulating object identifiers.

What it detects:

Sequential or predictable numeric IDs in URL paths and query strings
Confirmed IDOR: when changing an ID returns different data without re-authentication, with schema-based confidence scoring
Path traversal bypass attempts on object identifiers
Path parameters in your OpenAPI spec that lack security requirements (consolidated per-endpoint)

Why it matters: BOLA has been the #1 vulnerability in OWASP API Security Top 10 since its inception. Attackers iterate through IDs to scrape data belonging to other users. It’s trivially exploitable and often leaks sensitive information at scale.

How to fix: Use UUIDs or non-sequential identifiers. More importantly, implement object-level access checks — every request should verify that the authenticated user is authorized to access the specific resource they’re requesting, not just that they’re logged in.

3. BFLA / Privilege Escalation

Checks for Broken Function Level Authorization and whether privileged operations are properly restricted.

What it detects:

Admin and management endpoints accessible without elevated credentials
Configuration and system endpoints that return data when they should return 403 or 404
Spec-defined admin operations missing security requirements (consolidated into a single finding per scan)

Why it matters: An attacker who can access admin functionality can modify system configuration, read all user data, or escalate their privileges. Many APIs separate user-facing and admin routes but forget to enforce authorization on the admin side.

How to fix: Never rely on obscurity (hidden URLs) for admin protection. Implement role-based access control (RBAC) and verify the user’s role on every privileged operation. Return 404 (not 403) for unauthorized admin access to avoid confirming the endpoint exists.

4. Property Authorization

Identifies excessive data exposure in API responses, a common and underestimated vulnerability.

What it detects:

Over-exposed responses returning far more fields than the client needs
Internal properties leaking to clients (fields intended for internal use)
Sensitive fields in responses (password hashes, roles, internal IDs, admin flags)
Mass assignment risks: writable sensitive fields identified in your OpenAPI spec

Why it matters: APIs often return entire database objects instead of curated views. This leaks internal implementation details, user roles, and sensitive data that clients never need. Mass assignment lets attackers modify fields they shouldn’t have access to (e.g., setting is_admin: true).

How to fix: Return only the fields each client needs — implement response serializers or DTOs. Never expose internal fields or sensitive attributes. For mass assignment, use an allowlist of writable fields rather than accepting everything the client sends.

5. Input Validation

Tests for dangerous configurations that allow attackers to inject content or bypass security boundaries.

What it detects:

CORS wildcard (*) combined with credentials, allowing any website to make authenticated requests to your API
Missing Content-Type validation — enables content-type confusion attacks
Unsafe HTTP methods exposed (TRACE, DELETE, PATCH available when they shouldn’t be)
Debug and diagnostic endpoints accessible in production

Why it matters: A CORS misconfiguration with credentials is a critical vulnerability — it lets any website make authenticated API requests on behalf of your users. Debug endpoints in production leak configuration, environment variables, and internal state.

How to fix: Configure CORS with an explicit allowlist of origins, never wildcard with credentials. Disable unused HTTP methods. Remove or firewall debug/diagnostic endpoints before deploying to production.

6. Rate Limiting

Verifies that your API enforces request throttling and bounds response sizes.

What it detects:

No rate limiting: repeated requests all succeed without throttling
Missing rate-limit headers (X-RateLimit-Limit, X-RateLimit-Remaining)
Unbounded responses with large payloads and no pagination
Spec-defined list endpoints missing pagination parameters

Why it matters: Without rate limiting, attackers can brute-force credentials, scrape all your data, or run denial-of-service attacks at minimal cost. Large unbounded responses waste bandwidth and can be used for data extraction.

How to fix: Implement rate limiting at the API gateway or middleware level. Return 429 Too Many Requests when limits are exceeded. Add pagination to all list endpoints. Set reasonable page size limits (e.g., max 100 items).

7. Data Exposure

Scans API responses for sensitive data that shouldn’t be returned.

What it detects:

Personally identifiable information (PII): emails, phone numbers, financial data, government IDs
Credential material: API keys, tokens, secrets in response bodies
Error information leakage: SQL exceptions, stack traces, internal paths, debug output
Sensitive field names in JSON responses that suggest data handling issues

Why it matters: Data exposure is the direct cause of most API-related breaches. Even if your API requires authentication, returning sensitive data unnecessarily increases your blast radius if (when) a credential is compromised.

How to fix: Audit every field in your API responses — remove anything the client doesn’t strictly need. Never return full error details in production — log them server-side and return generic error messages. Mask or truncate sensitive values (e.g., show only last 4 digits of a card number).

8. Encryption

Checks transport-layer security to ensure data in transit is protected.

What it detects:

HTTP without HTTPS redirect, meaning data is transmitted in plaintext
Weak HSTS configuration (short max-age, missing from responses)
Cookies without Secure, HttpOnly, or SameSite flags
Mixed content: HTTP URLs embedded in HTTPS response bodies

Why it matters: Without proper transport security, attackers on the network path can intercept and modify API traffic (man-in-the-middle attacks). This is especially critical for APIs handling credentials, PII, or financial data.

How to fix: Enforce HTTPS everywhere — redirect HTTP to HTTPS at the infrastructure level. Set HSTS with a long max-age (at least 1 year) and include subdomains. Set Secure, HttpOnly, and SameSite flags on all cookies. Audit response bodies for hardcoded HTTP URLs.

9. SSRF

Detects Server-Side Request Forgery risks, where an attacker can make your server send requests to internal systems.

What it detects:

Parameters that accept URLs or redirect targets (potential injection points)
Internal network addresses appearing in responses (indicating internal infrastructure exposure)
Open redirect vulnerabilities
Spec-defined parameters suggesting URL handling

Why it matters: SSRF lets attackers use your server as a proxy to reach internal services, cloud metadata endpoints (like AWS IMDS), and other systems behind your firewall. It’s a common path to cloud credential theft and lateral movement.

How to fix: Validate and sanitize all URL inputs with an allowlist of permitted domains. Block requests to private IP ranges and cloud metadata endpoints. Avoid reflecting user-supplied URLs in responses.

10. Inventory Management

Flags API hygiene issues that reveal too much about your infrastructure.

What it detects:

Missing API versioning (no version in URL or headers)
Legacy, internal, or staging paths still accessible in production
Older API versions responding alongside current ones
Server technology fingerprinting via headers (Server, X-Powered-By)
Deprecated operations still active

Why it matters: Poor API hygiene gives attackers a map of your infrastructure. Legacy endpoints often have weaker security. Version headers and server fingerprints help attackers target known vulnerabilities in your specific stack.

How to fix: Remove legacy and staging endpoints from production. Strip server identification headers (Server, X-Powered-By). Implement API versioning. Disable or redirect deprecated API versions.

11. Unsafe Consumption

Identifies risks from third-party dependencies and external data flow patterns.

What it detects:

Excessive external URLs in response bodies (third-party dependency risk)
Webhook and callback patterns that could be exploited
External redirect chains
Spec-defined webhook endpoint definitions

Why it matters: APIs that consume data from external sources inherit those sources’ security posture. If an external dependency is compromised, your API becomes the delivery mechanism. Webhook endpoints can be manipulated for SSRF or data exfiltration.

How to fix: Minimize external dependencies in API responses. Validate and sanitize webhook callback URLs. Implement request signing for webhook delivery. Monitor and audit external URLs referenced by your API.

12. LLM / AI Security

Three-phase analysis for AI-powered endpoints covering prompt injection, data leakage, and adversarial attacks. The weight of this category adjusts automatically based on whether the endpoint is AI-powered: minimal impact for standard REST APIs, significant for detected LLM endpoints.

What it detects:

System prompt leakage
Prompt injection and jailbreak vulnerabilities
PII and credential leakage in LLM outputs
Unauthenticated AI endpoints
Cost exploitation (missing output limits)
Excessive agent capabilities exposed

Why it matters: LLM-powered APIs introduce an entirely new class of vulnerabilities that traditional scanners don’t detect. A single prompt injection can leak your system prompt (IP), extract training data, or trick the AI into performing unauthorized actions.

See LLM / AI Security for the full three-phase breakdown.