Является ли плохой практикой предоставление идентификатора базы данных клиенту в вашем REST API?

Question

Я обсуждал это пару раз в моей карьере. На мой взгляд, это совершенно нормально - выставлять клиенту идентификаторы, хранящиеся в базе данных, в ответе REST API. Но некоторые люди, с которыми я работал, считают, что это действительно один из первых уроков в области безопасности: «Никогда не передавайте свои идентификаторы базы данных клиенту».

Тогда они идут со всеми видами сложности, чтобы избежать этого. Например, на одном задании мне приходилось хэшировать каждый идентификатор в моем ответе покоя, а затем распаковывать все идентификаторы в запросе.

Теперь в моей новой работе мы имеем следующую схему. У таблицы есть автоматически увеличивающийся «идентификатор», но мы не раскрываем этого, рядом с этим у нас есть «код» uuid, и это тот, который мы предоставляем клиенту. По сути, у нас есть 2 идентификатора, оба хранятся в БД, но один мы можем раскрыть, другой мы можем, потому что:

«Никогда не передавайте свои идентификаторы базы данных клиенту.»

Имеет ли это хоть какой-то смысл? Мы по-прежнему предоставляем клиенту «идентификатор». Если проблема в том, что кто-то может видеть, сколько строк у нас в таблице, потому что этот «id» автоматически увеличивается, я просто сделал бы «id» идентификатором uuid и показал бы это клиенту.

Если вы посмотрите на примеры других публичных API отдыха, мне всегда кажется, что они без проблем выставляют идентификатор базы данных. Например, gitlab:

GET /projects/:id/users

[
  {
    "id": 1,
    "username": "john_smith",
    "name": "John Smith",
    "state": "active",
    "avatar_url": "http://localhost:3000/uploads/user/avatar/1/cd8.jpeg",
    "web_url": "http://localhost:3000/john_smith"
  },
  {
    "id": 2,
    "username": "jack_smith",
    "name": "Jack Smith",
    "state": "blocked",
    "avatar_url": "http://gravatar.com/../e32131cd8.jpeg",
    "web_url": "http://localhost:3000/jack_smith"
  }
]

Twitter: https://api.twitter.com/1.1/statuses/show.json?id={id}

Но даже stackoverflow: https://stackoverflow.com/questions/{id} https://stackoverflow.com/users/{id}

Могу поспорить, что 2188707 в URL https://stackoverflow.com/users/2188707 - это просто мой идентификатор пользователя в базе данных stackoverflow.

Answer 1

Не проблема безопасности, но она позволяет пользователю узнать некоторую информацию о размере ваших данных как компании. и некоторые компании не предпочитают раскрывать такую ​​информацию

Answer 2

Я не вижу каких-либо причин безопасности для предоставления простого идентификатора базы данных в вашем API. Если ваша база данных выставлена, вы все равно проиграли. Безопасность через неизвестность никогда не бывает решением.

Однако есть и другие причины для рассмотрения:

• Предоставление идентификатора базы данных создает связь с вашей базой данных. Представьте себе объединение данных из разных баз данных (с одной и той же схемой) или применение резервных данных к уже используемой базе данных. Не будет гарантии, что идентичные идентификаторы будут доступны.

• Разработка правильного API на основе ресурсов требует от вас предоставления универсально уникальных идентификаторов (UUID) или технического составного ключа по той простой причине, что нет другого способа обеспечить уникальность в разных системах / базах данных.