The Node.js Shortcut That Quietly Created a Security Hole

We verified who made the request, but never verified whether that user was allowed to access the requested resource.

The endpoint rejected unauthenticated requests, so we assumed it was secure.

It was not.

The route had authentication middleware. Invalid tokens returned 401. Expired sessions were rejected. The controller received a verified user.

Everything looked protected.

But an authenticated user could change the resource ID in the URL and access data belonging to another account.

Authentication worked exactly as expected.

Authorization was missing.

That difference came down to one condition in a database query, but in the application’s security model, it was the entire boundary.

The Route Looked Secure

The route looked like a normal protected Node.js endpoint:

router.get(
  "/documents/:documentId",
  validateAccessToken,
  attachCurrentUser,
  getDocument
);

The middleware performed all the expected work:

• verified the access token
• rejected invalid sessions
• loaded the current user
• attached the user to the request

The controller only ran after authentication succeeded.

That created a dangerous assumption:

Authenticated request = trusted request

But authenticated users should not automatically be trusted with every resource in the application.

A logged-in customer should not be able to read another customer’s invoice.

A member of one organization should not be able to access another organization’s projects.

A normal employee should not be able to approve an administrative request.

A project viewer may be allowed to read a project but not delete it.

Authentication answers one question:

Who is making this request?

Authorization answers another:

Is this user allowed to perform this action on this resource?

Identity is only an input to the authorization decision.

It is not the decision itself.

The Shortcut Was Loading Records by ID Alone

The controller accepted a resource ID from the URL:

async function getDocument(request, response) {
  const document = await documentService.findById(
    request.params.documentId
  );

  return response.json(document);
}

The service then loaded the record using only that ID:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
  },
});

This code looked clean.

It was easy to read.

It also asked the wrong question.

The query asked:

Does a document with this ID exist?

It did not ask:

Does this document belong to the current user or account?

The database had no knowledge of the security boundary.

For an account-scoped application, the query should include the account:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
    accountId: currentUser.accountId,
  },
});

For user-owned resources, it might include ownerId:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
    ownerId: currentUser.id,
  },
});

For a multi-tenant system, it might include tenantId:

const document = await documentRepository.findOne({
  where: {
    id: documentId,
    tenantId: currentUser.tenantId,
  },
});

This is not just another database condition.

It changes the meaning of the operation.

The unsafe version means:

Find this document.

The scoped version means:

Find this document inside the boundary this user is allowed to access.

The database query should understand the security boundary, not only the resource identifier.

Why a Valid Token Made the Bug Harder to Notice

Most authentication tests verify that anonymous users are rejected:

it("rejects requests without a token", async () => {
  await request(app)
    .get("/documents/123")
    .expect(401);
});

This is useful, but it only proves that unauthenticated users cannot access the endpoint.

A positive test may verify that the owner can access the document:

it("allows the owner to access the document", async () => {
  const user = await createUser();

  const document = await createDocument({
    ownerId: user.id,
  });

  await request(app)
    .get(`/documents/${document.id}`)
    .set("Authorization", createToken(user))
    .expect(200);
});

This test also passes.

The missing scenario is the one that exposes the vulnerability:

• a real user
• a valid token
• a real resource
• the wrong owner

it("does not expose another user's document", async () => {
  const owner = await createUser();
  const otherUser = await createUser();

  const document = await createDocument({
    ownerId: owner.id,
  });

  await request(app)
    .get(`/documents/${document.id}`)
    .set("Authorization", createToken(otherUser))
    .expect(404);
});

The most valuable security test often uses a valid token belonging to the wrong user.

This type of bug can also survive code review because authentication and data access usually live in different layers:

Route
  → Middleware
    → Controller
      → Service
        → Repository

A reviewer sees the authentication middleware in the route file.

Another reviewer sees a simple findById method in the repository.

Each piece looks reasonable in isolation.

The vulnerability appears only when the complete request path is examined.

The route proves identity.

The controller accepts a client-controlled identifier.

The repository loads the resource without ownership or tenant scoping.

The response returns the result.

Each file looked secure on its own.

The security hole existed between them.

UUIDs Did Not Fix the Authorization Problem

A common response to this vulnerability is to replace sequential IDs with UUIDs.

Sequential IDs are easy to guess:

/documents/1001
/documents/1002
/documents/1003

UUIDs are much harder to enumerate:

/documents/f9a81862-0db8-4f61-b7ea-9a74d97d71b4

That can reduce predictable resource discovery.

It does not create permission.

A user may still obtain a valid identifier through:

• a copied URL
• browser history
• logs
• analytics
• notifications
• support tickets
• screenshots
• frontend state
• another API response
• another vulnerable endpoint

When authorization is missing, possession of the identifier becomes possession of the resource.

That is not a safe access model.

A resource ID identifies an object.

It does not grant permission to access it.

A UUID can hide the door, but it cannot replace the lock.

The Same Shortcut Affected More Than Read Endpoints

Once a service exposes a generic method like this:

findById(id: string)

it often becomes the default lookup for several endpoints:

GET    /documents/:id
PATCH  /documents/:id
DELETE /documents/:id
POST   /documents/:id/share
POST   /documents/:id/archive

The missing boundary may allow another authenticated user to:

• read private data
• update records
• delete content
• download attachments
• resend invitations
• trigger workflows
• change ownership
• modify billing information
• approve restricted actions

Authorization also depends on the requested action.

A user may be allowed to read a project but not delete it.

An editor may update a draft but not publish it.

A manager may approve expenses only below a specific amount.

A support agent may view customer details but not change payment information.

A better authorization model is:

User + Action + Resource + Context = Authorization decision

Not:

Valid token = Permission granted

Nested Routes Can Create False Confidence

Nested URLs often look naturally secure:

/projects/:projectId/comments/:commentId

The route appears to say that the comment belongs to the project.

But the URL does not enforce that relationship.

A controller may verify access to the project and then load the comment using only commentId:

const comment = await commentRepository.findOne({
  where: {
    id: commentId,
  },
});

That comment could belong to another project.

The query should verify both identifiers:

const comment = await commentRepository.findOne({
  where: {
    id: commentId,
    projectId,
  },
});

The project itself must also exist inside the user’s permitted organization, account, or tenant.

A nested URL does not prove the relationship.

The data-access layer must enforce it.

The Real Fix Was Architectural

The fastest fix may be a manual ownership check:

if (document.ownerId !== currentUser.id) {
  throw new ForbiddenError();
}

That is better than no authorization.

But repeating checks manually across controllers creates another problem.

Eventually:

• one endpoint forgets the check
• one endpoint checks ownership but not tenancy
• one endpoint applies a different role rule
• one endpoint loads sensitive data before rejecting the request
• one endpoint handles administrators globally instead of per organization

Authorization becomes duplicated business logic.

Duplicated security logic eventually becomes inconsistent security logic.

The stronger approach is to make authorization part of the resource-access design.

Option 1: Scoped repository methods

For simple ownership or account rules, use methods that require the security boundary:

async function findAccountDocument(
  documentId: string,
  accountId: string
) {
  return documentRepository.findOne({
    where: {
      id: documentId,
      accountId,
    },
  });
}

The method does not provide an easy way to load a document outside the current account.

Option 2: Explicit policy services

More complex permissions may need a dedicated authorization policy:

const document = await documentService.findById(documentId);

authorizationService.assertCanReadDocument({
  user: currentUser,
  document,
});

This is useful when access depends on:

• ownership
• roles
• team membership
• organization membership
• resource state
• sharing rules
• subscription level
• administrative scope

Option 3: Framework guards

In NestJS, guards can handle authentication and high-level role checks.

However, a generic role guard may not have enough information to make a resource-level decision.

Knowing that a user has the role manager does not prove that the user manages the organization that owns the requested document.

Role authorization and resource authorization often need to work together.

Option 4: Database-level isolation

Some applications use tenant-aware database clients or row-level security.

This adds another layer of protection when application code forgets a filter.

It can be powerful, but it also adds complexity. Policies must be observable, testable, and understood by the team.

There is no single authorization design for every application.

The important requirement is this:

The security boundary should be explicit, reusable, testable, and difficult to bypass accidentally.

The safest authorization check is the one the application cannot easily forget to perform.

Test Security Boundaries, Not Only Endpoints

After finding this bug, the test strategy should change.

Do not only test whether the endpoint works.

Test which identities can perform which actions.

A useful authorization matrix might look like this:

Scenario	Expected result
No token	401
Invalid token	401
Owner with valid token	Success
Different user with valid token	Rejected
User from another tenant	Rejected
User with insufficient role	Rejected
Viewer attempting deletion	Rejected
Administrator inside allowed scope	Success

Test more than reads:

• create
• read
• update
• delete
• download
• share
• approve
• archive
• transfer ownership

For multi-tenant systems, create at least two tenant contexts:

Tenant A user → Tenant A resource → Allowed
Tenant A user → Tenant B resource → Rejected

For nested resources, intentionally mix identifiers:

Project A ID
+
Comment from Project B
=
Rejected

Applications should also decide whether unauthorized resource requests return 403 or 404.

A 403 response confirms that the resource exists but access is forbidden.

A 404 response can avoid revealing whether a protected resource exists.

The right choice depends on the API contract and threat model.

What matters is that the behavior is deliberate and consistent.

Partial Protection Is Still a Security Failure

The shortcut did not look reckless.

It looked like ordinary controller and repository code behind an authenticated route.

That was why it survived.

The token was valid.

The current user was known.

Anonymous requests were rejected.

The endpoint was still unsafe because the requested resource had no enforced ownership, tenant, role, or permission boundary.

The lasting fix was not a stronger token, a longer identifier, or another scattered condition.

It was making authorization part of the resource-access model and testing the application with valid users who should still be denied.

Security failures often survive because partial protection is mistaken for complete protection.

A valid token should open the application.

It should never open every record inside it.

Which authorization boundary is easiest to miss in your APIs: ownership, roles, tenant isolation, or action-specific permissions?