Running validators before fully checking permission can spill private data to unauthorized users. One example that already exists is in POST /folders, where we don't do permission checking until inside perform_create on the view set. Validators on the serializer are all run prior to that, which for example can leak the existence of a folder or file with a given name inside a folder that a user has no access to.
DRF runs things in the following order in the default create:
Permission checking via permission_classes
Serializer validation
perform_create
In summary, any logic that could be used to deny permission to a user, should occur in permission classes, or else if that's not practical, must run as serializer validators prior to any non-permission related serializer validators. Permission checking must occur prior to serializer.is_valid.
Running validators before fully checking permission can spill private data to unauthorized users. One example that already exists is in
POST /folders, where we don't do permission checking until insideperform_createon the view set. Validators on the serializer are all run prior to that, which for example can leak the existence of a folder or file with a given name inside a folder that a user has no access to.DRF runs things in the following order in the default
create:permission_classesperform_createIn summary, any logic that could be used to deny permission to a user, should occur in permission classes, or else if that's not practical, must run as serializer validators prior to any non-permission related serializer validators. Permission checking must occur prior to
serializer.is_valid.