MERN Stack Interview Questions

• Schema flexibility — documents in the same collection can have different fields, which is powerful for rapidly evolving products (e.g., an e-commerce catalog where shoes have “size” but laptops have “RAM”)
• Horizontal scalability via sharding — distributes data across machines. MongoDB Atlas can auto-shard, which is how companies like Forbes and Toyota handle billions of documents
• Rich query language — supports filters, projections, regex, geospatial queries, and full-text search natively
• Aggregation framework — a pipeline-based data processing engine that can replace many use cases where you would otherwise need a separate analytics tool
• Replica sets — automatic failover with primary/secondary replication. In production, a 3-node replica set gives you zero-downtime reads even if one node dies
• Multi-document ACID transactions (since v4.0) — often overlooked, but MongoDB does support transactions when you need them

1. When would you not choose MongoDB over PostgreSQL for a new project?
2. What happens to write performance as your MongoDB collection grows from 1M to 100M documents without proper indexing?
3. How does MongoDB’s WiredTiger storage engine handle concurrency at the document level?

• ObjectId is a 12-byte BSON type that encodes timestamp + machine ID + process ID + counter, giving you globally unique IDs without coordination — this is why MongoDB can generate IDs client-side without hitting the server
• Decimal128 prevents floating-point precision bugs in financial data (e.g., 0.1 + 0.2 !== 0.3 in JSON/JS, but Decimal128 handles it correctly)
• Length-prefixed encoding means MongoDB can scan through documents and skip irrelevant fields without deserializing them — critical for query performance on large documents

1. If BSON documents are larger than JSON, why does MongoDB still use BSON instead of just compressing JSON?
2. How does the ObjectId structure help with sorting by insertion time without a separate createdAt field?
3. What happens when you store a JavaScript Date object vs a string date in MongoDB — how does the query engine treat them differently?

• Capped collections — fixed-size collections that overwrite oldest docs when full. Used for logging (e.g., storing the last 10M log entries with automatic rotation). Created with db.createCollection("logs", { capped: true, size: 104857600 })
• Schema validation — despite being “schemaless,” production MongoDB almost always uses JSON Schema validation rules: db.createCollection("users", { validator: { $jsonSchema: { ... } } }). The flexibility is not about having no schema, but about evolving it without downtime migrations
• Document size limit — 16MB per document. This sounds large but becomes a real constraint when embedding arrays that grow unboundedly (e.g., embedding all comments inside a blog post document)
• The _id field is automatically indexed and must be unique within a collection. If you do not provide it, MongoDB generates an ObjectId

1. When would you split data across two collections vs embedding it in one document?
2. What happens when a document exceeds the 16MB size limit? How do you redesign to avoid this?
3. How do you handle schema evolution in MongoDB when a field needs to change type across millions of existing documents?

• insertOne() — inserts a single document. Returns insertedId
• insertMany() — inserts an array of documents. By default uses ordered insert (stops on first error). Pass { ordered: false } for bulk imports where you want to continue past failures — critical for ETL pipelines where you might be inserting 100K docs and a few have duplicate _id values

• find() — returns a cursor, not an array. This is important: cursors are lazy and stream results, so querying 1M documents does not load them all into memory
• findOne() — returns a single document or null. Internally adds limit(1) to the query
• Projections are critical for performance: find({ status: "active" }, { name: 1, email: 1 }) only returns the fields you need, reducing network transfer and memory usage

• updateOne() / updateMany() — uses update operators like $set, $inc, $push, $pull. The gotcha: without $set, you will replace the entire document
• findOneAndUpdate() — atomically finds and updates, returning either the old or new document (controlled by returnDocument: "after"). Essential for race-condition-safe operations like incrementing a counter
• replaceOne() — replaces the entire document except _id. Different from updateOne with $set

• deleteOne() / deleteMany() — permanent removal
• Soft deletes are a common production pattern: updateOne({ _id }, { $set: { deletedAt: new Date() } }) instead of actually deleting, allowing recovery and audit trails

1. What is the difference between updateOne with $set and replaceOne? When would you use each?
2. You need to insert 500K documents as fast as possible. How do you approach this?
3. How do you implement an atomic “transfer funds” operation between two user documents?

• Bytes 1-4: Unix timestamp (seconds since epoch)
• Bytes 5-9: Random value (unique per machine/process)
• Bytes 10-12: Incrementing counter

• Sortable by creation time — since the first 4 bytes are a timestamp, sorting by _id gives you chronological order for free. db.users.find().sort({ _id: 1 }) returns documents in insertion order without needing a createdAt field
• Globally unique without coordination — unlike auto-incrementing SQL IDs, ObjectIds can be generated on the client or across multiple shards without a central authority. This is what makes MongoDB horizontally scalable
• You can extract the timestamp: ObjectId("507f1f77bcf86cd799439011").getTimestamp() returns the creation date

1. Why is using an auto-incrementing integer as _id problematic in a sharded MongoDB cluster?
2. You notice that inserts are slow on a sharded collection. How might the _id (shard key) be causing a hotspot?
3. Can two documents in different collections have the same _id value? Why or why not?

• Each index costs ~8KB of RAM per 1000 documents. A collection with 50M docs and 10 indexes can consume several GB of RAM just for indexes
• Index intersection exists but is often slower than a single compound index — do not rely on MongoDB combining two single-field indexes efficiently
• Use explain("executionStats") to verify your index is actually being used. The IXSCAN stage means index usage; COLLSCAN means full scan
• Building indexes on large collections blocks writes by default. Use { background: true } (deprecated in v4.2+; now indexes are built with an optimized hybrid approach)

1. You have a compound index { a: 1, b: 1, c: 1 }. Which queries will use this index and which will not?
2. How would you index a field that contains arrays of objects (e.g., orders[].productId)?
3. Your production database has 20 indexes on a collection but writes are slow. How do you decide which indexes to remove?

db.orders.aggregate([
  { $match: { createdAt: { $gte: ISODate("2024-01-01") } } },
  { $group: {
      _id: { month: { $month: "$createdAt" }, product: "$productName" },
      revenue: { $sum: "$amount" },
      count: { $sum: 1 }
  }},
  { $sort: { revenue: -1 } },
  { $limit: 10 }
]);

• Put $match first — it filters documents early, reducing work for downstream stages, and can use indexes
• $match followed by $sort can use a compound index. Once you hit a $group or $project, indexes are no longer used
• For large datasets, use { allowDiskUse: true } — aggregation has a 100MB RAM limit per stage by default
• $lookup (joins) can be expensive. If you are doing $lookup on every query, your schema design might need denormalization

1. How would you compute a “running total” or “moving average” using the aggregation framework?
2. When would you choose to process data in the application layer (Node.js) vs the aggregation pipeline?
3. You have a $lookup that joins 10M orders with 1M users. It is slow. What are your optimization options?

• Shards — individual replica sets that each hold a portion of the data
• Config servers — store metadata about which data lives on which shard (the “chunk map”)
• mongos router — query router that clients connect to. It reads the config servers to know which shard to send queries to

• A bad shard key creates hotspots — e.g., sharding by createdAt sends all new writes to the last shard
• A good shard key has high cardinality (many unique values), even distribution, and query isolation (most queries target one shard, not all)
• Example: sharding an e-commerce orders collection by { userId: "hashed" } distributes writes evenly but means queries like “all orders this week” must scatter-gather across all shards
• Example: sharding by { region: 1, userId: 1 } enables zone sharding where US data stays on US servers (data residency compliance)

• Once you shard, you cannot change the shard key (pre-v5.0; v5.0+ allows resharding but it is an expensive operation)
• Scatter-gather queries (queries that do not include the shard key) hit all shards and are much slower
• MongoDB recommends sharding when your dataset exceeds what a single replica set can handle (typically 2-5TB or when write throughput exceeds what one primary can handle)
• Chunk splitting and balancing happen automatically — MongoDB moves chunks between shards to maintain even distribution, but this migration consumes I/O

1. You chose { email: 1 } as your shard key. A year later, your write throughput is bottlenecked. What went wrong and how do you fix it?
2. Explain the difference between hashed sharding and ranged sharding. When would you choose each?
3. How does MongoDB handle a query that does not include the shard key in the filter?

• The primary writes operations to a capped collection called the oplog (operations log)
• Secondaries continuously tail the primary’s oplog and apply the same operations locally
• This is asynchronous replication by default — secondaries may lag behind the primary (replication lag)

• If the primary becomes unreachable, the remaining members hold an election using the Raft consensus algorithm (since v3.2)
• A secondary with the most up-to-date oplog wins and becomes the new primary
• Failover typically completes in 10-30 seconds — during this window, writes fail
• Applications using the MongoDB driver with retryWrites: true automatically retry failed writes after failover

• w: 1 — acknowledged after primary writes (default)
• w: "majority" — acknowledged after majority of nodes write. Prevents data loss during failover but adds latency (~2-5ms extra)
• w: 0 — fire-and-forget. Fast but dangerous

1. What is replication lag, and how does it affect reads from secondaries in a real-time application?
2. You have a 3-node replica set and 2 nodes go down. Can the remaining node accept writes? Why or why not?
3. How does write concern "majority" prevent a specific data loss scenario that w: 1 does not?

// User with embedded addresses
{
  _id: ObjectId("..."),
  name: "Sarah",
  addresses: [
    { type: "home", city: "Austin", zip: "73301" },
    { type: "work", city: "Dallas", zip: "75001" }
  ]
}

// User document
{ _id: ObjectId("user1"), name: "Sarah" }
// Address documents
{ _id: ObjectId("addr1"), userId: ObjectId("user1"), city: "Austin" }
{ _id: ObjectId("addr2"), userId: ObjectId("user1"), city: "Dallas" }

• Data is always accessed together (e.g., user + their shipping addresses)
• The embedded array has a bounded, small size (e.g., max 5 addresses)
• You need atomic updates on both parent and child (single-document atomicity)
• The relationship is one-to-few

• Data grows unboundedly (e.g., user + their 50K comments over years)
• Data is accessed independently (e.g., products and reviews have different read patterns)
• The embedded document would exceed 16MB
• The relationship is one-to-many or many-to-many
• Multiple entities reference the same data (normalization avoids duplication)

1. You embedded user comments inside blog posts. Six months later, popular posts have 50K comments and the app is slow. How do you redesign?
2. How does the “bucket pattern” help with time-series data in MongoDB?
3. When would you use MongoDB’s $lookup for referencing, and what is its performance limitation compared to SQL JOINs?

const session = client.startSession();
try {
  session.startTransaction();
  await accounts.updateOne(
    { _id: "alice" },
    { $inc: { balance: -100 } },
    { session }
  );
  await accounts.updateOne(
    { _id: "bob" },
    { $inc: { balance: 100 } },
    { session }
  );
  await session.commitTransaction();
} catch (error) {
  await session.abortTransaction();
} finally {
  session.endSession();
}

• Financial operations (transfers, payments) where partial updates are unacceptable
• Multi-collection updates that must be atomic (e.g., creating an order AND reducing inventory)
• Any operation where you need “all or nothing” semantics

• If you can model the operation as a single-document update, you do not need a transaction — single-document operations are already atomic in MongoDB
• Transactions add latency (extra round trips, lock contention) and should not be your default tool
• Most experienced MongoDB developers redesign their schema to avoid needing transactions rather than reaching for them. This is a fundamental difference from SQL-first thinking
• Transactions have a 60-second default timeout and hold locks, so long-running transactions block other operations

1. How does MongoDB implement snapshot isolation for transactions, and what are the performance implications?
2. If a transaction fails mid-way on a sharded cluster, how does MongoDB ensure consistency across shards?
3. Redesign a “transfer funds” operation so it does not require a multi-document transaction.

const changeStream = db.collection("orders").watch();

changeStream.on("change", (change) => {
  console.log("Operation:", change.operationType);
  console.log("Document:", change.fullDocument);
  // operationType: "insert", "update", "replace", "delete"
});

• Real-time notifications — notify users when their order status changes
• Cache invalidation — invalidate Redis cache when source data changes
• Event-driven architectures — trigger downstream services when data changes (e.g., send email when user registers)
• Data synchronization — keep Elasticsearch or analytics databases in sync with MongoDB
• Audit logging — record every change for compliance

• Change streams require a replica set (even a single-node replica set for development)
• They support resume tokens — if your listener crashes, you can resume from exactly where you left off without missing events
• You can filter changes with a pipeline: collection.watch([{ $match: { "fullDocument.status": "shipped" } }])
• Change streams use the oplog, so they add minimal overhead to the database

1. How would you handle a scenario where your change stream listener was down for 2 hours? Can you recover all missed events?
2. Compare MongoDB Change Streams with using a separate message queue like Kafka. When would you choose each?
3. What happens to change streams when a replica set failover occurs?

// Application code handles both versions
function normalizeUser(doc) {
  if (!doc.fullName && doc.firstName) {
    // Old schema: firstName + lastName
    doc.fullName = `${doc.firstName} ${doc.lastName}`;
  }
  return doc;
}

// Migrate all documents
const cursor = db.users.find({ fullName: { $exists: false } });
const ops = [];
for await (const doc of cursor) {
  ops.push({
    updateOne: {
      filter: { _id: doc._id },
      update: { $set: { fullName: `${doc.firstName} ${doc.lastName}` },
                $unset: { firstName: "", lastName: "" } }
    }
  });
  if (ops.length === 1000) {
    await db.users.bulkWrite(ops);
    ops.length = 0;
  }
}

{ _id: 1, schemaVersion: 2, fullName: "Ali Khan" }
{ _id: 2, schemaVersion: 1, firstName: "Sara", lastName: "Ahmed" }

1. You need to rename a field used in 50M documents. What is your migration strategy to avoid downtime?
2. How do you use MongoDB’s $jsonSchema validator to enforce schema rules while still allowing gradual migration?
3. What are the risks of lazy migration when running analytics queries that span old and new schema versions?

• No built-in ORM or database layer — you choose (Mongoose, Prisma, Sequelize)
• No built-in authentication — you add Passport, JWT, or custom middleware
• No built-in validation — you add Zod, Joi, or express-validator
• No built-in view engine — you add EJS, Pug, or just send JSON

1. When would you choose Fastify over Express for a new project, and why?
2. Express has not had a major release in years. What does that mean for its production readiness?
3. How does Express compare to Koa in terms of middleware composition?

// This works: body parser runs BEFORE the route handler
app.use(express.json());
app.post("/users", (req, res) => res.json(req.body));

// This BREAKS: body parser runs AFTER the route
app.post("/users", (req, res) => res.json(req.body)); // req.body is undefined
app.use(express.json());

• Application-level (app.use()) — runs for every request. Use for logging, CORS, body parsing
• Router-level (router.use()) — scoped to a specific router. Use for sub-application middleware like auth on /admin routes
• Error-handling ((err, req, res, next)) — the 4-parameter signature tells Express this is an error handler. Must be declared last
• Third-party — cors(), helmet(), morgan(). These are just functions that return middleware

1. What happens if a middleware calls both res.send() AND next()? Is that valid?
2. How does Express know the difference between a regular middleware and an error-handling middleware?
3. You have 15 middleware functions. Requests are slow. How do you identify which middleware is the bottleneck?

• Routes are matched in the order they are defined — first match wins
• Exact matches take priority over parameterized routes only if defined first
• app.use("/api") matches /api, /api/users, /api/anything (prefix matching)
• app.get("/api") matches only /api exactly (exact matching)

// routes/users.js
const router = express.Router();
router.get("/", getAllUsers);
router.get("/:id", getUserById);
router.post("/", createUser);
module.exports = router;

// app.js
app.use("/api/users", require("./routes/users"));
app.use("/api/orders", require("./routes/orders"));

1. You have app.get("/users/:id") and app.get("/users/admin"). A request to /users/admin hits the first route with id = "admin". How do you fix this?
2. How does Express handle a request that matches no routes?
3. What is the performance difference between having 500 routes on app directly vs using express.Router() to organize them?

// /users/42 -> req.params.id = "42"
app.get("/users/:id", (req, res) => {
  // Always a string -- you must parse if you need a number
  const userId = parseInt(req.params.id, 10);
});

// /users?role=admin&page=2 -> req.query = { role: "admin", page: "2" }
app.get("/users", (req, res) => {
  const { role, page = 1, limit = 10 } = req.query;
});

1. When would you use /users/:userId/orders/:orderId vs /orders/:orderId? What are the trade-offs of nested routes?
2. How do you validate that :id is a valid MongoDB ObjectId before it reaches your database query?
3. What is the difference between req.params, req.query, and req.body? When should each be used in REST API design?

app.use(express.json()); // Parses Content-Type: application/json
app.use(express.urlencoded({ extended: true })); // Parses Content-Type: application/x-www-form-urlencoded

app.use(express.json({ limit: "10kb" })); // Prevent payload bombs

app.post("/users", async (req, res, next) => {
  try {
    // 1. Validate input
    const validated = userSchema.parse(req.body); // Zod validation
    // 2. Business logic
    const user = await userService.create(validated);
    // 3. Respond with 201 + Location header
    res.status(201).location(`/users/${user.id}`).json(user);
  } catch (err) {
    next(err);
  }
});

• Set a limit on express.json() to prevent denial-of-service via large payloads (default is 100kb, but 10kb is often sufficient for API requests)
• Return 201 Created (not 200 OK) for successful resource creation
• For file uploads, express.json() does not work — you need multer or busboy
• The Content-Type header must match the parser, or req.body will be empty/undefined

1. A client sends a POST with Content-Type: text/plain. What happens with express.json() middleware? How do you handle it?
2. How do you handle multipart/form-data (file uploads) in Express?
3. What is the difference between express.json() and the deprecated body-parser package?

​

Example:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello from Express!');
});

app.listen(3000, () => console.log('Server running on port 3000'));

​

Why:

​

When:

​

Where:

1. If you were starting a new high-performance API from scratch today, would you still choose Express? Why or why not?
2. How does Express’s middleware model differ from Koa’s async/await-based middleware?
3. Express 5 has been in alpha for years. What problems does it solve that Express 4 does not?

​

Example:

function logger(req, res, next) {
  console.log(`${req.method} ${req.url}`);
  next(); // Pass control to next middleware
}

app.use(logger);
app.get('/', (req, res) => res.send('Home'));

​

Why:

​

When:

​

Where:

• helmet() — security headers (first, because it protects everything below)
• cors() — CORS handling
• morgan() or custom logger — request logging
• express.json() — body parsing
• Rate limiter — abuse prevention
• Auth middleware — token verification
• Route handlers
• Error handler (always last)

1. What happens to your app if an early middleware throws an uncaught exception? How does Express handle it?
2. Can middleware be async? What is the gotcha with async middleware in Express 4?
3. How would you create a middleware that measures the response time of every request and logs it?

​

Example:

// Error-handling middleware
app.use((err, req, res, next) => {
  console.error(err.message);
  res.status(500).send('Internal Server Error');
});

​

Why:

​

When:

​

Where:

​

Example:

app.use((req, res, next) => {
  console.log('Before route');
  next(); // Pass to next middleware or route
});

app.get('/', (req, res) => {
  res.send('After middleware');
});

​

Why:

​

When:

​

Where:

​

Example:

app.use('/users', (req, res, next) => {
  console.log('Middleware for /users');
  next();
});

app.get('/users', (req, res) => res.send('User list'));

​

Why:

​

When:

​

Where:

1. Request enters Express
2. Passes through middleware stack
3. If matched, route handler executes
4. If no match → 404 handler
5. If error → error-handling middleware

​

Example Flow:

Incoming Request
   ↓
app.use(logger)
   ↓
app.use(auth)
   ↓
app.get('/users', controller)
   ↓
app.use(errorHandler)
   ↓
Response Sent

​

Why:

​

When:

​

Where:

​

Example:

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ message: err.message });
});

// And to trigger it:
app.get('/', (req, res, next) => {
  next(new Error('Something went wrong'));
});

​

Why:

​

When:

​

Where:

​

Example:

res.send('Hello');
res.json({ success: true });
res.end(); // No data, just closes connection

​

Why:

​

When:

• send() → text or HTML
• json() → APIs
• end() → streams or empty responses

​

Where:

1. Use Helmet → sets HTTP headers
2. Use Rate-limiter → prevent brute-force
3. Use CORS properly
4. Use express.json({ limit }) → prevent payload overflows
5. Disable x-powered-by header
6. Validate all inputs (with Joi/Zod)

​

Example:

const helmet = require('helmet');
const rateLimit = require('express-rate-limit');

app.use(helmet());
app.use(rateLimit({ windowMs: 60 * 1000, max: 100 }));
app.disable('x-powered-by');

​

Why:

​

When:

​

Where:

1. Try/catch inside route, or
2. Wrap with async error handler.

​

Example:

// Approach 1: try/catch
app.get('/', async (req, res, next) => {
  try {
    const users = await User.find();
    res.json(users);
  } catch (err) {
    next(err);
  }
});

// Approach 2: wrapper function
const asyncHandler = fn => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next);

​

Why:

​

When:

​

Where:

​

Example:

app.get('/users', handler1);
app.use('/users', handler2);

​

Why:

​

When:

​

Where:

​

Example:

app.get('/users/:id', (req, res) => {
  res.send(`User ID: ${req.params.id}`);
});

​

Why:

​

When:

​

Where:

• Authentication → verifying identity (e.g., login with email/password or Google OAuth)
• Authorization → verifying permissions (e.g., only admin can delete a user)

​

Example:

// Example route using both
app.get('/admin', authenticateUser, authorizeRole('admin'), (req, res) => {
  res.send('Welcome Admin!');
});

​

Why:

​

When:

​

Where:

​

Steps:

1. User logs in with credentials
2. Server verifies credentials and issues a signed JWT using jsonwebtoken
3. Client stores JWT (usually in localStorage or cookie)
4. Client sends JWT in Authorization: Bearer <token> header for protected routes

​

Example:

import jwt from 'jsonwebtoken';

// Generate Token
const token = jwt.sign({ userId: user.id, role: user.role }, process.env.JWT_SECRET, {
  expiresIn: '1h',
});

// Middleware for verification
function verifyToken(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token provided' });

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    req.user = decoded;
    next();
  } catch (err) {
    res.status(403).json({ error: 'Invalid token' });
  }
}

​

Why:

​

When:

​

Where:

• Never store JWTs in localStorage — vulnerable to XSS. Use HttpOnly cookies instead
• Always set short expiration (15 minutes for access tokens) and use refresh tokens for longevity
• Include only necessary claims — the payload is Base64-encoded, not encrypted. Anyone can decode it
• Use RS256 (asymmetric) for microservices instead of HS256 (symmetric), so services can verify tokens without knowing the secret
• Validate the alg header — the “none algorithm” attack changes alg to "none" to bypass signature verification

1. A user changes their password. How do you invalidate all their existing JWTs?
2. What is the “none algorithm” attack and how do you prevent it?
3. Your JWT payload is 8KB. What problems does this cause and how do you reduce it?

• The app is monolithic and server-rendered (like an Express + EJS app)
• You need easy session invalidation (e.g., logout all sessions)
• You store user-specific state in the backend

​

Example (session-based login):

import session from 'express-session';

app.use(session({
  secret: 'keyboard cat',
  resave: false,
  saveUninitialized: true,
  cookie: { secure: false },
}));

​

Why:

​

When:

​

Where:

​

Example:

function authorizeRole(...roles) {
  return (req, res, next) => {
    if (!roles.includes(req.user.role)) {
      return res.status(403).json({ error: 'Access denied' });
    }
    next();
  };
}

// Usage
app.delete('/users/:id', verifyToken, authorizeRole('admin'), deleteUser);

​

Why:

​

When:

​

Where:

​

Example (ABAC):

// Only allow if user owns the resource
if (req.user.id !== post.authorId) {
  return res.status(403).json({ error: 'Not allowed' });
}

​

Why:

​

When:

​

Where:

​

Example using bcrypt:

import bcrypt from 'bcrypt';

const salt = await bcrypt.genSalt(10);
const hashedPassword = await bcrypt.hash(password, salt);

​

Why:

​

When:

​

Where:

​

Example:

// Generate both
const accessToken = jwt.sign({ userId }, JWT_SECRET, { expiresIn: '15m' });
const refreshToken = jwt.sign({ userId }, REFRESH_SECRET, { expiresIn: '7d' });

// Refresh endpoint
app.post('/refresh', (req, res) => {
  const { token } = req.body;
  const user = jwt.verify(token, REFRESH_SECRET);
  const newAccessToken = jwt.sign({ userId: user.id }, JWT_SECRET, { expiresIn: '15m' });
  res.json({ accessToken: newAccessToken });
});

​

Why:

​

When:

​

Where:

​

Common strategies:

1. Blacklist tokens in Redis
2. Rotate refresh tokens (invalidate old ones)
3. Use short expiry times for access tokens

​

Example:

// Blacklist token on logout
redisClient.setex(token, expiryTime, 'blacklisted');

​

Why:

​

When:

​

Where:

1. JWT token leakage — store tokens securely
2. No HTTPS — exposes credentials
3. Brute force attacks — use rate limiting
4. Insecure password reset links — use short-lived tokens

​

Example mitigation:

import rateLimit from 'express-rate-limit';
app.use('/auth/login', rateLimit({ windowMs: 15 * 60 * 1000, max: 5 }));

​

Why:

​

When:

​

Where:

​

Example:

import passport from 'passport';
import { Strategy as GoogleStrategy } from 'passport-google-oauth20';

passport.use(new GoogleStrategy({
  clientID: process.env.GOOGLE_ID,
  clientSecret: process.env.GOOGLE_SECRET,
  callbackURL: '/auth/google/callback',
}, (accessToken, refreshToken, profile, done) => {
  done(null, profile);
}));

​

Why:

​

When:

​

Where: