Попытка сделать ваш сервис без гражданства - достойная цель. Является ли наличие идентификаторов заказа в строках запроса "безопасным", однако, зависит от многих вещей. Основные вещи, о которых вам, возможно, придется беспокоиться:
- пользователи, изменяющие свой идентификатор заказа
- идентификаторы заказа "просачиваются" третьим лицам
- идентификаторы заказа, прогнозируемые сторонними организациями
Я говорю «может», потому что то, о чем вам действительно нужно беспокоиться, зависит от деталей вашей системы. Каковы последствия этих событий? В зависимости от деталей вашей системы они могут быть безвредными или очень серьезными.
Самая простая проблема, которую нужно решить - это проблема с утечкой. Используйте HTTPS. Это не только предотвращает «подслушивание», но также предотвращает утечки из-за журналов прокси и заголовков Referer.
Проблема прогнозирования может быть решена путем шифрования (да, в дополнение к HTTPS - мы не хотим, чтобы конечный пользователь также расшифровывал это) идентификатора заказа, который появляется в строке запроса. Таким образом, кто-то не может просто включить / уменьшить строку запроса, чтобы найти другой идентификатор заказа. (Это также не позволяет пользователям легко определить общее количество заказов в вашей системе, что может быть желательным.)
Вы можете решить проблему изменения пользователем своего идентификатора заказа, либо записав, кому принадлежит идентификатор заказа при его первом выделении, либо включив безопасную подпись пары (user, orderid) в качестве параметра запроса. Тогда пользователь может изменить только свой идентификатор заказа на тот, который у него уже есть, что, по крайней мере, не позволяет ему вмешиваться в чужие заказы. Если вы сделаете это, вам, вероятно, не потребуется шифровать идентификаторы заказов, если только вы не хотите, чтобы пользователи не знали, сколько существует заказов.
Это всего лишь некоторые идеи. Какие из них применимы к вашей системе, зависят от факторов, которые я упоминал ранее.