Backend-for-Frontend (BFF) security

A Backend-for-Frontend layer aggregates data from multiple downstream services and presents a simplified contract to client applications. This consolidation reduces client complexity but introduces a centralized target that exposes authentication, authorization, and data aggregation risks. Because the BFF typically accepts high-trust credentials from clients and forwards them to internal services, misconfigured trust boundaries can lead to privilege escalation, data over-exposure, and IDOR through predictable resource identifiers. The API shape often includes coarse-grained endpoints that return nested data, increasing the risk of sensitive field leakage if field-level authorization is inconsistent. Black-box scanning evaluates these risks without access to source code by observing authentication flows, parameter handling, and response contents to surface insecure patterns and weak security headers.

Using black-box methods, the scanner evaluates endpoints against the OWASP API Top 10 (2023) with explicit mapping to this standard. Detection includes authentication bypass attempts, JWT misconfigurations such as alg=none or missing exp claims, and security header deficiencies including missing or invalid WWW-Authenticate responses. The scanner checks for BOLA and IDOR by probing sequential and adjacent identifiers, and for BFLA by attempting to access admin-only functionality or observing role/permission leakage in responses. Input validation checks include CORS wildcard usage with credentials, dangerous HTTP methods, and debug endpoints. Rate limiting is assessed via the presence and correctness of rate-limit headers and response sizes, while data exposure looks for PII patterns, API key formats, and error or stack-trace leakage. Encryption checks cover HTTPS redirects, HSTS, cookie flags, and mixed content. SSRF probes target URL-accepting parameters and body fields with internal IP detection. Inventory management checks for missing versioning and legacy path patterns, and unsafe consumption reviews third-party URL and webhook/callback surfaces. LLM security is assessed through 18 adversarial probes across Quick, Standard, and Deep tiers, including system prompt extraction, instruction override, DAN and roleplay jailbreaks, data exfiltration, cost exploitation, encoding bypasses, prompt injection variants, token smuggling, tool abuse, nested instruction injection, and PII extraction.

The scanner parses OpenAPI 3.0, 3.1, and Swagger 2.0 documents with recursive $ref resolution to compare the contract against runtime behavior. It flags undefined security schemes, sensitive fields returned without explicit justification, deprecated operations, and missing pagination that can lead to unbounded data exposure. Cross-referencing spec definitions with observed responses helps identify mismatches between documented and actual data returned by the BFF. This process highlights endpoints where authorization is underspecified or where response schemas expose more data than intended. Note that contract analysis complements but does not replace runtime testing; implementation-level logic and trust boundaries must still be verified through black-box probes.

Authenticated scanning at the Starter tier and above supports Bearer, API key, Basic auth, and Cookie credentials. Domain verification is enforced through a DNS TXT record or an HTTP well-known file to ensure only the domain owner can submit authenticated scans. The scanner sends only a limited set of headers, specifically Authorization, X-API-Key, Cookie, and X-Custom-*, and uses read-only methods such as GET and HEAD, with text-only POST reserved for LLM-specific probes. Because destructive payloads are never sent, the approach is non-intrusive and suitable for continuous monitoring. However, business logic flaws that depend on complex workflows or contextual state are outside the scope of automated detection and typically require human review.

The scanner detects and reports findings with prioritized risk scores and remediation guidance, but it does not fix, patch, block, or remediate issues directly. For each finding, guidance outlines how to validate and resolve the issue, such as tightening authorization checks, removing unnecessary fields, or enforcing strict CORS rules. Continuous monitoring in the Pro tier performs scheduled rescans every six hours, daily, weekly, or monthly, and tracks score drift by diffing findings across scans. Email alerts are rate-limited to one per hour per API, and HMAC-SHA256 signed webhooks can notify external systems, with automatic disablement after five consecutive delivery failures. This approach keeps the BFF layer observable over time without introducing false confidence in automated controls.