успокоительный api .. сеансовая безопасность

Question

Предположим, что в приложении для заказа пользователь "Бен" мог бы перечислить конкретный заказ, выдав

/ order / 1

сейчас .. перед тем как я аутентифицировался "Бен"(имя пользователя / пароль аутентифицировано) и отправил имя пользователя в виде файла cookie (подписанного контрольной суммой sha1).

при каждом запросе http я получаю файл cookie, который сообщает мне, что" Bent "все еще аутентифицирован, но кто может остановитьон из выдачи

/ order / 23

, где order с id = 23 не принадлежит "Бену".

, поэтому я думаю, что я должен написать некоторую логику, чтобы убедиться,этот порядок 23 на самом деле принадлежит «Бену» ... это лучший метод или шаблон для такого рода ситуаций?

следует ли мне использовать отдельный «функциональный первичный ключ» вместо серийного идентификатора первичного ключа?

Answer 1

Я не вижу разумного естественного первичного ключа для заказа.Чтобы сделать его менее заметным, вы можете использовать UUID (довольно малый шанс случайно найти / orders / 4886ed80-dd71-11e0-9572-0800200c9a66) ...

НО это будет безопасность по незаметности.Даже если я не смогу угадать UUID вашего заказа, я могу отследить ваш трафик и, если безопасность обеспечивается только через непонятные URL-адреса, я смогу делать все, что захочу, с ресурсом Order.

Это должно прояснить, что вы не можете пропустить аутентификацию в таком случае.