Dual-Tenant Verification and 404 Anti-Enumeration Oracles in AI-Generated APIs

#173

Key Takeaways

AI coding assistants routinely introduce single-tenant fixture bias by generating database queries that fetch records by primary key alone while validating those endpoints under a single mock user who owns the data. Testers must verify multi-tenant APIs using a dual-tenant verification harness with provenance independence, cross-tenant execution across GET, PUT, PATCH, and DELETE, and out-of-band database state assertions. Unauthorized cross-tenant requests must fail closed with an HTTP 404 Not Found rather than an HTTP 403 Forbidden to prevent object ID enumeration.

Read Today’s Notes

AI code generation tools frequently introduce Broken Object-Level Authorization (BOLA) defects alongside passing automated test suites due to single-tenant fixture bias. When generating backend features, models build database queries that retrieve or update records by primary key alone without verifying tenant ownership. The accompanying AI-generated tests create and query objects under a single mock user session, causing all assertions to pass because the caller owns the target data. Static analysis and linters do not flag these queries because looking up a record by ID contains no syntactic defect.

Common testing blind spots in multi-tenant authorization include:

  • Single-tenant fixture bias: Test suites rarely provision two separate organizations to test whether Tenant B can read or mutate Tenant A’s resources.
  • The HTTP 403 enumeration trap: Expecting an HTTP 403 Forbidden on unauthorized cross-tenant access confirms to an external caller that the targeted object ID exists in another tenant’s workspace. Cross-tenant requests must fail closed with an HTTP 404 Not Found.
  • Reliance on UUID obscurity: Treating 128-bit identifiers as access controls fails because object IDs routinely leak through logs, webhooks, browser history, and referer headers.
  • Service-role key bypasses: AI-generated export routes, such as project export endpoints, often drop down to administrative service-role keys to handle complex joins, bypassing database row-level security (RLS) policies.

The Dual-Tenant Verification Harness addresses these gaps through three automated gates:

  • Gate 1 (Dual-Tenant Provisioning with Provenance Independence): The test runner provisions two strictly isolated tenants (Tenant Alpha and Tenant Beta) with separate session tokens and clean database boundaries. Research on black-box authorization detection across 64,400 requests by Siqi Lin, Qianheng Cheng, and Yiping Mao demonstrated that removing provenance independence and evidence quarantine caused authorization state pollution to rise from 0% to 100%.
  • Gate 2 (Cross-Tenant Execution Matrix): Every endpoint accepting an object ID executes Tenant Beta’s token against Tenant Alpha’s resources across GET, PUT, PATCH, and DELETE, asserting an HTTP 404 Not Found. Benchmark research from VibeEval on the Gapbench platform identified invoice endpoints as the primary target for BOLA vulnerabilities in AI-generated CRUD code, with PUT and PATCH carrying the highest mutation risks.
  • Gate 3 (Out-of-Band Mutation Verification): Following a cross-tenant mutation request, the test runner queries the database directly via an out-of-band connection to verify that zero rows changed, regardless of the returned HTTP status code. In CVE-2026-125752, the UpdateCouponStatus gRPC handler in Meteroid versions prior to 2.2.0 updated coupons by ID without scoping by tenant ownership, enabling authenticated users to modify foreign coupon statuses and read back coupon details.

Companion Newsletter

Automated test suites can report 100% green execution while leaving cross-tenant data leaks open in production. This failure occurs when test suites mirror the same architectural blind spot as the application code: single-tenant fixture bias. When an AI coding assistant scaffolds a CRUD endpoint, it typically queries the database by primary key alone. When it writes the corresponding integration test, it authenticates as a single mock user, creates a record, and queries that same record back. Because caller and owner are identical in the test fixture, missing tenant ownership checks remain invisible to both the test runner and static linters.

For QA engineers and technical practitioners, validating multi-tenant isolation requires shifting from single-user happy paths to cross-identity boundary enforcement. A secure multi-tenant endpoint must not only block unauthorized data access and mutation, but also prevent resource enumeration. If an endpoint returns an HTTP 403 Forbidden when Tenant B requests Tenant A’s resource ID, the API leaks the existence of that record. Enforcing an HTTP 404 Not Found oracle ensures that unauthorized cross-tenant probes are indistinguishable from requests for non-existent IDs. Furthermore, testers cannot rely on database row-level security assumptions alone, as complex AI-generated routes like project exports frequently invoke administrative service-role keys that bypass RLS entirely.

Testers can validate their own API test suites today by applying the Operator Move and the 5-Day Dual-Tenant Drill:

  • Audit an existing API integration test: Locate a test file that runs assertions under a single authenticated user session and add a second isolated tenant session helper.
  • Execute cross-tenant read and mutation probes: Have Tenant A create an entity, then send a GET request and a PATCH request against that entity ID using Tenant B’s token. Assert that both responses return an HTTP 404 Not Found rather than an HTTP 200 or an HTTP 403.
  • Verify database state out-of-band: Query the database directly after cross-tenant PUT, PATCH, or DELETE attempts to confirm that underlying records remain unmodified, guarding against handlers that mutate state before returning an error or leaking data as seen in Meteroid CVE-2026-125752.
  • Run the 5-day dual-tenant drill: Catalog all ID-based endpoints, scaffold reusable dual-tenant fixtures with strict provenance independence, implement cross-tenant read tests on high-risk routes such as invoice endpoints, add mutation tests with direct database state assertions, and enforce the suite as a blocking CI release gate.

Research and References

More posts