You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 29, 2022. It is now read-only.
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.