CesarBuilds logo Secure Release Check the fit ↗

● SYNTHETIC LOCAL DEMO · NO CLIENT SYSTEM TESTED

One access boundary.
Nine API checks.

This synthetic demo changes and tests a local HTTP route for one tenant-scoped record lookup. Every user, token and record is fictional. It is not evidence from a client application, a penetration test, certification, or release approval.

WHAT THE EVIDENCE SHOWSThe local Node.js API validates a test-only HMAC-signed bearer token and checks its tenant claim before returning one in-memory record. Nine loopback HTTP integration tests pass; four function-level regression tests also pass. The token format is not a production identity provider. No database or client system was tested.
THE FIXTURETwo fictional tenant records
THE CHECK13 tests · 13 passed
THE ENVIRONMENTNode.js · loopback only

01 · THE EXAMPLE SCOPE FICTIONAL

First, agree on
what’s in bounds.

The demo operation: a local HTTP GET route validates one test-only signed bearer token, then returns a project only when the requested ID and token tenant match.

The fixture: two in-memory records and synthetic token claims for Tenant North and Tenant South; no actual account or customer data.

Not exercised: a real identity provider/session, database or RLS, other roles, deployment, logs, dependencies, production controls, or other application paths.

The HMAC token and signing key exist only for this demo. They are not a production authentication implementation. The tests show one local route's behavior, not that any real app authenticates or enforces the same boundary.

For real work, the asset owner must approve the exact repository/version, environment, test accounts and checks in writing before access or changes.

02 · THE DEMO FINDING LOCAL SYNTHETIC FIXTURE

DEMO-F01 · NO CLIENT SEVERITY

The baseline lookup skipped tenant ownership

The first local function baseline selected by project ID only. In that synthetic fixture, a North principal received the South record; a principal without tenant context also received a record.

LIMITED IMPACT STATEMENT

One toy route was observed

This does not establish an issue in any real application. In a client system, impact would depend on verified identity, data, routes, database policy and all other access paths.

What we’d recordFictional example
PrincipalTest-only signed token claim for `tenant-north`; no auth provider or real credential
Requested record`project-south` with `tenant-south` in memory
Baseline behaviorProject returned when selection compared only project ID
Expected behaviorReturn no record unless both project ID and tenant ID match
BoundaryFunction tests plus one HTTP route on loopback; no database or live app

03 · THE LOCAL CHANGE AND RETEST DEMO ONLY

Match the tenant
before returning a record.

Change made in the demo: fail closed when the demo token is absent, malformed, tampered or expired; derive the fixture tenant from its verified signature; return a record only when both IDs match.

The demo token is a test fixture, not a production identity provider. A real system must derive identity from a properly verified session and enforce the boundary across every relevant route and data layer.

const principal = authenticate(request, signingSecret, now);
if (!principal) return sendJson(response, 401, { error: "unauthorized" });

const project = DEMO_PROJECTS.find(
  (record) => record.id === projectId && record.tenantId === principal.tenantId,
);
if (!project) return sendJson(response, 404, { error: "not_found" });
Local regression checkExpected behaviorResult · Node.js v24.16.0
DEMO-01 · member reads own-tenant projectMatching project returnedPass
DEMO-02 · member requests other-tenant projectNo record returnedPass
DEMO-03 · member requests unknown projectNo record returnedPass
DEMO-04 · tenant context is absentNo record returnedPass
API-01 · North member reads North projectHTTP 200; only requested tenant recordPass
API-02 · North member requests South projectHTTP 404; no cross-tenant recordPass
API-03 · bearer token absentHTTP 401Pass
API-04 · signed tenant claim is changedHTTP 401Pass
API-05 · bearer token is malformedHTTP 401Pass
API-06 · token has expiredHTTP 401Pass
API-07 · project does not existHTTP 404Pass
API-08 · project ID contains an encoded slashHTTP 400Pass
API-09 · unsupported method is usedHTTP 405Pass

Reproducible commands: node --test outputs/secure-release-lab/test/project-access.test.mjs · 4 passed, 0 failed; node --test outputs/secure-release-lab/test/http-tenant-api.test.mjs · 9 passed, 0 failed. The HTTP test server binds to 127.0.0.1 on an ephemeral port. These runs cover only this local synthetic fixture.

04 · WHAT TO TAKE FROM THIS AND WHAT NOT TO

Be clear about the evidence.
Be clear about its limits.

Thirteen local tests do not establish that a real application is secure. This is not a penetration test, independent review, certification, or release approval.

A real report would name the owner-approved scope and commit, separate checked from unchecked paths, record evidence and retest results, and leave the release decision and residual risk with the product owner.

Talk through a release See the one-workflow scope ↗