Как лучше показывать MongoDB ObjectId в адрес

MongoDB ObjectId можно показывать в адрес как строку из 24 hex-символов, например /products/665f1c1a7b8c2e0012a4d111. Это технически нормально: ObjectId не является паролем. Но для публичных страниц и удобства пользователя часто лучше использовать человекочитаемый slug, например /products/kurs-po-mongodb

Практический выбор такой: для внутренних админок можно использовать ObjectId; для публичных страниц лучше slug; для API можно использовать ObjectId, но обязательно валидировать его

Главная мысль простая: сам формат адреса не должен быть единственной защитой. Красивый адрес помогает человеку понять страницу, а проверка прав и валидация параметров защищают данные

Если сомневаетесь, начните с ObjectId в API и добавьте slug только для публичных страниц

Вариант 1. ObjectId в адрес

Пример маршрута:

/products/665f1c1a7b8c2e0012a4d111

В Node.js через Mongoose:

import mongoose from "mongoose";

app.get("/products/:id", async (req, res) => {
  const { id } = req.params;

  if (!mongoose.Types.ObjectId.isValid(id)) {
    return res.status(400).json({ error: "Некорректный id" });
  }

  const product = await Product.findById(id);

  if (!product) {
    return res.status(404).json({ error: "Товар не найден" });
  }

  res.json(product);
});

Главное — не отправлять любой параметр сразу в запрос без проверки

Вариант 2. Slug для публичной страницы

Пример документа:

{
  title: "Курс по MongoDB",
  slug: "kurs-po-mongodb",
  price: 1900
}

Маршрут:

/products/kurs-po-mongodb

Запрос:

const product = await Product.findOne({ slug: req.params.slug });

Для slug полезно поставить уникальный индекс:

productSchema.index({ slug: 1 }, { unique: true });

Что безопаснее

Сам по себе ObjectId не дает доступ к данным. Опасность появляется, если приложение отдает чужие документы без проверки прав. Например, пользователь меняет id в адрес и видит чужой заказ. Это лечится не скрытием ObjectId, а авторизацией:

const order = await Order.findOne({
  _id: id,
  userId: req.user.id
});

Так пользователь сможет получить только свой заказ

Когда что выбирать

Частые ошибки

Не проверяют формат id

Некорректный id может привести к ошибке запроса. Валидируйте параметр до обращения к базе

Думают, что скрытый id заменяет права

Даже если использовать красивый slug, проверка прав все равно нужна

Меняют slug без редиректа

Если публичный адрес меняется, добавьте редирект со старого slug на новый. Иначе пользователи и поисковые системы попадут на 404

Что почитать дальше по MongoDB

Если нужен общий маршрут по теме, откройте рубрику MongoDB. Для соседних задач пригодятся эти разборы:

• Как лучше искать переписку в MongoDB перед созданием
• Как лучше реализовать структуру в MongoDB
• Discord bot на Python и MongoDB: как задать проверку
• Failed to start MongoDB database server: что проверить

Как проверить результат на практике

Для MongoDB-материала полезно делать три проверки: сначала выполнить команду на маленьком наборе тестовых документов, затем посмотреть результат через find() или MongoDB Compass, а после этого повторить действие на копии реальной структуры данных. Если запрос меняет документы, сначала запускайте его с фильтром на один документ и только потом расширяйте условие

Еще одна хорошая привычка — записывать исходное состояние и ожидаемый результат. Например: было три документа, после обновления изменился только один; был массив из пяти элементов, после операции остался нужный элемент; индекс появился в getIndexes(). Такая проверка быстро показывает, что вы исправили именно задачу, а не просто получили команду без ошибки