API authorization.

We designed a deterministic multi-tenant HTTP API and an 18-invariant authorization test suite. The suite covers cross-tenant read/write/delete boundaries, authorization context derived from trusted identities, tenant-scoped collection results, function-level role boundaries, and object-property assignment restrictions. We ran the same cases against one hardened configuration, three individually fault-injected variants, and one combined fault configuration: 90 individual HTTP-level test observations.

The hardened variant satisfied 18/18 invariants. The variants with deliberately removed object checks, role/property checks, or trusted-context enforcement each violated at least four invariants, while the combined fault variant violated 11. This supports a narrow engineering conclusion: this specific invariant suite detects the deliberately injected authorization regressions in the included synthetic application. It does not measure the prevalence of vulnerabilities in production APIs, demonstrate a new zero-day, or prove these fault patterns are exploitable in any third-party product.

Can a small, testable suite of API authorization invariants distinguish a correctly scoped multi-tenant service from services with three common classes of access-control regressions, while preserving positive use cases and anonymous-authentication checks?

This experiment does not ask whether real organizations are vulnerable to these exact bugs; establishing that would require individually authorized assessments of production software and a representative sample.

The synthetic service has two tenants (alpha and beta), multiple document owners and administrators, and five synthetic user identities. It supports document read, edit and deletion; collection listing; an administrator-only users endpoint; and an internal-notes endpoint. All records and bearer tokens are artificial strings. The HTTP server binds only to 127.0.0.1, uses an ephemeral port, and never reaches external systems.

An authenticated caller from alpha is considered adversarial for the purposes of negative tests when attempting to read or alter beta documents, modify a peer's document, elevate access to an administrator-only function, submit protected object properties, or override a tenant attribute through untrusted HTTP inputs. The authenticated caller's original tenant identity remains authoritative in the hardened mode.

We reuse identical seed data and the same set of 18 test cases for all five variants. After every test request, application data is reset to an initial deep copy so that mutations cannot influence another case. Each observation records the HTTP response, expected policy, pass/fail decision, and before/after document state differences.

Test oracles. For negative controls, a request must be denied with the stated status and not modify stored data. For positive write controls, the approved title change must actually occur. For collection read tests, the visible object/user IDs must exactly match the requester's tenant. Status codes chosen in this lab (such as 403 vs. 404) are not mandatory for all real production APIs; implementations should adapt expected responses to their own security policy.

The test harness uses Python's http.client for actual HTTP requests and http.server as the lab target. No third-party modules or Internet access are required.

Aggregate: 90 HTTP observations; 26 violated invariants across the four deliberately insecure variants and zero in the reference configuration. The harness detected all four seeded fault configurations (4/4), but this must not be interpreted as a general detection-rate or accuracy measurement across real-world applications.

Cross-tenant access

In object mode, the test suite identifies cross-tenant reads and cross-tenant modifications/deletion by an administrator of a different tenant (C08–C10). Document listing also leaks foreign records in this mode (C11–C12). The test design intentionally includes a user who is an administrator within the wrong tenant: checking only whether a caller is an administrator does not establish which tenant's records they may modify.

Untrusted tenant selection

In context mode, an alpha user can redirect list behavior by adding an arbitrary tenant query parameter or X-Tenant-ID header (C11–C12). The same untrusted header can redirect access and an administrator's edit to a foreign tenant (C13, C18). In the secure variant, these caller-supplied values do not alter the tenant associated with the authenticated identity. This is a demonstration of a seeded design mistake, not a claim about a proxy or framework's defaults.

Roles & protected properties

In function mode, a member can reach administrator-only endpoints or internal fields and may edit another member's document (C14–C16). A permitted title-edit route also accepts protected fields (tenant, owner, approved) that the hardened implementation rejects (C17). This illustrates why an allowlist of mutable fields and function-level authorization must complement object-level tenant filtering.

Beyond authentication

C06 and C07 reject missing and invalid credentials in every variant. Nonetheless, the object, function and context variants violate multiple authorization invariants after authenticating a valid user. This is a controlled counterexample to treating successful authentication tests as proof of adequate authorization.

1. Derive tenant context from a verified identity, not a caller-controlled query value or a client-supplied header. If a gateway supplies tenant identity, enforce a verifiable trusted boundary and strip spoofable inbound values.
2. Enforce row/object tenant policy on every read, write, delete and list query, not only on entry pages or route groups.
3. Check role and, when applicable, record ownership separately from tenant scope. A role is not a universal cross-tenant authorization.
4. Explicitly allowlist fields for each mutation. Treat ownership, tenant attribution and approval state as protected business-policy fields.
5. Test negative cases with postconditions and collection-content checks; HTTP status alone may miss data exposure or side effects.
6. Preserve positive controls so over-restrictive policies do not masquerade as secure behavior.

python --version
python run_study.py

The runner exits with an error if the reference hardened variant fails any invariant or if a fault-injected variant violates none. Evidence is stored in evidence/results.json (all 90 request observations, including state differences) and evidence/results.csv (compact table). The Python runtime version and UTC experiment timestamp are recorded in JSON; read the source for exact route logic and fixtures.

This experiment was run with Python 3.13.5 in an isolated Linux container. It uses only the standard library. Different supported Python versions are checked by the included GitHub Actions configuration once the repository is publicly hosted and CI is enabled.

• Synthetic application: the examined targets are deliberate test fixtures, not independent production deployments. The study says nothing about the frequency or impact of vulnerabilities outside this lab.
• Fault selection: all vulnerabilities were planted by the study author. Catching four planned variants does not establish discovery performance for unknown bug classes, and invariant failures overlap across variants.
• Scale and adversarial realism: this is a small deterministic scenario, not a broad fuzzing campaign, distributed system, database-backed SaaS product, reverse proxy, or full adversarial red-team exercise.
• Security outcome: zero failures in the hardened case only means it passes the 18 specified tests, not that it is free of security defects.
• External verification: a public release with signed/attributed source, CI, and an independently repeated run would strengthen confidence. A real-world validation against an authorized, versioned owned application would substantially strengthen the evidence.

1. OWASP, API Security Top 10 — 2023.
2. OWASP, API1:2023 Broken Object Level Authorization.
3. OWASP, API5:2023 Broken Function Level Authorization.
4. OWASP WSTG, API Broken Object Level Authorization.