DEV Community: Muhammad Masood Kausar

The Node.js Shortcut That Quietly Created a Security Hole

Muhammad Masood Kausar — Tue, 21 Jul 2026 07:46:18 +0000

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?

A Streaming-First UI Framework Built for the AI Era

Muhammad Masood Kausar — Mon, 20 Jul 2026 14:04:38 +0000

Most AI products still stream words.

But what if an AI model could stream the interface itself?

I recently explored Aktion, an ambitious open-source project created by my mentor, Asfandiyar Khan, a senior frontend engineer based in Germany.

Aktion is a streaming-first UI framework designed to turn compact, JavaScript-shaped instructions into reactive and interactive user interfaces.

Instead of producing another Markdown response or a large block of frontend code, an AI model can progressively generate:

Cards
Charts
Forms
Tables
Dashboards
Navigation
Interactive workflows

What makes Aktion different?

Traditional AI-generated frontend code often requires the model to coordinate several independent systems:

Framework syntax
Package imports
State management
Routing
Form handling
Styling
Data fetching
Component libraries
Dependency versions

Aktion takes a different approach.

It gives developers and AI agents:

A compact JavaScript-shaped reactive language
A unified UI runtime
A consistent component vocabulary
Built-in application capabilities
A framework-agnostic Web Component
Streaming support for progressively generated interfaces

The central integration point is the <aktion-app> Web Component.

Because of this approach, Aktion can be embedded inside React, Vue, Angular, Svelte, plain HTML, or another host environment without rebuilding the generated UI layer for every framework.

Why streaming-first UI matters

Most AI interfaces wait until a response is complete before presenting the final output.

Aktion is designed so completed statements can be rendered while the model is still generating the rest of the response.

A heading can appear first.

Then a chart.

Then filters, forms, cards, and interactive controls.

The AI response does not only describe an application.

It gradually becomes the application.

A smaller target for AI-generated interfaces

One of Aktion’s most interesting ideas is its constrained language.

AI models normally have enormous freedom when generating frontend applications. They must choose libraries, understand different APIs, manage imports, and connect tools that were not necessarily designed to work together.

More freedom can also create more incompatible decisions.

Aktion reduces that decision space by providing one language, one runtime, and one predictable set of interface primitives.

The important idea is not only that Aktion contains many features.

It is that AI-generated interfaces may become more dependable when models generate into a smaller and more controlled environment.

More than a component library

Aktion brings several common frontend concerns into one system, including:

Reactive state
Routing
Forms
Data fetching
Themes
Responsive styling
Charts
Realtime interfaces
Internationalization
Testing utilities
Server-side rendering
A large built-in component vocabulary

This does not automatically make it the right solution for every application.

However, it makes Aktion an interesting experiment in how frontend runtimes could evolve for generative UI.

The engineering effort behind Aktion

Building a framework is very different from building a small library.

Aktion brings together:

A language
A parser
A reactive runtime
A rendering system
A component vocabulary
Streaming behavior
Developer tooling
LLM integration
Documentation
Interactive demonstrations

It is inspiring to see my mentor transform years of frontend experience into such an ambitious open-source project.

An idea worth exploring

Aktion may still be an early project, and questions around security, runtime size, extensibility, debugging, and long-term stability deserve careful discussion.

But the architectural question behind it is important:

Should AI continue generating unrestricted frontend applications, or should we design smaller runtimes that give models a clearer and more predictable target?

The future of generative UI may not depend only on making AI models more capable.

It may also depend on designing better environments for them to generate into.

Explore the project

🌐 Visit the Aktion project homepage

💻 View Aktion on GitHub

📖 Read my complete article on Medium

Congratulations to Asfandiyar Khan on this impressive engineering effort and valuable contribution to the open-source community.

What are your thoughts on streaming-first generative UI?