Request data stored in shared state

Request data stored in shared state

Description

Storing user-specific request or session data in module globals or singleton objects can make the same values available to other requests in the process.

This does not require multithreaded execution. User-specific values may remain in shared state even when one process handles requests sequentially.

Potential impact

  • A previous user's identity or permission data may be exposed to another user.
  • Authorization may incorrectly use another user's state.

Remediation

  • Keep request-specific data in locations with separate request scope, such as local variables, request objects or session stores.
  • Do not store user-specific authentication, session or personal data in module globals or singleton objects.

Examples

Before

javascript
let currentUser;

app.get("/profile", (req, res) => {
  currentUser = req.session.user;
  res.json(currentUser);
});

After

javascript
app.get("/profile", (req, res) => {
  const currentUser = req.session.user;
  res.json(currentUser);
});

Explanation:

  • Before: The user value remains in a global variable that other code or later requests can read. The shown synchronous handler immediately returns the value it just assigned; mixing users' values becomes a risk when shared state is reused or asynchronous work interleaves.
  • After: The handler uses only a function-local variable for this request. Session middleware and authentication must already be configured.

References