Resource ownership checks in Express - Step-by-Step Execution

Concept Flow - Resource ownership checks

Request received

↓

Extract user ID from auth

↓

Extract resource ID from request

↓

Fetch resource from database

↓

Compare resource owner ID with user ID

↓

Allow access

↓

Send response

The server checks if the logged-in user owns the resource before allowing access or denying it.

Execution Sample

Express

app.get('/posts/:id', async (req, res) => {
  const userId = req.user.id;
  const post = await Post.findById(req.params.id);
  if (post && post.ownerId === userId) {
    res.send(post);
  } else {
    res.status(403).send('Forbidden');
  }
});

This code checks if the logged-in user owns the post before sending it or denying access.

Execution Table

Step	Action	Value/User ID	Resource Owner ID	Condition (ownerId === userId)	Branch Taken	Response Sent
1	Request received for post ID 101	user123	-	-	-	-
2	Fetch post from DB	user123	user123	-	-	-
3	Compare ownerId and userId	user123	user123	true	Allow access	-
4	Send post data	user123	user123	true	Allow access	Post data sent
5	Request received for post ID 102	user123	-	-	-	-
6	Fetch post from DB	user123	user999	-	-	-
7	Compare ownerId and userId	user123	user999	false	Deny access	-
8	Send 403 Forbidden	user123	user999	false	Deny access	403 Forbidden sent

💡 Execution stops after sending response based on ownership check result.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	After Step 7	Final
userId	undefined	user123	user123	user123	user123	user123
post.ownerId	undefined	user123	user123	user999	user999	user999
condition ownerId === userId	undefined	-	true	-	false	false
response	none	none	pending	none	pending	sent

Key Moments - 3 Insights

Why do we compare post.ownerId with userId?

We compare to check if the logged-in user owns the resource. If they match (see execution_table step 3), access is allowed; otherwise, it is denied (step 7).

What happens if the resource is not found in the database?

If the resource is missing, the fetch returns null or undefined, so ownerId is undefined. The condition fails, and access is denied, preventing unauthorized access.

Why send a 403 status code instead of 404 when ownership check fails?

403 means 'Forbidden'—the resource exists but user can't access it. 404 means 'Not Found'. Using 403 informs the user they are unauthorized, not that the resource is missing.

Visual Quiz - 3 Questions

Look at the execution table, what is the condition result at step 7?

A false

B undefined

C true

D null

💡 Hint

Check the 'Condition (ownerId === userId)' column at step 7 in the execution_table.

At which step is the 403 Forbidden response sent?

A Step 4

B Step 8

C Step 5

D Step 3

💡 Hint

Look at the 'Response Sent' column in the execution_table for the step sending '403 Forbidden sent'.

If userId and ownerId always match, what changes in the execution table?

A No response is sent

B All branches take 'Deny access' path

C All branches take 'Allow access' path

D The condition is always false

💡 Hint

Refer to the 'Branch Taken' column and condition results in the execution_table.

Concept Snapshot

Resource ownership checks in Express:
- Extract user ID from authenticated request
- Fetch resource by ID from DB
- Compare resource owner ID with user ID
- If match, allow access and send resource
- If no match, send 403 Forbidden
- Prevents unauthorized access to others' data

Full Transcript

In Express, resource ownership checks ensure users can only access their own data. When a request arrives, the server extracts the logged-in user's ID and the resource ID from the request. It fetches the resource from the database and compares the resource's owner ID with the user's ID. If they match, the server sends the resource data back. If they don't, the server responds with a 403 Forbidden status, denying access. This process protects user data by verifying ownership before allowing access.