Authorization: who can do what

Who you are vs what you may do

Authentication answers "who are you?" (login). Authorization answers "are you allowed to do this?" A logged-in customer is authenticated, but they must still not be authorized to refund other people's orders.

401 or 403?

Role-based access control (RBAC)

In RBAC each user has a role, and each role has a list of permissions. A permission is a named action like "product:update". The code asks "does this role have this permission?" instead of checking user names.

// Example only: runs on a server with Node.js and Express
const PERMISSIONS = {
  customer: ['product:read', 'order:read'],
  staff: ['product:read', 'product:update', 'order:read'],
  admin: ['product:read', 'product:update', 'order:read', 'order:refund'],
};

function requirePermission(permission) {
  return (req, res, next) => {
    if (!req.user) return res.status(401).json({ error: 'Login required' });
    const allowed = PERMISSIONS[req.user.role] ?? [];
    if (!allowed.includes(permission)) return res.status(403).json({ error: 'Forbidden' });
    next();
  };
}

app.post('/api/orders/:id/refund', requirePermission('order:refund'), refundOrder);

Ownership checks

Roles are not enough. A customer has "order:read", but only for their own orders. So after loading the record, check that order.userId equals the logged-in user's id. Even better, put the owner in the query itself: SELECT * FROM orders WHERE id = ? AND user_id = ?.

Broken access control and IDOR

IDOR (Insecure Direct Object Reference) is when the server trusts an id from the URL without checking ownership. Broken access control sits at number one in the OWASP Top 10 list of web risks.

GET /api/orders/1043   (Asha's own order)          -> 200 OK
GET /api/orders/1044   (Asha changes one number)     -> 200 OK  <- BUG: Ravi's address and phone!

Fixed server:
GET /api/orders/1044   (order belongs to Ravi)       -> 403 Forbidden (or 404)

• Deny by default: if no rule says yes, the answer is no.
• Least privilege: give each user, staff member and API key only the permissions they need.
• Check on the server, on every request, for every action, including "read".
• Log denied attempts; many 403s from one account is a warning sign.
• Write tests for "user A cannot see user B's data".