UUID в URL: как проверить параметр и доступ к объекту

Параметр UUID в URL проходит как минимум три разные проверки: подходит ли его текстовая форма, существует ли объект и разрешено ли текущему пользователю действие. Успех первой проверки ничего не говорит о двух остальных. Это важно, даже если значение невозможно угадать простым перебором счётчика.

Для API заранее определите допустимую форму: UUID любой поддерживаемой версии или строго v4, только запись с дефисами или ещё компактные варианты, какой регистр считается каноническим. Иначе разные слои приложения начнут принимать разные строки.

UUID как один сегмент пути

Синтетический путь:

/documents/07f7f6ad-b06e-4aaa-8e69-15c2c6d1508c

Буквы, цифры и дефис относятся к unreserved URI-символам. Каноническое текстовое UUID помещается в один сегмент без специальной замены этих символов. RFC 3986, раздел 2.3, январь 2005; проверено 05.10.2026.

Это пример собственного маршрута приложения, не действующий endpoint Neraviko. Генератор UUID можно использовать для искусственного ID контрольного набора; он не валидирует ваш маршрут и не проверяет права на документы.

На сервере сначала извлеките один уже разобранный параметр пути средствами framework. Не ищите UUID произвольной подстрокой во всём URL: строка с корректным фрагментом и посторонним хвостом не должна становиться допустимым идентификатором.

Проверенный строгий пример для v4

Ниже самостоятельный Python-пример для политики «только каноническая форма v4; регистр допускается». Он проверен локально:

import re
import uuid

pattern = re.compile(
    r"[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-"
    r"[89ab][0-9a-f]{3}-[0-9a-f]{12}",
    re.IGNORECASE,
)

def parse_v4(segment):
    if not pattern.fullmatch(segment):
        raise ValueError("expected canonical UUID v4")
    return str(uuid.UUID(segment))

Для 07F7F6AD-B06E-4AAA-8E69-15C2C6D1508C результат — 07f7f6ad-b06e-4aaa-8e69-15c2c6d1508c. Для той же строки с завершающим переводом строки — отказ. Для третьей группы 7aaa вместо 4aaa — отказ этой политики, хотя UUID другой версии может быть допустим в ином контракте.

fullmatch проверяет весь сегмент. Не используйте поиск подстроки и не удаляйте неожиданные символы ради успешной проверки. Сам UUID-parser может принимать дополнительные представления; предварительная проверка здесь намеренно ограничивает форму маршрута.

Версия и вариант задаются определёнными битами UUID. RFC 9562, разделы 4.1–4.2, май 2024; проверено 05.10.2026. Значения nil/max и другие версии требуют собственного решения в API; строгий v4-пример их не принимает.

Решите судьбу дополнительных представлений

Фигурные скобки, префикс urn:uuid: и строка без дефисов могут приниматься отдельным UUID-парсером, но не входят в строгую форму маршрута этого примера. Добавьте их в набор ожидаемых отказов. Если приложение намеренно поддерживает альтернативный ввод, нормализуйте его в одном известном месте и стройте дальнейшие ссылки из канонического значения; не расширяйте правила каждого слоя независимо.

Для приёмки сравните один разрешённый ID в нижнем и верхнем регистре: они должны указывать на одну сущность согласно выбранной политике. Затем отправьте тот же ID с лишним префиксом, суффиксом и пробелом. Успешный поиск корректной подстроки внутри такого ввода означает, что проверка целого параметра потеряна. Этот контроль не требует настоящих пользователей и может выполняться на искусственном маршруте тестовой среды.

После синтаксиса проверьте объект

Нормализованный UUID используйте в параметризованном запросе или штатной ORM-операции. Не конструируйте SQL из строки пути. Затем ограничьте поиск доступной пользователю областью либо примените объектную policy перед возвратом результата.

Наличие случайного GUID не заменяет object-level access control. OWASP рекомендует проверять разрешение при каждом обращении к объекту, включая корректные сложные идентификаторы. OWASP IDOR Prevention, проверено 05.10.2026; дата публикации страницы не указана.

Статусы ошибочного формата, отсутствующего объекта и отказа доступа определите в своём контракте. Иногда политика специально делает отсутствующий и недоступный объект неразличимыми. Главное — последовательное поведение, которое не раскрывает лишние сведения и проверяется тестом.

Контрольный набор для маршрута

Возьмите искусственные объекты двух тестовых пользователей. Проверьте чтение собственного ID и отказ для ID другого пользователя. Повторите для изменения, удаления и экспорта, если такие операции есть: защита одной страницы не покрывает остальные действия.

Для синтаксиса добавьте верхний регистр, отсутствующий дефис, лишний символ, перевод строки, другую версию и корректный несуществующий ID. Отдельно проверьте, что framework не выполняет неожиданное повторное декодирование параметра. Эти случаи принадлежат вашему маршруту; веб-генератор их не исправляет.

Для недопустимых вариантов не создавайте объект и не выдавайте новый ID автоматически: ошибка входа должна оставаться ошибкой входа.

Если URL и cache key нормализуются по-разному, одна сущность может иметь несколько текстовых представлений. Выберите один канонический регистр для хранения и построения ссылок, сохранив договорённость о принимаемом вводе.

UUID Neraviko генерируется на сервере; сырые запросы и результаты операции по контракту не сохраняются и не логируются по умолчанию. Для тестов маршрута используйте искусственные значения, а рабочую авторизацию проверяйте в существующем приложении.