Skip to main content
Latchform

Application security for product engineering teams.

Latchform reviews the code that controls access to your product: permissions, sessions, integrations, and third-party packages. We trace a request through the application and give your engineers the steps to reproduce what we find.

Vertical Session, Permission, and Resource flow for Tenant A member (active session)200 Allow: Permitted: active Tenant A member is authorized to read Tenant A record ord_tnA_0184.1. SESSIONACTIVETenant A membersid=ses_09f2 · ACTIVE2. PERMISSION200 ALLOWowner(tenant-a) && readTenant A verified · permitted3. TENANT Aord_tnA_0184READ OK3. TENANT Bord_tnB_0912Isolated
  1. 1. Session: Tenant A member (active)Active
  2. 2. Permission: Tenant A verified · permitted200 Allowed
  3. 3. Resource: Tenant A (ord_tnA_0184)read executed
Illustration on sample data. Open interactive lab

What you can commission

Commission a focused review of one boundary before a release or a complete review across all four areas.

All service specifications
Isometric authorization drawing showing a caller identity plane, a vertical policy gate, and separated Tenant A and Tenant B resource vaultsusr_tnAPOLICYowner=ATenant A200 ALLOWTenant B403 DENIED

Authorization reviews

Check whether users can reach another tenant’s records or change data outside their role.

We trace caller identity from HTTP handlers into database queries, bulk endpoints, and background jobs, delivering a route-by-route ownership matrix and reproducible requests for any bypass.

Isometric session drawing comparing a client cookie prism with a 3D server-side session ledger where the middle record is marked revokedCOOKIEses_09f2lookupses_11c8 · expREVOKED401 at gateses_04a1 · active

Session handling

Find out what the server accepts after sign-out, password changes, and account removal.

We replay active, rotated, expired, and revoked credentials against protected endpoints to verify whether access stops immediately on the server or remains open until a token expires.

Isometric integration drawing showing an external webhook source passing through an angled HMAC signature verification screen to an isolated application workerWEBHOOKPOST bodyHMAC-256timestampreplay IDWorkerTenant key

Integration security

Review signature checks, replay handling, and where each customer’s integration credentials are stored.

We inspect raw-body webhook signature verification, timestamp replay windows, and how outbound OAuth tokens and API keys are scoped to their owning tenant in background workers.

Isometric three-stratum dependency drawing narrowing from declared manifest packages to loaded runtime modules and a single reachable route execution path1. DECLAREDparseXml()2. LOADED3. POST /import

Dependency reviews

Trace vulnerable packages into the deployed build and the code paths that use them.

We verify whether a flagged package can be reached by production traffic, evaluate install-time and CI build exposure, and hand over verified lockfile upgrade diffs.

How a review works and what your team receives

Each finding includes the request, test fixture and expected response so your engineers can reproduce it in their own environment.

When teams bring us in

Before launching a multi-tenant sharing or role model, after changing authentication or session handling, when adding webhooks or customer OAuth connections, or when triaging high-severity dependency advisories.

How we scope & access the app

Using your route table and tenant model, we agree on the exact boundaries to inspect. We agree repository access and use a staging environment with isolated test tenants. Production access is outside that arrangement unless separately agreed.

How your engineers reproduce findings

Findings identify the relevant route handler, query or token check and include reproduction steps. Where appropriate, we propose a regression test for your team to run.

Illustrative example · synthetic fixtures

What a delivered finding looks like

An illustrative finding showing the staging request, observed versus expected server behavior, and the query predicate fix with a regression assertion.

Open standalone boundary lab
Illustrative finding · authorization boundary

Missing tenant predicate on order status mutation

src/routes/orders/update.ts:48

1. Request & test fixture

Authenticated as Tenant A administrator (usr_tnA_admin_01) with active session sid=ses_sample_active_09f2 targeting a Tenant B order record.

PATCH /v1/orders/ord_tnB_0912 HTTP/1.1
Host: staging.example.test
Cookie: sid=ses_sample_active_09f2
Content-Type: application/json

{
  "status": "approved"
}
Observed response (200 OK)

Handler verifies the caller has the admin role, then runs UPDATE orders SET status = $1 WHERE id = $2. Tenant B's order ord_tnB_0912 is modified across tenant boundaries.

Expected response (404 / 403)

Update statement scopes by caller tenant: WHERE id = $2 AND tenant_id = $3. Matches zero rows in tnA_sample_01, returns 404 Not Found, and leaves Tenant B's record unchanged.

2. Recommended fix & regression check

Bind the authenticated session's tenantId directly in the mutation predicate and assert cross-tenant rejection in the route test suite:

// src/routes/orders/update.ts
const result = await db.query(
  'UPDATE orders SET status = $1 WHERE id = $2 AND tenant_id = $3 RETURNING id',
  [body.status, params.orderId, session.tenantId]
)
if (result.rowCount === 0) return Response.json({ error: 'Not found' }, { status: 404 })

// tests/orders-authorization.test.ts
expect(res.status).toBe(404)
expect(await getOrderStatus('ord_tnB_0912')).toBe('pending')

What every finding includes

  • HTTP request & fixture: Exact method, path, headers, payload, and synthetic test tenant identity.
  • Observed vs. expected result: The response returned in staging compared against the intended access rule.
  • Code location & fix: File and line reference, query or middleware change, and a runnable regression test.
Interactive model · 24 combinations

Explore the full Boundary lab

Step through all 24 combinations of session state, caller role, target tenant, and operation in the standalone policy simulator.

Open boundary lab

Engineering notes

Technical notes examining how session revocation and dependency reachability behave in application code.

All engineering notes