Demo Authorization Implementation

Having completed a detailed look at authentication, this lesson focuses on authorization: verifying who can do what after identity is established. We’ll load Claude again, run an authorization review against the target application, and consolidate the findings, prioritized fixes, and ready-to-use remediation snippets.

A presentation slide titled "Authorization Implementation" with a dark curved shape on the right containing the word "Demo" in blue. A small "© Copyright KodeKloud" notice appears in the bottom-left.

Load the prompts and automation used for this assessment from the public repository: https://github.com/JeremyMorgan/Claude-Code-Reviewing-Prompts What to analyze

Authorization implementation across all routes and endpoints.
Broken Object Level Authorization (BOLA / IDOR).
Broken Function Level Authorization.
Missing authorization checks on sensitive endpoints (admin, bulk, debug).
Role-based access control (RBAC) correctness and deny-by-default enforcement.
Privilege escalation paths via update flows or misapplied defaults.
JWT validation on protected routes and token revocation checks.
Proper scope checking for API/service tokens and multi-tenant isolation.
Field-level authorization, bulk protections, and consistent error handling.

Authorization Implementation checklist (consolidated)

Check	What to verify	Notes / Example
Object-level authorization (BOLA/IDOR)	Enforce ownership/tenant checks on GET/PUT/DELETE /:id and any identifier-based access.	Validate IDs from URL/body/query against the authenticated user’s tenantId/userId.
Function-level authorization	Ensure server-side role/permission checks for all privileged routes.	Don’t rely on client-side UI checks.
Sensitive endpoints protected	Audit for unprotected admin/debug/bulk export routes.	Confirm middleware order: authN -> authZ -> handler.
RBAC mapping & deny-by-default	Map roles to explicit permissions; prevent clients from setting roles.	Store role assignments server-side only.
Privilege escalation vectors	Block updates to fields like role, tenantId, isAdmin unless performed by authorized system flows.	Add field-level checks in update handlers.
JWT verification	Use jwt.verify with algorithms, issuer, audience, and exp. Avoid trusting jwt.decode.	Check jti/tokenVersion against a revocation list.
API token scope checks	Enforce least-privilege scopes per token; separate user vs service tokens.	Validate audience and intended usage.
Multi-tenant isolation	Filter list/search endpoints by tenant, enforce server-side tenant constraints.	Avoid client-provided tenant identifiers.
Bulk protections	Verify ownership per item on bulk operations and limit sizes/rates.	Fail-safe per-item checks.
Field-level authorization	Hide sensitive fields (SSN, apiKey, secrets) from non-privileged roles.	Use projection/serialization rules.
Error handling/resource enumeration	Return consistent 403 vs 404 to avoid leaking existence.	Consider 404 when revealing existence is risky.
Middleware ordering	Ensure no handlers run before auth middleware; check nested routers.	Use top-level auth middleware where appropriate.
CORS & CSRF	Avoid wildcard origins with credentials; if cookies used, enforce SameSite/CSRF tokens.	Harden cross-site risks.
Open redirect protections	Validate redirect/next parameters against an allowlist.	Prevent phishing by open redirects.
Fallback/debug routes	Remove or protect `/seed`, `/reset`, `/debug` in prod.	Make admin-only or gated behind feature flags.

High-level summary (assessment snapshot)

Risk Score: 9.5/10 (Critical)
Critical issues identified:
1. No authentication/authorization middleware — endpoints are unprotected beyond login.
2. Weak JWT implementation — missing strict verification parameters; possible default secrets.
3. No RBAC or object-level authorization — vulnerable to BOLA/IDOR.
4. Inconsistent error handling — may leak resource existence.

This assessment indicates the application should not handle real user data in its current state. Immediate remediation is required before any production deployment.

Concrete remediation snippets

Authentication middleware (verify JWT)

// middleware/authenticate.js
const jwt = require('jsonwebtoken');

const authenticateToken = (req, res, next) => {
  const authHeader = req.headers['authorization'] || '';
  const token = authHeader.startsWith('Bearer ') ? authHeader.slice(7) : null;

  if (!token) {
    return res.status(401).json({ error: 'Missing Authorization token' });
  }

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET, {
      algorithms: ['HS256'],
      issuer: process.env.JWT_ISS,   // e.g., 'your-app'
      audience: process.env.JWT_AUD // e.g., 'your-app-users'
    });
    // Keep minimal, validated claims only
    req.user = {
      userId: payload.userId,
      roles: payload.roles,
      tenantId: payload.tenantId,
      jti: payload.jti || payload.tokenVersion
    };
    return next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid or expired token' });
  }
};

module.exports = authenticateToken;

Issuing JWTs with recommended claims (login handler)

// routes/auth.js (excerpt)
const jwt = require('jsonwebtoken');

const token = jwt.sign(
  {
    userId: user.id,
    email: user.email,
    roles: user.roles,               // array or minimal role identifiers
    tenantId: user.tenantId,         // multi-tenant context if applicable
    tokenVersion: user.tokenVersion, // used to revoke tokens server-side
    iat: Math.floor(Date.now() / 1000)
  },
  process.env.JWT_SECRET,
  {
    algorithm: 'HS256',
    issuer: process.env.JWT_ISS,
    audience: process.env.JWT_AUD,
    expiresIn: '15m' // short-lived access token
  }
);

Object-level ownership authorization (authorizeOwnership middleware)

// middleware/authorizeOwnership.js
const pool = require('../db'); // adjust to your DB client

const authorizeOwnership = async (req, res, next) => {
  const resourceId = req.params.id;
  const userId = req.user && req.user.userId;

  if (!userId) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  try {
    const result = await pool.query(
      'SELECT user_id FROM resources WHERE id = $1',
      [resourceId]
    );

    if (result.rows.length === 0) {
      // Optionally hide existence to prevent enumeration
      return res.status(404).json({ error: 'Resource not found' });
    }

    if (result.rows[0].user_id !== userId) {
      return res.status(403).json({ error: 'Access denied' });
    }

    next();
  } catch (err) {
    next(err);
  }
};

module.exports = authorizeOwnership;

Applying middleware and enforcing authN -> authZ -> handler order

// server.js (excerpt)
const express = require('express');
const authenticateToken = require('./middleware/authenticate');
const authorizeOwnership = require('./middleware/authorizeOwnership');
const app = express();

app.use(express.json());

// Public route
app.get('/', (req, res) => res.send('Public endpoint'));

// Protected route: authentication runs first, then ownership check, then handler
app.get('/api/resources/:id', authenticateToken, authorizeOwnership, async (req, res) => {
  // Safe to fetch and return resource because ownership was checked
  const resource = await getResourceById(req.params.id);
  res.json(resource);
});

Proof-of-Concept (what the assessment demonstrated)

# Anyone can access the public endpoint
curl http://localhost:3000/

# Login returns a JWT, but if routes do not validate it, downstream endpoints remain unprotected:
curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"password123"}'

Recommended immediate actions (prioritized)

Replace any default JWT secret (e.g., JWT_SECRET=your_jwt_secret_key_here) with a strong secret (256-bit recommended) stored in a secure secret manager.
Implement and apply authentication middleware (jwt.verify with algorithms/issuer/audience) across all protected routes before any business logic.
Add object-level ownership checks for all /:id and object-access routes; enforce deny-by-default for RBAC decisions.
Audit and remove or strictly protect debug/admin routes (e.g., /seed, /reset, /debug) in production.
Normalize error handling to avoid resource enumeration (use 404 for not-found and 403 for explicit access-denied where appropriate).

Full report and remediation expectations For each finding produce:

Title, Severity, CWE (if applicable)
Evidence (file/function/lines)
Why it matters
Exploitability notes
Minimal PoC (safe)
Code-level remediation snippets
Defense-in-depth guidance and recommended tests

Also produce a checklist diff marking each verification item as Pass / Fail / Not Applicable. Notes on LLM-generated code

LLMs synthesize examples from many sources and may suggest working but insecure defaults (weak secrets, missing validations). Treat generated code as a starting point: run automated security tests and manual code review to harden before production.

Suggested follow-up reviews

Input validation and sanitization for user- or bot-controlled inputs (prevent SQLi, injection).
Rate limiting and brute-force protections for sensitive routes.
Token revocation and refresh token patterns (rotate and revoke via tokenVersion/jti).
Logging, monitoring, and alerting for suspicious authorization failures.

Links and references

Prompts and automation: https://github.com/JeremyMorgan/Claude-Code-Reviewing-Prompts
JSON Web Tokens: https://jwt.io/
OWASP Broken Access Control: https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control

Introduction

Getting Started with Claude Code

Working with Claude Code

Code Review with Claude Code

Security Auditing with Claude Code

Advanced Features

Demo Authorization Implementation

Watch Video