Your JWT Is Valid and Your API Is Still Vulnerable

I have seen this demo many times. The React app has a polished login screen. The identity provider redirects back. A JWT appears. The dashboard loads. Everybody relaxes because the padlock icon has entered the meeting.

Then I change /projects/alice-1 to /projects/bob-1. The API returns Bob's project. Login was perfect. Authorization was on holiday.

This is Broken Object Level Authorization, usually shortened to BOLA. Many developers also know the same family of bugs as IDOR. It is especially easy to generate with AI because the endpoint looks complete: authentication, a scope check, validation, a database query, and a nice JSON response. Every requested feature is there. The missing feature is the one the prompt did not name.

The working endpoint that is not safe

// The login works. The token is valid. The scope is valid.
// The endpoint is still vulnerable.
app.get(
  "/projects/:id",
  {
    hooks: requireAuth("projects:read"),
    request: { params: z.object({ id: z.string() }).strict() },
    responses: { 200: { description: "Project", body: ProjectResponse } },
  },
  async ({ params, state }) => {
    return state.projects.findById(params.id);
  },
);

// Alice calls /projects/alice-1  -> 200
// Alice calls /projects/bob-1    -> also 200
//
// Authentication passed both times. That is exactly the problem.

The route answers one question correctly: may this caller use the project-reading function? It never answers the next question: may this caller read this specific project?

Three layers, three different jobs

Function-level authorization is usually a scope or role. It decides whether the caller may attempt an operation such as reading projects or refunding an order.

Object-level authorization connects the principal to one record. It decides whether Alice may read project 42, not whether Alice may read projects in general.

Property-level authorization decides which fields the caller may read or change. A project owner may rename a project without being allowed to set ownerId, tenantId, approvedAt, or role. Giving someone the Edit button does not mean handing them the database row and a pen.

Normalize identity once

The solution should not depend on one identity vendor. Auth0, Cognito, Entra ID, Clerk, Keycloak, Zitadel, Ory, or a signed session can all produce the same application principal:

// Every identity provider or session adapter ends here.
// Business code below this boundary stays provider-neutral.
export interface Principal {
  userId: string;               // immutable internal application id
  issuer: string;               // who authenticated the caller
  subject: string;              // provider subject within that issuer
  tenantId?: string;            // trusted application tenant
  permissions: readonly string[];
}

declare module "@daloyjs/core" {
  interface AppState {
    principal?: Principal;
  }
}

Map the pair (issuer, subject) to one immutable application user ID. Do not use email as your ownership key. Email is contact information wearing a fake moustache and pretending to be a primary key.

Put ownership into the data operation

The safest repository is one that makes owner-scoped operations boring and obvious. This interface works with any ORM, SQL builder, document database, key-value store, or in-memory test double:

// Make the safe operation the obvious operation.
export interface ProjectRepository {
  listForOwner(ownerId: string, tenantId?: string): Promise<Project[]>;
  findForOwner(
    id: string,
    ownerId: string,
    tenantId?: string,
  ): Promise<Project | null>;
  updateForOwner(
    id: string,
    ownerId: string,
    patch: ProjectPatch,
    tenantId?: string,
  ): Promise<Project | null>;
  deleteForOwner(
    id: string,
    ownerId: string,
    tenantId?: string,
  ): Promise<boolean>;
}

A real implementation should combine the resource ID and trusted owner or tenant in the same database query. Avoid loading by ID, checking in application code, then mutating by ID in a separate operation. That pattern is easy to weaken during refactoring and can create a time-of-check to time-of-use gap.

app.get(
  "/projects/:id",
  {
    hooks: requireAuth("projects:read"),
    request: {
      params: z.object({ id: z.string().min(1) }).strict(),
    },
    responses: {
      200: { description: "Project", body: ProjectResponse },
      404: { description: "Not found or not accessible" },
    },
  },
  async ({ params, state }) => {
    const principal = state.principal!;
    const project = await state.projects.findForOwner(
      params.id,
      principal.userId,
      principal.tenantId,
    );

    if (!project) throw new NotFoundError("Project not found");
    return { status: 200, body: toProjectResponse(project) };
  },
);

Return the same 404 for a missing project and a project owned by somebody else when revealing existence would be sensitive. A 403can tell Alice that Bob's secret project ID is real. Sometimes that disclosure is acceptable. It should be a decision, not an accident.

The client does not choose ownership

Creation endpoints have a second common problem: mass assignment. The AI passes the whole request body to the ORM, so a helpful caller includes ownerId, role, or isApproved. Very efficient. The attacker appreciates the developer experience.

const CreateProjectBody = z
  .object({
    name: z.string().min(1).max(120),
    description: z.string().max(2_000).nullable().optional(),
  })
  .strict();

// ownerId, tenantId, role, and approvedAt are not accepted.
// The client describes the project. The principal decides who owns it.
const project = await state.projects.createForOwner(
  state.principal!.userId,
  body,
  state.principal!.tenantId,
);

Strict request schemas reject privileged fields. Response schemas perform the other half of the job by preventing internal flags, deleted records, billing metadata, or credentials from leaving the API.

One-user tests cannot prove isolation

A happy-path test proves Alice can use the product. It says nothing about Bob's data. Every user-owned or tenant-owned resource needs at least two principals in the test suite.

test("Alice cannot read Bob's project", async () => {
  const response = await app.request("/projects/bob-1", {
    headers: { authorization: "Bearer alice-token" },
  });

  assert.equal(response.status, 404);
});

test("Alice cannot assign a project to Bob", async () => {
  const response = await app.request("/projects", {
    method: "POST",
    headers: {
      authorization: "Bearer alice-token",
      "content-type": "application/json",
    },
    body: JSON.stringify({
      name: "Definitely normal project",
      ownerId: "user-bob",
    }),
  });

  assert.equal(response.status, 422);
});

Repeat the same idea for list, update, and delete operations. Add a cross-tenant case when the product has organizations. Add an explicit admin case when support staff need access, and verify that the bypass creates an audit event.

Why AI keeps generating this bug

Business owners ask for login because login is visible. They ask for CRUD because CRUD is visible. They rarely ask for object-level authorization because they do not know the term, and they should not need an application-security vocabulary to request a normal product.

The coding agent optimizes for the prompt. It reaches the happy path, sees a valid token, and moves on. A bigger pile of tutorials does not automatically help if those tutorials also stop at "add JWT middleware, job done."

This rule belongs in framework documentation, executable tutorials, project scaffolds, AI instructions, and tests. Repeating it is not glamorous, but neither is explaining a cross-customer data leak to every customer at once.

When a route accepts a resource identifier:

1. Classify the resource as public, user-owned, tenant-owned, shared,
   or administrator-only.
2. Check the operation permission.
3. Constrain the data read or write with the resource id AND the trusted
   owner or tenant from the verified principal.
4. Never accept ownership or privileged fields from an ordinary body.
5. Add two principals and prove that Alice cannot access Bob's record.
6. Make administrator bypasses explicit, permissioned, and audited.

Do not treat successful authentication as resource authorization.

What the framework can and cannot do

DaloyJS can verify identity, enforce scopes, validate identifiers, reject unexpected properties, validate response bodies, redact production errors, and carry a typed principal into the handler. It cannot know whether an invoice belongs to a user, an organization, both, or neither. That is business policy.

The framework can still make the policy difficult to forget. The official guidance now classifies identifier routes, favors owner-scoped repository operations, rejects client-selected ownership, and requires Alice-versus-Bob tests in generated agent instructions.

A short note about Django, TypeScript, and hiring

I would not reject Django because it is old. Mature software is not a yoghurt with an expiry date. Django's integrated security features are useful.

I would still choose a TypeScript backend when the available team already builds React and TypeScript every day, or when hiring for that stack is materially easier for the business. Sharing language, types, generated clients, and mental models across the frontend and backend is a legitimate operational advantage.

That staffing decision is not a security control. React developers do not receive object-level authorization through osmosis. Choose the stack your team can maintain, then make the authorization policy structural in that stack.

The takeaway

A valid JWT proves that the identity provider recognizes the caller. A scope proves that the caller may attempt an operation. Neither proves ownership of the ID in the URL.

Scope every user-owned and tenant-owned data operation using trusted principal data. Reject privileged ownership fields. Test with two users. Make admin bypasses explicit and audited. If Alice can change one character in a URL and become Bob, the login screen was only expensive decoration.

Read the complete resource authorization guide and build the multi-user projects tutorial. The tutorial includes the attack tests, because an authorization guide without an attacker is just optimistic documentation.